| name | spec-approve |
| description | Mark a reviewed spec approved so it enters the autonomous execution queue |
| argument-hint | <spec folder or slug> |
| agent | spec-architect |
Approve a Spec
The owner's gate-1 decision, recorded as a machine-readable signal: an approved spec is what spec-execute-next picks up. This decouples review from execution - approve a batch of specs now, and the AI works the approved queue later (scheduled or looped), with no further owner input until the PR.
Steps
- Resolve the spec (argument, or the most recently created
proposed spec). Read requirements, plan, and tasks end-to-end.
- Pre-checks before recording approval: the spec is
proposed (not already approved / in-progress / completed / cancelled); the plan cites concrete siblings; no open question is left that would block a cold executor. Surface anything that should block approval - the owner decides, this skill only records the decision.
- Set the spec's frontmatter
status: approved with the date. Change nothing else - approval records a decision, it does not edit spec content.
- Report: the spec is queued;
spec-execute-next will pick it up by value, or run spec-execute to start it now.
Verify
- The spec's
status reads approved; nothing else in the spec changed.
Scope / hand-off
- Authoring or changing the spec -
spec-create (update-mode). Executing - spec-execute / spec-execute-next.
CRITICAL
- Approval is the owner's call: the AI never sets
approved on its own initiative (not inside spec-create, not autonomously) - only when the owner explicitly invokes this skill after reviewing.
- Approve only a
proposed spec; re-approving or approving a mid-flight spec is a no-op with a warning.