Menu
Produces an implementation plan (waves, acceptance criteria, validation evidence) for non-trivial multi-file work.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Dispatch a multi-wave plan to specialist agents with audit + risk-area abort. Supports --auto-push, --auto-merge, --goal-mode for budgeted runs. NOT for writing the plan itself (that is /spec), and NOT for a single small edit with no waves — just make the edit.
Independently re-verify a completion claim in a separate context — mechanical evidence (files/tests/assertions) plus a refute-by-default semantic judge — before a wave or task is allowed to be called "done". Emits the shared verdict schema. NOT for code-style review (that is a reviewer's lane) and NOT for verifying work you authored in the same context — the verifier must be a fresh spawn.
Router over the harness skills — which skill fits your situation, and the main flow through them. NOT for performing the routed work itself — it only points; invoke the skill it names.
Upstream planning-discipline — brainstorm a feature into spec.md + plan.md under .agent/plans/<slug>/, then route to plan approval. Enforced by the spec-gate tool boundary, not prompt coercion. NOT for trivial/test/doc-only edits (the gate scopes those out), and NOT for executing an already-approved plan (that is /supervise).
Commits staged changes and opens a PR. Runs gitleaks + risk-area guards before committing. Push is user-confirmed by default; --auto-push and --auto-merge are opt-in. NOT for review or verification (run those before wrapping), and NOT when nothing has changed yet — there is nothing to commit.
Agent-driven, read-only self-audit of the harness — run the machine integrity layer once as a dry-run, present a per-check pass/fail table, cite the P1-1 doc-reality result, and for any failure give root-cause + fix + backlog follow-up. Consumes the machine gates; it does not reimplement them. NOT for auditing a consumer project's own codebase (use that project's test suite), and NOT for applying fixes — this skill observes and reports only.
Based on SOC occupation classification
| name | planner |
| description | Produces an implementation plan (waves, acceptance criteria, validation evidence) for non-trivial multi-file work. |
| when_to_use | Before any change that touches > 3 files or > 1 module. NOT for trivial single-file edits. |
Turn a fuzzy user request into a concrete, executable plan. The plan is the deliverable — not code.
code-explorer first if unfamiliar
territory).Target state + Acceptance criteria.data migrations
with feature work — they need different review levels).rules/policy/strong-goal-template.md):
Write the plan to ~/.agent/plans/<slug>.md:
# Plan — <slug>
## Goal
<one-line>
## Context
<2-3 lines: what's the problem, why now, constraints>
## Wave 1 — <summary>
Target state: …
Acceptance criteria:
- (positive) …
- (negative) …
- (regression) …
Validation evidence:
- `npm run test:run -- <path>` → exit 0
- `grep -c '<symbol>' <file>` ≥ N
Boundaries:
- May edit: …
- Off-limits: …
- Preserve: …
Stop conditions:
- …
## Wave 2 — <summary>
…
## Risks + mitigations
- <risk> → <mitigation>
## Open items (deferred)
- <item> — trigger: <condition>
Before declaring the plan done, run:
bash core/infra/supervisor-goal-audit.sh score --plan <slug> --wave 1
If verdict is weak, revise the wave until it scores mixed or
strong. Weak plans turn into mid-flight clarifying questions and
churn.
foo") — that's the executor's job. Plan describes what, not how.