What this prompt does
This prompt forces an AI coding assistant to act as a senior staff engineer who plans a multi-file feature before writing a single line of code. It frames the request around four context variables — [feature_name], [stack], [conventions], and [constraints] — then demands a structured plan: files grouped by layer, a migration sketch, API and contract impact with breaking-change flags, per-file risk ratings, suggested commit boundaries, and open questions. It ends with an explicit instruction to stop and wait for approval.
The structure works because it converts a vague "build this feature" request into a reviewable artifact. By naming [conventions] (for example, Form Requests, service classes, PHPUnit) the model stays inside your repo's existing patterns instead of inventing its own. [constraints] like "no breaking API changes" or "ship behind a feature flag" become hard rails the plan must respect. The approval gate is the load-bearing part: it stops the assistant from sprinting into a sprawling diff before you've sanity-checked the shape.
When to use it
- Before starting any feature that touches more than two or three files
- When the change spans layers (routing, service, model, view, test) and order matters
- When a feature includes a database migration you want reviewed before it lands
- When you need clean, individually reviewable commits rather than one giant diff
- When working with a junior or an agent that tends to over-build without a map
- When a feature must respect hard constraints like feature flags or API compatibility
Example output
You get a checklist-style plan, not code. Expect a grouped file list (routing / service / model / view / test), a short migration sketch for any schema change, a section flagging public API or contract impact, a per-file risk table marked low / medium / high with reasons, a suggested sequence of commit boundaries, and a list of open questions the assistant needs answered. Each item is concrete enough to act on rather than a vague gesture at the work, and the commit boundaries are ordered so that the first commit is the safest place to start. It then stops and waits for your go-ahead, which is the moment to challenge any file you didn't expect to see in the list or any risk rating that looks too optimistic.
Pro tips
- Fill
[conventions]with the specifics your repo actually enforces — vague conventions produce vague plans - Use
[constraints]to encode the non-negotiables (no breaking changes, behind a flag) so they shape every step - Keep
[feature_name]narrow; one cohesive feature plans far better than a bundle of loosely related changes - Read the open-questions section first — that's usually where the real ambiguity hides
- If the risk ratings feel hand-wavy, ask it to justify each one before you approve
- Never skip the approval gate; the cheapest bug to fix is the one you catch in the plan
