Menu
Produces an implementation plan (waves, acceptance criteria, validation evidence) for non-trivial multi-file work.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| 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.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.