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)