Spec Flow

Spec flow

Lightweight spec loop for controlled task-by-task work.

Loop: plan one slice → execute one task → checkpoint or close → repeat.

specctl owns state. Do not edit task status or .spec/SESSION.yaml by hand.

Read first

• references/method.md for artifact shapes, planning rules, task quality, and mini-interview guidance.
• references/specctl-commands.md for CLI commands.

State model

• .spec/tasks/TASK-*.md — executable vertical slices. Required for work.
• .spec/epics/EPIC-*.md — optional group for multi-task plans.
• .spec/reqs/REQ-*.md — optional WHY/WHAT context for ambiguous work.
• .spec/SESSION.yaml — active task, step, base commit.
• .spec/PROGRESS.md — append-only activity log.

Task states: todo, in-progress, done.

Common flows

New project:

scripts/specctl init

Then plan the first executable slice. Do not build a full backlog unless the user asks.

Existing project:

1. Inspect current code and project instructions.
2. Create the smallest task that can be verified.
3. Link optional REQ/EPIC context only when it reduces ambiguity.

Stop and resume:

scripts/specctl checkpoint --message "<where to resume>"
scripts/specctl session handoff

Iterate:

scripts/specctl ready
scripts/specctl start TASK-<id>
# implement + verify
scripts/specctl done TASK-<id> --summary "..." --tests "..."

Modes

Orient

Use when the user asks for status, next task, resume, health, or what to do next.

scripts/specctl status
scripts/specctl ready
scripts/specctl session handoff
scripts/specctl validate

Report active session, next ready task, validation issues, and the smallest next action.

Plan

Use when the user has an idea, requirement, bug, or project gap and wants an executable plan.

1. Run scripts/specctl init.
2. Check status/session before changing files.
3. Ask 3-5 questions only if the slice is unclear.
4. Optionally scan the codebase for relevant files and patterns.
5. Draft the smallest useful artifact set:
   • one clear slice → one TASK-*
   • several slices → one EPIC-* plus tasks
   • unclear WHY/WHAT → one REQ-* first
6. Show the proposed plan; obtain approval if the user has not already authorized that scope.
7. Write with scripts/specctl new task <slug> when possible, then edit details.
8. Run scripts/specctl validate and scripts/specctl ready.

Do not write implementation code in plan files.

Execute

Use when the user wants to work, continue, or implement a task.

1. Run scripts/specctl status and scripts/specctl session show.
2. Resume an existing matching session when the user asks to continue. Ask before replacing a conflicting session.
3. Select with scripts/specctl ready or verify the named task with scripts/specctl show TASK-<id>.
4. Start with scripts/specctl start TASK-<id>.
5. Make a short implementation plan; obtain approval if that implementation scope is not already approved.
6. Implement only the approved task.
7. Run project-appropriate checks from project instructions and changed files.
8. Show scoped diff or scripts/specctl session handoff before close.
9. Close with scripts/specctl done ... or checkpoint with scripts/specctl checkpoint.

Checkpoint or close

Use when the user stops, switches context, or finishes.

Checkpoint:

scripts/specctl checkpoint --message "<where to resume>"

Close:

scripts/specctl done TASK-<id> \
  --summary "<what changed>" \
  --tests "<checks passed or not run: reason>" \
  --files "<changed files or none>" \
  --commits "<sha or none>"

specctl done needs --summary and --tests unless the user explicitly approves --force. These fields record the caller's evidence; the helper does not execute or certify checks. Name commands and results honestly, including skip reasons, and satisfy project gates before closing.

Guardrails

• One task is the execution unit.
• Checkpoint before stopping or switching.
• Keep work inside the approved task.
• File follow-up tasks instead of expanding scope.
• Verification is adaptive; do not assume every project has make.
• Authorization persists for the agreed plan and implementation scope; do not repeat approval at each mechanical step. Ask when scope changes or before forcing state or clearing a conflicting session.

Output

## Spec flow

Mode: orient | plan | execute | checkpoint | close
Task: <TASK-id or none>
Status: <ready | in-progress | checkpointed | done | blocked>
Evidence: <commands/tests/checks or skipped reason>
Next: <one command or action>

Failure handling

• No .spec/: run or offer scripts/specctl init.
• Active session conflicts: show handoff and ask before switching.
• No ready tasks: show blockers; plan new work or finish blockers.
• Validation fails: fix the smallest artifact issue before work.
• Verification fails: fix within scope, checkpoint, or stop; do not mark done.