Organize actions by execution context (@computer, @phone, @errands) not by project — you execute based on where you are and what tools are available

Why This Is a Rule

Project-based task organization ("Website Redesign tasks," "Tax Preparation tasks") looks logical but creates a retrieval mismatch at execution time. When you sit down at your computer with 30 minutes to spare, you don't think "Which project should I advance?" — you think "What can I do right now with a computer and 30 minutes?" To answer that question from project-based lists, you'd need to scan every project list, identify the computer-dependent tasks across all projects, and pick one. Context-based organization pre-answers this question: the @computer list already contains exactly the tasks you can do right now.

David Allen's GTD context system organizes actions by the physical conditions required for execution: @computer (needs a computer), @phone (needs to make a call), @errands (needs to be out and about), @home (needs to be at home), @office (needs to be at work), @waiting (delegated, tracking only). When you're at the grocery store, you check @errands. When you're at your desk, you check @computer. The list shows exactly and only what's executable in your current context.

This is an application of the retrieval-oriented organization principle: organize information based on how you'll access it, not how you'd categorize it. You access tasks by execution context (what can I do here and now?), so that's the organizing dimension that makes the list immediately actionable.

When This Fires

• When organizing your task management system and choosing the primary grouping
• When you have free time in a specific context and don't know what to work on
• When project-based lists feel overwhelming because they mix executable and non-executable items
• Complements Capture actions as specific next physical steps (not "handle client project" but "email Sarah the revised timeline") — eliminate re-processing at execution time (next physical action) with the organizational system that makes those actions findable by context

Common Failure Mode

Over-contexting: creating 15 context lists for every possible location and tool combination. This defeats the purpose by making the system too complex to maintain. Most people need 4-6 contexts at most. The contexts should match your actual recurring execution environments, not every theoretically possible one.

The Protocol

(1) Define your 4-6 primary execution contexts based on where and how you actually work: @computer, @phone, @errands, @home, @office, @agenda (for discussions with specific people). (2) When capturing an action (Capture actions as specific next physical steps (not "handle client project" but "email Sarah the revised timeline") — eliminate re-processing at execution time), assign it to the context where it can be executed. "Email Sarah the timeline" → @computer. "Buy printer paper" → @errands. "Discuss budget with Mike" → @agenda-Mike. (3) When you have time to work, check the list for your current context. All items on that list are executable right now. (4) Maintain project lists separately for planning purposes, but use context lists for execution. The project list answers "What does this project need?" The context list answers "What can I do right now?" (5) Review and adjust contexts quarterly. If a context list is always empty or never checked, eliminate it.