majiayu000 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