plan

name	plan
description	Turn a vague or multi-step task into a concrete, verifiable implementation plan before writing code. Use when a task is non-trivial, ambiguous, or spans several files.

plan

Think before coding. Produce a short, concrete plan that surfaces assumptions and defines how success will be verified, so implementation is mechanical.

Steps

1. Understand the real request. Restate the goal in one sentence. List the explicit requirements and the implicit ones. If a requirement is ambiguous and the choice changes the outcome, ask - do not guess.
2. Survey the code. Find the files, functions, and patterns the change touches. Note existing conventions to follow. Identify constraints (stack rules, public APIs, data shapes).
3. Choose an approach. If there is a real fork, give one recommendation with a one-line rationale, not an exhaustive survey.
4. Break it into steps. Each step is small, ordered by dependency, and independently checkable.
5. Define success criteria. State exactly how each step is verified (a test, a command, an observable behavior).
6. Call out risk. What could break, what is out of scope, what you are assuming.

Output

Goal: <one sentence>
Assumptions: <list, or "none">
Steps:
  1. <action> -> verify: <how>
  2. ...
Risks / out of scope: <list>

Rules

• Plan to the altitude of the task: a one-file fix gets a 3-line plan, not a document.
• Prefer the smallest change that satisfies the requirement; do not design for imagined future needs.
• Surface unknowns explicitly instead of hiding them behind confident prose.
• Do not start editing until the plan's open questions are resolved.