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:
-
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.
-
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.
-
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.
-
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.
-
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.
-
Invariants. List what must not break (frozen contracts, do-not-touch, security / privacy /
data / money) and assert each in the verification section.
-
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".
-
Runnable gates. Exact commands with expected output — never "test it" — and note what each
check can't catch. For each phase name the behavioral check that proves it works (Claude Code:
/verify; /run for anything user-facing — Codex: run the test / drive the app yourself), and,
for phases touching auth / data / money / security / storage, the review the executor runs before
the PR (Claude Code: /code-review + /security-review; Codex: a free fresh-context sub-agent
review + the codex-security skills). A cross-model metered reviewer (Greptile / CodeRabbit) is
owner-triggered — surface it, never auto-run it. 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.
-
Rollback + out-of-scope + known-untestable. Name them.
State the risk tier up front (touches auth / data / money / security → full ceremony incl. the §4
review; otherwise lighter). Write the plan to a durable file — label each phase so the kickoff
workflow can target it by name. Then request approval.
