| 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
- 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.
- 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).
- Choose an approach. If there is a real fork, give one recommendation with a
one-line rationale, not an exhaustive survey.
- Break it into steps. Each step is small, ordered by dependency, and
independently checkable.
- Define success criteria. State exactly how each step is verified (a test, a
command, an observable behavior).
- 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.
