Create Plan
When to Use
- The user explicitly requests a plan for a coding task (feature, bug fix, refactor) before implementation begins.
- You need to organize work into ordered checklist items, including discovery, changes, tests, and rollout.
- The work benefits from a short, structured plan that can be reviewed and approved before coding.
When NOT to Use
- The request is already being implemented or no plan is needed (e.g., simple bugfix or documentation edit).
- You're in the middle of executing a plan and should focus on executing (use executing-plans).
- The task is exploratory, open-ended, or research-heavy without a concrete implementation path.
Goal
Turn a user prompt into a single, actionable plan delivered in the final assistant message.
Minimal workflow
Throughout the entire workflow, operate in read-only mode. Do not write or update files.
- Scan context quickly
- Read README.md and any obvious docs (docs/, CONTRIBUTING.md, ARCHITECTURE.md). - Skim relevant files (the ones most likely touched). - Identify constraints (language, frameworks, CI/test commands, deployment shape).
- Ask follow-ups only if blocking
- Ask at most 1–2 questions. - Only ask if you cannot responsibly plan without the answer; prefer multiple-choice. - If unsure but not blocked, make a reasonable assumption and proceed.
- Create a plan using the template below
- Start with 1 short paragraph describing the intent and approach. - Clearly call out what is in scope and what is not in scope in short. - Then provide a small checklist of action items (default 6–10 items). - Each checklist item should be a concrete action and, when helpful, mention files/commands. - Make items atomic and ordered: discovery → changes → tests → rollout. - Verb-first: “Add…”, “Refactor…”, “Verify…”, “Ship…”. - Include at least one item for tests/validation and one for edge cases/risk when applicable. - If there are unknowns, include a tiny Open questions section (max 3).
- Do not preface the plan with meta explanations; output only the plan as per template
Plan template (follow exactly)
# Plan
<1–3 sentences: what we’re doing, why, and the high-level approach.>
## Scope
- In:
- Out:
## Action items
[ ] <Step 1>
[ ] <Step 2>
[ ] <Step 3>
[ ] <Step 4>
[ ] <Step 5>
[ ] <Step 6>
## Open questions
- <Question 1>
- <Question 2>
- <Question 3>Checklist item guidance
Good checklist items:
- Point to likely files/modules: src/..., app/..., services/...
- Name concrete validation: “Run npm test”, “Add unit tests for X”
- Include safe rollout when relevant: feature flag, migration plan, rollback note
Avoid:
- Vague steps (“handle backend”, “do auth”)
- Too many micro-steps
- Writing code snippets (keep the plan implementation-agnostic)