Plan mode as an acceptance gate

Plan mode reduces wrong-direction implementation by separating repository exploration from edits. A strong workflow turns accepted intent and spec into a versioned plan.md with files, sequence, risks, migrations, rollback, and proof. Model output remains a proposal: a named human accepts the plan, then execution starts with separately chosen sandbox and approval settings.

Scorecard question: How often do you start implementation in Plan mode and commit plan.md?

Maximum-score answer: Plan mode is the default for non-trivial work; the accepted plan is committed before application code.

Use the same contract in every tool

Tool	Verified planning entry	Important boundary
Claude Code	`/plan`, Shift+Tab, or `claude --permission-mode plan`	Use `claude -w BRANCH_NAME` for a separate worktree; plan mode is not deployment authority
Cursor	Plan mode in the agent UI; `cursor-agent --plan` or `cursor-agent --mode plan`	`--sandbox` is a separate CLI control
Codex	`/plan` in the CLI at an appropriate turn boundary	Worktrees come from the Codex app or Git; the CLI has no `--worktree` flag

Commands were checked on 4 September 2026 against the installed Claude Code 2.1.258, Cursor Agent 2026.01.28-fd13201, and Codex CLI 0.146.0, then compared with the official references linked below.

The plan contract

An acceptable plan names:

the problem and non-goals inherited from intent.md and spec.md;
files and symbols to inspect or change;
ordered implementation steps and dependencies;
data migration, compatibility, security, and rollback risks;
deterministic checks plus any visual or manual proof;
unresolved decisions and the human who must make them.

Save the accepted result in the repository. A private plan hidden in a tool session cannot serve CI, reviewers, or a later agent.

Prompts to copy

Read intent.md, spec.md, repository instructions, and the relevant code.
Work read-only. Produce a plan with exact files, ordered steps, risks,
rollback, and proof. List unanswered decisions; do not edit files.

Challenge this plan against current code and tests.
Find missing call sites, migration hazards, security boundaries,
and verification gaps. Return a revised plan only.

Execute the accepted plan.md in an isolated worktree.
Stop if implementation requires a materially different design.
Run every listed check and report commands, exit codes, and deviations.
Do not merge or deploy.

Failure modes

The plan is generic. Reject it until it cites actual files, symbols, tests, and proof.

The plan becomes stale during implementation. Stop, update plan.md with the reason, and have the named approver accept the changed direction before continuing.

Planning is confused with permission. Configure sandboxing, command approvals, credentials, branch protection, and production gates separately.

The tool has no plan command in the current state. Start a fresh planning turn or use an explicit read-only planning prompt. Do not invent a flag.

Verify the gate

Every non-trivial change links accepted intent.md, spec.md, and plan.md.
The plan contains exact proof commands and owners for manual checks.
Git history shows the accepted plan before or with the implementation.
The agent stops and records material deviations.
Planning mode, sandbox, approval policy, merge, and production authority are separate controls.

Continue after acceptance

Move to Build only after the plan is accepted. Use the tool map for current Claude Code, Cursor, and Codex mechanics.

Official references

Artifact chain Keep one source of truth from intent to incident.

Governance and autonomy Separate planning from action authority.