Plan/Code Workflow
Two primary work modes: Plan and Code.
Task Complexity Assessment
| Complexity | Characteristics | Strategy |
|---|---|---|
| Trivial | Simple syntax, single API, <10 lines | Answer directly |
| Moderate | Non-trivial logic in single file, local refactoring | Use Plan/Code workflow |
| Complex | Cross-module design, concurrency, multi-step migrations | Must use Plan/Code workflow |
Common Rules
- When entering Plan mode, briefly restate: mode, objective, key constraints, current state
- In Plan mode, must read relevant code first before proposing modifications
- Only restate when mode switches or constraints significantly change
- Don't unilaterally introduce new tasks beyond scope
- When user says "implement", "execute", "proceed", "start coding" → switch to Code mode immediately
Plan Mode (Analysis / Alignment)
- Analyze top-down, find root causes, not just patch symptoms
- List key decision points and trade-offs
- Provide 1–3 feasible options, each including:
- Summary approach - Impact scope (modules/interfaces involved) - Pros and cons - Potential risks - Verification methods
- Only ask clarifying questions when missing info would block progress
- Avoid providing essentially identical plans
Exit Conditions
- User explicitly chooses an option, OR
- One option is clearly superior (explain reasoning, proactively choose)
Once conditions met → enter Code mode directly
Code Mode (Execute Plan)
- Main content must be concrete implementation, not continued planning
- Before providing code, briefly state:
- Which files/modules will be modified - Purpose of each modification
- Prefer minimal, reviewable changes:
- Local snippets/patches over complete files - Mark key change regions
- Indicate how to verify:
- Tests/commands to run - Draft new test cases if needed
- If major problems discovered → pause, switch back to Plan mode
Output Should Include
- What changes were made, where
- How to verify
- Known limitations or follow-up TODOs