spec-driven-verify

You are helping the user verify a spec-driven change before archiving.

Prerequisites

The .spec-driven/ directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run /spec-driven-init first.

Steps

1. Select the change — run node {{SKILL_DIR}}/scripts/spec-driven.js modify to list active changes. Ask which change to verify. If already specified, use it.

2. Format check — run:

   node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
   

   Report any errors (blocking) or warnings (non-blocking).

   • If the script warns that tasks.md has no ## Testing section, promote that to a CRITICAL — every change must include test tasks

3. Task completion check — run:

   node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
   

   If remaining > 0, list the incomplete tasks. These are CRITICAL issues.

4. Open questions check — read .spec-driven/changes/<name>/questions.md and scan for - [ ] Q: entries:

   • Any open (unanswered) question is a CRITICAL — implementation cannot be verified with unresolved ambiguity
   • The script also reports these as errors; treat them as CRITICALs here

5. Implementation evidence check — for each completed task in tasks.md:

   • Identify what code or files the task should have changed
   • Verify the change actually exists (read relevant files)
   • Note any tasks with no visible evidence as WARNINGs

6. Spec alignment check — read .spec-driven/specs/, .spec-driven/config.yaml, .spec-driven/changes/<name>/proposal.md, and all files in .spec-driven/changes/<name>/specs/:

   • Does the implementation match what was proposed?
   • Do the delta files in changes/<name>/specs/ accurately describe what was implemented? Empty specs/ with real behavior changes is a CRITICAL.
   • Does each delta file mirror its corresponding main spec file path? Mismatched paths mean the merge will fail.
   • Do the delta files use the standard format (### Requirement: <name>, RFC 2119 keywords, #### Scenario: blocks)? Non-conforming format is a CRITICAL — the spec format is mandatory.
   • If config.yaml has a rules field (including any fileMatch entries), check whether the implementation and artifacts comply — violations are WARNINGs
   • If proposal.md has an Unchanged Behavior section with content, verify the implementation has not violated any listed behaviors — violations are CRITICALs
   • Flag misalignments as WARNINGs or CRITICALs

7. Output a tiered report:

   CRITICAL (blocks archive):
     - [list or "none"]
   
   WARNING (should address):
     - [list or "none"]
   
   SUGGESTION (optional improvements):
     - [list or "none"]
   

8. Recommend next step:

   • If CRITICAL issues: address them before archiving
   • If only WARNINGs: ask user if they want to address them or proceed
   • If clean: suggest /spec-driven-review <name>

Rules

• Be honest — don't pass a change just because tasks are checked off
• CRITICALs are things that would make the change incorrect or incomplete
• WARNINGs are things that reduce confidence but don't necessarily block
• SUGGESTIONs are optional quality improvements