plan-phase

Plan a phase (high bar)

Cross-platform note. This is the skill form of the /tale-mode:plan-phase Claude Code command, for hosts where slash commands don't exist (e.g. Codex). The two are kept in sync — if you edit one, mirror the other. On Codex there is no $ARGUMENTS: take the task to plan from the user's prompt. If your host has a plan mode, enter it — and keep recon prompt-hygiene: prefer the host's dedicated read tools over shell, keep shell recon to plain single-purpose read-only commands (on Claude Code, 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.

Plan the user's task at a high bar. 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. Spawn a read-only sub-agent (Claude Code: an Explore agent; Codex: a sub-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 — especially fast-moving or RC ones — confirm the CURRENT setup against official docs (Context7 / web), not training memory.

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 — don't plan against un-captured intent.

4. Ask the real forks. Ask the user about genuine, load-bearing choices you can't resolve from the task / code / a sensible default — batched into one round. Label each option by authority: "In plan", "Engineering alternative", or "Out of scope". Don't mark an option "Recommended" if it contradicts the active plan; to override the plan, say "recommend changing the plan" and cite the exact line.

5. Adversarial review — fresh eyes, looped. Run a hostile, fresh-context reviewer on your draft (Claude Code: the plan-reviewer agent; Codex: a fresh sub-agent framed as a jaded senior): "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 until a fresh pass surfaces nothing material (cap the rounds; gains saturate fast). This is where design holes get caught before they cascade.

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. 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 roles table) — the delegation decision belongs at plan time, not mid-build; main-loop workstreams carry a one-line justification (taste or interdependence). Order foundation-first, then independent fan-out. Emit a progress tracker and a per-phase kickoff cue so the plan self-documents how to start each phase: on Claude Code /tale-mode:kickoff-phase <this-file> "Phase N"; on Codex, invoke the kickoff-phase skill (from /skills) naming this file + "Phase N".