plan-phase

Plan $ARGUMENTS at a high bar. If your tooling has a plan mode, enter it — and keep recon prompt-hygiene: prefer the dedicated read tools (Read/Grep/Glob) over shell, keep shell recon to plain single-purpose read-only commands (simple ls/cat/grep/git log chains auto-approve via the bundled plan-mode hook), and route loop-heavy sweeps through read-only sub-agents. Do not skip a step:

1. Open with a grill (only when the brief leaves real gaps). Before designing, close the owner-shaped gaps interview-style: outcome-first questions (the owner decides outcomes; the machine owns mechanisms), ONE at a time, each with a recommended answer; challenge vague answers ("fast" = what latency?). Never ask what the code or live docs can answer — that's §1's job. A settled brief skips this step.

2. Verify, don't trust. Launch a read-only/Explore agent to read the relevant code and sources; confirm every claim you'll rely on; cite file:line. Correct any stale assumption explicitly ("the brief says X; the code shows Y at <file:line>"). For any external framework / library / SDK / CLI you'll build on — especially fast-moving or RC ones — confirm the CURRENT setup against official docs (Context7 / web), not training memory; scaffold commands, adapter conventions, and build-output paths are top causes of "looked right, didn't run".

3. Decisions with receipts. A table Decision | Source, where Source is a verbatim quote from the user, an answer you asked for, or "my judgment — rationale: …". Never inscribe a constraint nobody gave you. If the task came from an open-ended discussion with no written brief, first distil that conversation's conclusions into the receipts table (or a short brief file) — don't plan against un-captured intent; the plan is only as sound as the receipts it cites.

4. Ask the real forks. Use AskUserQuestion for genuine, load-bearing choices you can't resolve from the task / code / a sensible default — batched. Label each option by authority: "In plan", "Engineering alternative", or "Out of scope". Do not mark an option "Recommended" if it contradicts the active plan. If you want to recommend changing the plan, explicitly say "recommend changing the plan" and cite the exact plan line being overridden.

5. Adversarial review — fresh eyes, looped. Run the plan-reviewer agent on your draft as a hostile, fresh-context reader (it can't see the frame you wrote in): "try to break this plan — what's stale vs the code, what's a design hole, what's the worst-case input, what will the verification miss?" Fold every confirmed finding in with an ID (C1, C2, …), then re-run it on the revised plan — a fix can open a new hole — until a fresh pass surfaces nothing material (cap the rounds; gains saturate fast). This is where design holes get caught before they cascade into every later phase.

6. Invariants. List what must not break (frozen contracts, do-not-touch, security / privacy / data / money) and assert each in the verification section.

7. Decompose & sequence — size to sessions. If the task is larger than one sitting, split it into independently-shippable phases — each sized to one session / one PR / one coherent verify-loop, with its own done-criteria, gate, and rollback. A phase you can't finish and verify in a single session is too big; split it. Keep each phase thin (intent + gate), not step-by-step — the executor re-derives specifics against live code at kickoff. Name an executor per workstream (builder/codex/runner/main-loop, per the owner's CLAUDE.md roles table) — the delegation decision belongs at plan time, not mid-build; main-loop workstreams carry a one-line justification (taste or interdependence). Order them foundation-first (the dependency root, gated green), then independent fan-out where parallelizable. For a multi-phase plan, emit a progress tracker and a /tale-mode:kickoff-phase <this-file> "Phase N" cue per phase.

8. Runnable gates. Exact commands with expected output — never "test it" — and note what each check can't catch. A clean diff is not evidence; run it. For each phase, name the behavioral check that proves it works (/verify; /run for anything user-facing) and — for phases touching auth/data/money/security/storage — the /code-review + /security-review the executor runs before the PR; flag any check blocked on not-yet-provisioned services as a deferral the kickoff carries. Every phase's gate list ends with ONE end-to-end proof — a single runnable check that the phase's work is connected through the whole system, not just unit-green. Fail-case test each gate at plan time — inject exactly what it should catch and confirm it goes red; a green gate can bless a bug, and a gate that can't fail isn't a gate.

9. Rollback + out-of-scope + known-untestable. Name them.