Claude Code Plan-First: Force a Reviewable Plan Before Touching Any Code

You are operating in PLAN-FIRST mode. Do NOT edit, create, or delete any files, and do NOT run any state-changing commands until I explicitly reply with the word `APPROVE`. Read-only exploration (searching, reading files, running read-only commands) is allowed and encouraged.

TASK:
{{TASK_DESCRIPTION}}

CONSTRAINTS / CONTEXT:
{{CONSTRAINTS}}

Follow this procedure exactly.

STEP 1 — Explore (read-only):
- Inspect the relevant parts of the codebase before proposing anything. Identify the existing patterns, conventions, and the files most likely involved.
- If a CLAUDE.md / AGENTS.md or similar project guide exists, respect it.
- If anything about the task is ambiguous, list your open questions at the TOP of your response. Make your best assumption for each, label it clearly as an ASSUMPTION, and continue — do not stall waiting for me.

STEP 2 — Produce the PLAN. Output these sections, in order:
1. **Goal restated** — one or two sentences, in your own words, describing what 'done' means.
2. **Files to touch** — a bullet list. For each file: the exact path, and whether it is CREATE / MODIFY / DELETE, plus a one-line reason. If you are unsure a file exists, say so.
3. **Implementation steps** — an ordered list of small, individually reviewable steps. Each step should be something I could verify on its own.
4. **Risks & blast radius** — what could break, what existing behavior this might affect, any migration/data/security/backward-compat concern. Be honest; if you are not sure, say 'uncertain'.
5. **Out of scope** — explicitly list things you will NOT do, so we agree on boundaries.
6. **Acceptance criteria** — a concrete checklist (commands to run, expected outputs, behaviors to observe) that proves the change works. Prefer criteria I can verify mechanically (a test passing, a command exiting 0, a specific UI state).

STEP 3 — Stop and wait.
End your response with: 'Reply APPROVE to execute, or tell me what to change in the plan.'

Rules:
- Keep the plan tight. No filler, no 'as an AI' preamble.
- Do not start implementing in the same message as the plan.
- If after my feedback the plan changes materially, re-print the full updated plan and wait for APPROVE again.
- When I finally reply APPROVE, execute the plan step by step, and after each major step state which acceptance criterion it satisfies.

You are operating in PLAN-FIRST mode. Do NOT edit, create, or delete any files, and do NOT run any state-changing commands until I explicitly reply with the word `APPROVE`. Read-only exploration (searching, reading files, running read-only commands) is allowed and encouraged.

TASK:
{{TASK_DESCRIPTION}}

CONSTRAINTS / CONTEXT:
{{CONSTRAINTS}}

Follow this procedure exactly.

STEP 1 — Explore (read-only):
- Inspect the relevant parts of the codebase before proposing anything. Identify the existing patterns, conventions, and the files most likely involved.
- If a CLAUDE.md / AGENTS.md or similar project guide exists, respect it.
- If anything about the task is ambiguous, list your open questions at the TOP of your response. Make your best assumption for each, label it clearly as an ASSUMPTION, and continue — do not stall waiting for me.

STEP 2 — Produce the PLAN. Output these sections, in order:
1. **Goal restated** — one or two sentences, in your own words, describing what 'done' means.
2. **Files to touch** — a bullet list. For each file: the exact path, and whether it is CREATE / MODIFY / DELETE, plus a one-line reason. If you are unsure a file exists, say so.
3. **Implementation steps** — an ordered list of small, individually reviewable steps. Each step should be something I could verify on its own.
4. **Risks & blast radius** — what could break, what existing behavior this might affect, any migration/data/security/backward-compat concern. Be honest; if you are not sure, say 'uncertain'.
5. **Out of scope** — explicitly list things you will NOT do, so we agree on boundaries.
6. **Acceptance criteria** — a concrete checklist (commands to run, expected outputs, behaviors to observe) that proves the change works. Prefer criteria I can verify mechanically (a test passing, a command exiting 0, a specific UI state).

STEP 3 — Stop and wait.
End your response with: 'Reply APPROVE to execute, or tell me what to change in the plan.'

Rules:
- Keep the plan tight. No filler, no 'as an AI' preamble.
- Do not start implementing in the same message as the plan.
- If after my feedback the plan changes materially, re-print the full updated plan and wait for APPROVE again.
- When I finally reply APPROVE, execute the plan step by step, and after each major step state which acceptance criterion it satisfies.