Command reference

Published from docs/reference/commands.md at 835522e. Edit the source in the repository, not this page.

This is the authoritative list of Sanduq's 42 public extension commands, with one example each. Package READMEs and extension pages link here. Examples use the synthetic booking application and issue 412. Guards still enforce issue binding and stage order; an example does not bypass them.

Command names

Each command has a manifest identifier. Your host shows it under its own syntax:

Host	Example
Claude Code	/speckit-assure-analyze --feature specs/412-refund-approval
Codex	$speckit-assure-analyze --feature specs/412-refund-approval
Manifest identifier	speckit.assure.analyze

The tables below use Claude Code syntax. In Codex, replace the leading / with $. Prompts are agent requests, not shell commands. Claude Desktop does not run extensions.

Contents

• Workflow (15 commands, including the two Scope commands)
• Project (2 commands)
• Assure (3 commands)
• User Manual (4 commands)
• PR (2 commands)
• Illustrate (4 commands)
• Memory (7 commands)
• Progress (5 commands)
• Workflow utilities from the shell
• Runtime commands for the front half
• Internal skills and overlays

Workflow

Extension page · package README

Command	When and example
/speckit-workflow-init	Set project policy: Enable QA and User Manual for the booking application; use an advisory managed-only gate and our existing Project.
/speckit-workflow-scope	Start explicitly: 412 Assess refund approval and continue through implementation under project policy.
/speckit-workflow-clarify	After issue answers: Reread issue 412's edited answers and resume the bound feature.
/speckit-workflow-continue	After interruption: Resume specs/412-refund-approval from its checkpoint; inspect recorded worker handles first.
/speckit-workflow-finalize	Authorize the PR handoff: Finish current checks and documentation; create or update the refund feature's PR.
/speckit-workflow-status	Inspect: Show issue 412's active claim, remaining stages, and stale evidence.
/speckit-workflow-doctor	Diagnose: Check actual Project mappings, dependencies, policy, and host commands.
/speckit-workflow-reconcile	Repair integration: Restore managed hooks and presets while preserving unrelated hooks.
/speckit-workflow-verify-affected	Before pushing: Run the refund feature's affected lanes against origin/main using our configured hooks.
/speckit-workflow-ci-report	Investigate slow checks: Summarize the last 10 runs of ci.yml in example-org/booking-app; distinguish fixed job overhead from test time.
/speckit-workflow-gate-explain	Diagnose drift: Explain the failing gate for specs/412-refund-approval against origin/main before changing evidence.
/speckit-workflow-worker-brief	Bound a worker task: Generate the brief for T012 in specs/412-refund-approval with its owned paths and verbatim requirements.
/speckit-workflow-apply-pending	Reconcile shared artifacts: Preview pending refund contract proposals; check each against implementation before applying.

Scope

Extension page · package README

Scope is part of Workflow, and its two commands are among Workflow's 15. Workflow provides Scope from 2.0.0; before that these were speckit.scope.run and speckit.scope.plan in the separate scope extension (upgrades).

Command	When and example
/speckit-workflow-scope-run	Analyze: 412 Inspect existing refund behavior and propose the remaining feature boundary.
/speckit-workflow-scope-plan	After decomposition: Regenerate and validate the refund dependency plan as an Illustrate diagram.
/speckit-scope-migrate	Retired Scope 2.0.0 shim, not counted above; only with it installed: How do I move this project to Workflow 2.0.0?

Scope's hook commands run from Spec Kit events and are not host skills (so they never compete with speckit.specify or speckit.plan for a prompt): /speckit-workflow-scope-guard before Specify, /speckit-workflow-scope-bind and /speckit-workflow-scope-after-specify after Specify, /speckit-workflow-scope-plan-guard before Plan, /speckit-workflow-scope-reconcile after Implement. To refresh parent progress by hand run python .specify/extensions/workflow/scripts/scope/scope.py reconcile --apply.

Project

Extension page · package README

Command	When and example
/speckit-project-init	Once: Discover the booking application's Project, map lifecycle columns, and select required sync.
/speckit-project-sync	Reconcile: Synchronize the refund parent and completed task IDs without duplicate native sub-issues.

Assure

Extension page · package README

Command	When and example
/speckit-assure-init	Once: Configure required QA analysis and tester documentation for the booking application.
/speckit-assure-analyze	Before implementation: --feature specs/412-refund-approval Add missing duplicate settlement, rejection, permission, and accessibility coverage.
/speckit-assure-document	After checks: --feature specs/412-refund-approval Document runnable refund scenarios and the actual test evidence.

User Manual

Extension page · package README

Command	When and example
/speckit-user-manual-init	Once: Discover Booking, Payments, and Operations modules; interview me, require English, and offer Arabic.
/speckit-user-manual-analyze	Before implementation: Find refund tutorials, API, entity, release, and screenshot gaps in this feature's tasks.
/speckit-user-manual-update	After implementation: Update only affected refund pages and assets; build the private preview and record freshness.
/speckit-user-manual-release	At a verified application release: Build the approved v3.0.0 audience/language HTML archives and PDFs.

PR

Extension page · package README

Command	When and example
/speckit-pr-generate	Publish: --feature specs/412-refund-approval Update the existing PR with behavior, verified checks, and readable diagrams.
/speckit-pr-review-feedback	After review: example-org/booking-app#438 Classify unresolved feedback and present the concrete fix/reply plan for approval.

Illustrate

Extension page · package README

Command	When and example
/speckit-illustrate-theme	Configure: set cobalt light or validate for the tracked project theme.
/speckit-illustrate-generate	Explain: Create a state diagram of refund request, approval/rejection, and settlement from the real implementation.
/speckit-illustrate-export	Embed: docs/refund-approval.html --svg-only
/speckit-illustrate-import	Redraw: docs/legacy/order-flow.mmd --size doc-wide --detail balanced in the active project theme with a fidelity ledger.

Memory

Extension page · package README

Command	When and example
/speckit-memory-init	Once: Configure main as this sample application's merge branch and register its real test commands and covered paths.
/speckit-memory-prepare	After implementation: Queue specs/412-refund-approval for eligibility checking after merge.
/speckit-memory-run	Explicit selection: specs/412-refund-approval Archive this verified, fully completed feature.
/speckit-memory-session	Next local session: Inspect interrupted transactions and process approved pending archives after merge.
/speckit-memory-enable	Once per concrete policy/implementation: Present the configured branch, checks, hooks, and guards for owner review before enabling automatic mode.
/speckit-memory-impact	Before a new spec: Consult current refund constraints and settlement decisions relevant to this proposed change.
/speckit-memory-status	Inspect: Show policy approval, queued refund work, writer state, and recovery phase.

Native Memory utilities do not register additional agent skills. In the Memory 2.2.0 package, archive.py preflight --spec <path> --check <name> exposes early guards, and archive.py inspect --run <id> --view checks --max-bytes 16384 returns bounded records. See Memory.

Progress

Extension page · package README

Command	When and example
/speckit-progress-init	Once per feature, after Tasks: Create the progress report for specs/412-refund-approval and bind this session.
/speckit-progress-refresh	Forced snapshot only: Write a final progress snapshot for specs/412-refund-approval.
/speckit-progress-status	Any time: Show the one-line progress status.
/speckit-progress-theme	Once: Use the cobalt theme for the progress report.
/speckit-progress-export	On request: Export the progress report as Markdown.

The hook handler speckit.progress.hook is internal and is not registered as a skill. Spec Kit's event dispatcher runs it for the five hook events; do not invoke it.

Workflow utilities from the shell

The five utilities do not claim or complete a stage. Affected verification requires the project's ci.gate.affected_command and verify_command, writes local results, and does not count as remote CI evidence. CI Report measures job durations and wall-clock span, not a dependency-aware critical path. Worker Brief refuses an oversized brief unless explicitly allowed.

Gate Explain's auto-fix applies only to eligible evidence-only drift with a real reason and unchanged|changed assessment. Apply Pending is a dispatcher operation: it previews by default, refuses active claims and delegated mutation, and may stale dependent receipts. Follow the returned recovery recipe. Utility source contracts.

The corresponding CLI recipes run from the consumer root. Substitute its repository and base branch:

python .specify/extensions/workflow/scripts/verify_affected.py --root . --feature specs/412-refund-approval --base-ref origin/main
python .specify/extensions/workflow/scripts/ci_report.py --repository example-org/booking-app --workflow ci.yml --limit 10
python .specify/extensions/workflow/scripts/gate_explain.py --root . --feature specs/412-refund-approval --base-ref origin/main
python .specify/extensions/workflow/scripts/worker_brief.py --root . --feature specs/412-refund-approval --task T012
python .specify/extensions/workflow/scripts/apply_pending.py --root . --feature specs/412-refund-approval

Runtime commands for the front half

These run from the consumer root inside the managed lifecycle; the dispatcher calls them, and you can run them to diagnose or recover:

# Inspect an interrupted owner, even after its branch was deleted
python .specify/extensions/workflow/scripts/workflow.py status --feature specs/412-refund-approval
# After inspecting writes and confirming the owner stopped, release its exact claim
python .specify/extensions/workflow/scripts/workflow.py recover --feature specs/412-refund-approval --token <recorded-token> --reason "Owner stopped; inspected local and remote writes"
# Lite tier (no Analyze stage): run lint before completing Plan; Plan's complete runs workflow:lint itself
python .specify/extensions/workflow/scripts/lint.py --feature specs/412-refund-approval --json
# Standard tier: Analyze runs as lint; --record completes the claimed Analyze stage, only when clean
python .specify/extensions/workflow/scripts/lint.py --feature specs/412-refund-approval --json
python .specify/extensions/workflow/scripts/lint.py --feature specs/412-refund-approval --record --token <active-token>
# Re-record stages after an upstream document changed (no active claim)
python .specify/extensions/workflow/scripts/workflow.py revalidate-upstream --feature specs/412-refund-approval --through plan --plan
python .specify/extensions/workflow/scripts/workflow.py revalidate-upstream --feature specs/412-refund-approval --through plan --receipt <stages.json>
# Render the spec from the approved Scope analysis (single leaf, approved analysis only)
python .specify/extensions/workflow/scripts/scope/scope.py render-spec 412 --analysis <analysis.json> --feature specs/412-refund-approval --apply
# Answer the first clarification round in the session (issue creator only)
python .specify/extensions/workflow/scripts/scope/clarification.py publish 412 --analysis <analysis.json> --answers <answers.json> --apply
# Publish one phase's task issues under phase-lazy
python .specify/extensions/workflow/scripts/task_issues.py --feature specs/412-refund-approval --parent 412 --phase "Phase 2: Refund approval" --apply --summary

scope.py gate, approve, publish and bind accept --snapshot <inspect output> and reuse it while it matches the live issue and is within scope.board_cache_seconds (snapshot_reused in their output). The operating guide explains the policy keys these depend on.

Internal skills and overlays

Workflow also exposes the local Memory handoff from the consumer root:

python .specify/extensions/workflow/scripts/workflow.py memory-handoff --transition session
python .specify/extensions/workflow/scripts/workflow.py memory-handoff --transition execute --feature specs/412-refund-approval --check product
python .specify/extensions/workflow/scripts/workflow.py memory-handoff --transition postmerge --feature specs/412-refund-approval --report verified-merge.json

Use an existing configured check name. Honor the exit, pending reason and returned registered action; a returned action does not mean the archive ran. The Memory handoff contract defines the exact post-merge binding and recovery order.

These skills ship inside extensions; they are not additional npx skills installs.

Skill source	Owner and use in the refund example
assure	Assure Analyze/Document route QA analysis and test walkthroughs.
scope-analyst	Scope Run owns issue evidence, prerequisite checks, effort, and decomposition.
github-clarification	Clarify/Brainstorm reread issue 412's human answers and preserve binding.
speckit-workflow	Workflow commands claim stages, invoke their references, and validate receipts.
speckit-scope alias	The short entry routes issue 412 into the managed dispatcher.
Bridge alias	Routes continuation to its current owner and prevents a competing executor.
user-manual	Manual commands own module discovery and incremental refund documentation.
user-manual references	Loaded only when a task needs them: api-docs.md (safe refund contracts), release-docs.md (release and migration evidence), ui-screenshots.md (approved/refused refund states), preview-publishing.md (the approved private preview).
Illustrate package skill	Generate/export useful refund diagrams through extension commands.
Delegate Task (vendored)	Workflow dispatches bounded worker tasks through this driver, vendored from sanduq-skills.

Canonical Workflow, Scope Gate, and Scope Brainstorm presets prepend policy to provider commands; Clarify and SuperSpec Brainstorm are replaced outright by pointers to Scope's GitHub clarification skill. Installing an overlay does not install SuperSpec or Bridge. The worked lifecycle covers every overlay and its consistent prompt. Contributing explains where to contribute.

Hooks

Which commands run automatically, and when, is in the generated hooks reference.