This page is a compact guide to the terms and decisions used by
implementing-staged-plans. The canonical skill instructions
and their linked procedures remain authoritative when a user guide and the
implemented workflow differ.
The command depends on how the skill was installed:
| Installation | Invoke with |
|---|---|
| Codex plugin or standalone skill | $implementing-staged-plans |
| Claude Code plugin | /implementation-plugin:implementing-staged-plans |
| Claude Code standalone skill | /implementing-staged-plans |
Follow the invocation with a target program or manifest, the action you want, the desired approval mode when creating new state, and any explicit stop.
A repository-backed record that ties an authoritative source to requirements, planned increments, approvals, state, workspace, and evidence.
One bounded, reviewable unit of the program. An increment has its own plan, authority, implementation, review, verification, and acceptance state.
The current implementation plan for one increment, including the files and behavior expected to change. It is bound to the current program, workspace, and repository observation rather than acting as a timeless checklist.
The immutable pre-product-change snapshot of the exact plan, repository observation, path dispositions, and preserved user work. New-program status cannot become authorized until this baseline and its plan-bound action authorization are durable.
The approved writable repository path, branch, base, current head, and recorded pre-existing work. It prevents work prepared for one tree from being applied to another without revalidation.
A current grant for one named action and scope, such as modifying the workspace, running local verification, or creating a local commit. It is separate from the approval mode.
The concrete result that supports a claim: for example, a command result, accepted review artifact, state digest, or repository observation. Evidence is limited to what it actually exercised.
The bound collection of review findings, dispositions, verification results, and the exact diff proposed for acceptance.
A navigation record for continuing later. It points to the controlling state and evidence but grants no authority on its own.
The final accounting across every requirement, amendment, increment, finding, deferral, and program-level verification result.
The bound summary presented for explicit program-closure approval after reconciliation succeeds.
The implemented order is: Create a New Program, Activate a Generated
Program, Before Production Modification, Prepare Review and Diff
Disposition, Dispose the Current Diff, Continue an Accepted Program
when requested, Authorize a Successor Increment when one is allocated,
Resolve a Blocked Program when typed recovery is required, and Close a
Final Program when no successor remains. Creation and first-increment behavior
remain owned by Plan A. Plan B adds exact accept-continue, the distinct
accepted-state-continuation route, status-current successor grants through
current_increment_authority_binding, and prompt-bound blocked-recovery.
Final programs reuse the unchanged Plan A closure transaction and derive paths
from implementation-closure-storage/v1.
Every typed transaction writes controlling status last and adopts only byte-identical prefixes. A divergent prefix stops for recovery without cleanup.
The skill always revalidates current repository facts and controlling records before relying on an earlier state.
Approval modes define routine interruption policy. New-model typed dispositions
in version 0.1.2 always offer accept-stop and conditionally offer exact
accept-continue for one satisfied successor. Modes do not grant action authority
or automatic successor rollover. Legacy approval:full and
approval:full-diff modes retain their automatic acceptance behavior.
| Mode | Scope | Routine plan pause | Diff acceptance | Continuation and mandatory stop |
|---|---|---|---|---|
approval:standard |
One increment | Yes | User | Stops for plan approval, user-owned material decisions, contradictions, hard stops, and diff acceptance |
approval:pre-approve |
One increment | No | User | Stops for user-owned decisions, program amendments, contradictions, hard stops, and diff acceptance |
approval:full-increment |
One increment | No | User | Runs through verification, then stops for diff acceptance unless a hard stop occurs |
approval:full-diff |
Legacy current increment | No | Legacy policy permits automatic acceptance only after verification and a valid bound packet | Cannot begin another increment |
approval:full |
Legacy current increment | No | Legacy policy permits automatic acceptance only after verification and a valid bound packet | Cannot begin another increment automatically; discovery stops at legacy-rollover-upgrade-required |
New-program proposal construction, bootstrap, and launch reject
approval:full-diff and approval:full before every write. Those modes are
dual-read compatibility for already persisted legacy programs only.
When a direct creation request omits a mode, proposal construction defaults to
approval:full-increment before producing any bytes. The selected mode is then
persisted explicitly. Persisted state with a missing or unknown mode is invalid
and is not silently defaulted. An explicit user-requested gate always remains in
force, even if the selected mode would normally omit that pause.
Approval mode sets the routine interruption policy. It answers questions such as whether to pause for the exact-file plan and who accepts the reviewed diff.
Implementation action authorization permits one current program action and scope. Examples include writing a specific program artifact, modifying the bound workspace, running named local verification, or creating a local commit.
Later or external-action authorization covers consequential actions after implementation, such as a pull request, merge, publication, release, deployment, migration, destructive operation, permission change, or provider mutation. The program must be in a suitable state, and the grant must name that exact action.
None of these permissions substitutes for the others. In particular, accepting a diff does not authorize a commit, and closing a program does not authorize a release.
The workflow stops instead of guessing when it finds:
- more than one possible program or workspace;
- a source, plan, approval, status, brief, handoff, or packet digest mismatch;
- a branch, base, head, path, or pre-existing-work observation that has drifted;
- an active or conflicted Git operation;
- a requested transition that is not legal from the current state;
- missing, expired, revoked, rejected, ambiguous, or mismatched authority;
- a user-owned decision or program amendment required by the selected mode; or
- a requested Git, publication, provider, or external action outside the grant.
Typed continuation and blocked recovery have their own exact prompts and
retry/recovery routes. legacy-rollover-upgrade-required still quarantines the
legacy rollover writer, and blocked-transaction-required still rejects generic
direct blocked edges. program-revision-workflow-required and
unsupported-program-mutation continue to stop unsupported revision,
supersession, cancellation, or other program mutation. Accepted legacy programs
and historical terminal records remain readable, but those read paths do not
reactivate a mutation sink.
The result should name the failed invariant and return the smallest action that can resolve it. The workflow does not manufacture replacement state to continue.
The bundled scripts can validate schemas, exact bindings, digests, declared state transitions, file constraints, deterministic packet structure, and specific local command evidence supplied to them.
They do not prove that a reviewer was genuinely independent, a human approval was well informed, a design is semantically correct, a live service behaves as expected, or an external action occurred. Those claims still need evidence from the relevant human or runtime process.
For copyable task prompts, continue with Common workflows. For a blocked run, use Troubleshooting.