菜单
Use when tracked work is already shaped and the next move is to execute, verify, block, or request feedback without replanning from scratch.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when routed repo work still has meaningful ambiguity about behavior, constraints, taste, or acceptance intent, and that ambiguity would make planning or execution unsafe.
Use when a new request might involve repo work, tracked changes, workspace-specific decisions, or durable coordination and you must decide whether Superplan should engage before exploring or implementing.
Use when the target is understood but the work still needs an execution path, task breakdown, or proof strategy before implementation begins.
Use when Superplan may engage and you need to decide whether to stay lightweight, create one tracked task, gather context first, or shape deeper structure before execution begins.
Use when Superplan has decided to engage and the work still needs plans, specs, proof paths, or multiple tracked tasks shaped before bounded execution can start.
Use when brownfield or long-running repo work lacks durable context about architecture, conventions, or recurring gotchas that future tasks will need again.
基于 SOC 职业分类
| name | superplan-execute |
| description | Use when tracked work is already shaped and the next move is to execute, verify, block, or request feedback without replanning from scratch. |
Move graph-ready work forward without drifting into broad replanning or unnecessary CLI exploration.
This is the main execution control surface once work has been shaped. It should behave more like a scheduler and control plane than a single linear worker.
Execution should be primarily subagent-driven:
Once execution starts, prefer the narrowest execution sub-problem over broad workflow reconsideration.
superplan-debug when a failure blocks forward motionsuperplan-tdd when a new behavior or bugfix can be expressed as a proof-first implementation stepsuperplan-verify when success claims are approaching faster than proofsuperplan-review when the question becomes "is this task actually done?"Use when:
Do not run when:
Inputs:
Assumptions:
Keep these layers distinct:
Do not collapse execution into a flat task-file-only mindset.
See references/runtime-state.md.
Align execution to the CLI that exists today.
Current CLI execution surface:
superplan task inspect show <task_ref> --jsonsuperplan run --jsonsuperplan run --fresh --jsonsuperplan run <task_ref> --jsonsuperplan task runtime block <task_ref> --reason <reason> --jsonsuperplan task runtime request-feedback <task_ref> --message <message> --jsonsuperplan task review complete <task_ref> --jsonsuperplan task repair fix --jsonsuperplan status --jsonsuperplan worktree ensure <change-slug> --jsonsuperplan worktree list --jsonsuperplan worktree detach <change-slug> --jsonsuperplan worktree prune --jsonCurrent CLI truth:
in_progress, in_review, done, blocked, and needs_feedback~/.config/superplan/project-<name>-<hash>/runtime/, which the CLI may render as .superplan/runtime/... from the repo rootsuperplan task inspect show <task_ref> --json includes one task's computed readiness reasonssuperplan status --json is the current narrow runtime summary surface even though a persisted .superplan/runtime/current.json-style summary is still only a product targetin_reviewTherefore:
status --json and run --json to inspect the frontier; use task inspect show <task_ref> --json only when one specific task needs deeper inspectioncomplete, approve, and reopenpending or in_progress; either move it through complete and the appropriate review state or explicitly report the blocker that prevented that transitionExecution is not permission to wander across CLI commands.
superplan run payload, and one relevant verification path--help, neighboring subcommands, or extra diagnostic commands when the next execution command is already knownsuperplan task inspect show <task_ref> --json only when one task's detailed readiness or reasons are actually neededsuperplan doctor --json only for setup or install issues, not normal executionExecution updates must describe actual work performed, current verification, material risks, and user-impacting decisions. Do not narrate Superplan ceremony.
control-plane mode.Use the CLI as the transition gate for runtime state.
needs_feedback means the task cannot proceed without a human decisionin_review means implementation is complete enough for acceptance review and waiting on approval or reopenMark task done when:
Request feedback only for genuine blockers:
Do not use needs_feedback for routine work completion. Completion with passing verification should transition through review complete, not feedback request.
Recovery rules:
superplan task repair fix for deterministic runtime repairsuperplan task repair reset <task_ref> only as an explicit recovery action, not as the normal pathSee references/runtime-state.md and references/lifecycle-semantics.md.
Classify discovered changes into three buckets:
Authority:
superplan-shapesuperplan-routeSee references/trajectory-changes.md.
superplan status --json and superplan run --json; use superplan task inspect show <task_ref> --json when one task needs full detailsuperplan task repair fix when warrantedRecommended patterns:
See references/subagent-dispatch.md.
review runtime statestatus, run, task inspect show, or task repair fix when runtime or readiness is unclearstatus or task inspect show without a concrete state, blocker, or handoff reasonExpected output categories:
Runtime summary should keep legible:
Use the runtime-aware CLI as the scheduler:
superplan run <task_ref> --json; if the user starts unrelated work in the same chat, use superplan run --fresh --json; otherwise start with superplan run --jsonsuperplan status --json only when frontier orientation, inspection, or runtime recovery is actually neededsuperplan run; only call superplan task inspect show <task_ref> --json when you need one task's full details and readiness reasonsrun or task activation returns EXECUTION_ROOT_OCCUPIED or EXECUTION_ROOT_STALE, repair or inspect execution-root routing with superplan worktree ensure <change-slug> --json or superplan worktree list --json before continuing in the wrong checkoutsuperplan task runtime block <task_ref> --reason "<reason>" --json when blockedsuperplan task runtime request-feedback <task_ref> --message "<message>" --json when user input is requiredsuperplan task review complete <task_ref> --json only after the task contract is actually satisfiedsuperplan task repair fix --json if runtime state becomes inconsistentsuperplan task scaffold new, superplan task scaffold batch, superplan run, superplan run <task_ref>, and superplan task review reopen to auto-reveal the overlay as work becomes visible; on a fresh machine or after install/update, verify overlay health with superplan doctor --json and superplan overlay ensure --json before assuming it is working, and inspect launchability or companion errors if the reveal fails; use superplan overlay hide --json when the workspace becomes idle or emptyoverlay.companion.launched is false, surface overlay.companion.reason instead of assuming the overlay appearedClose-out rule:
pending or in_progress just because code and tests are doneUse .superplan/decisions.md for meaningful execution choices, such as trajectory changes, major blocker handling, or review-routing decisions that future agents need to preserve.
Do not use it as a runtime event stream.
Use .superplan/gotchas.md for repeated execution traps, misleading repo behavior, unstable verification patterns, or subagent coordination failures likely to recur.
See references/gotchas.md.
Likely handoffs:
superplan-reviewsuperplan-shape when structural trajectory change is detectedsuperplan-route only when strategic trajectory change is detectedInternal support-skill usage may include:
superplan-debugsuperplan-tddsuperplan-verifyExecution handoff to superplan-review should name the evidence gathered and the CLI/runtime facts that support the review.
Current CLI:
superplan task inspect show <task_ref> --jsonsuperplan run --jsonsuperplan run <task_ref> --jsonsuperplan task runtime block <task_ref> --reason <reason> --jsonsuperplan task runtime request-feedback <task_ref> --message <message> --jsonsuperplan task review complete <task_ref> --jsonsuperplan task repair fix --jsonsuperplan task repair reset <task_ref> --jsonsuperplan status --jsonsuperplan overlay ensure --jsonsuperplan overlay hide --jsonFuture CLI hooks:
superplan task reviewsuperplan run dispatchsuperplan run reconcileShould execute:
Should dispatch subagents in parallel:
Should use the CLI control plane explicitly:
superplan run --json to select or start worksuperplan run <task_ref> --json when one known task should become active explicitlysuperplan task inspect show <task_ref> --json when a specific task needs full detail or readiness explanationsuperplan task runtime block ... --json or superplan task runtime request-feedback ... --json when execution must pausesuperplan task repair fix --json when runtime state has driftedShould avoid parallelism:
Should not overclaim current CLI support:
run and status exist today, but richer run dispatch and run reconcile do notShould classify trajectory change as local:
Should classify trajectory change as structural:
Should classify trajectory change as strategic:
Should block cleanly:
Should escalate instead of silently working around:
Should not reshape casually: