/comet-verify runs your tests and build commands, checks that implementation matches design, produces a verification report saved to disk, and then asks you to decide what to do with the feature branch. Nothing advances to archive until both the report exists and the branch is handled — the guard enforces both as hard prerequisites.
Trigger
Run/comet-verify directly, or let /comet auto-dispatch when all tasks in tasks.md are checked. Both OpenSpec and Superpowers contribute to this phase.
Owner
Both OpenSpec and Superpowers — OpenSpec’sopenspec-verify-change skill handles full spec-coverage verification for larger changes; Superpowers’ finishing-a-development-branch skill handles the branch lifecycle. Lightweight verification (small changes) runs inline without loading an external skill.
What Happens
Scale assessment determines verification mode
The AI runs a scale assessment that counts tasks, delta specs, and changed files to determine whether this is a lightweight (small change) or full verification. The result is written to
.comet.yaml as verify_mode. If every task was committed individually, the AI also checks the base-ref commit range for a more accurate picture of change scope.Tests and build commands run
The AI executes your project’s build and test commands. It reads
verify_command and build_command from .comet.yaml first; if neither is set, it falls back to auto-detection (npm run build, Maven, Cargo, etc.). Output from failed commands is printed as evidence.- Lightweight verification checks: all tasks complete, changed files match task descriptions, build passes, tests pass, no obvious security issues (hardcoded keys, unsafe operations).
- Full verification additionally loads
openspec-verify-changeand checks: implementation vs.design.mdhigh-level decisions, implementation vs. Design Doc (technical RFC), all delta spec acceptance scenarios pass,proposal.mdgoals satisfied, and consistency between delta spec and Design Doc.
Verification report is produced and saved
Verification conclusions are written to a report file at
docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md. The path is recorded in .comet.yaml as verification_report. This file must exist on disk — the guard checks the path, not just the field value.You choose how to handle the branch (blocking pause)
The AI loads the Superpowers
finishing-a-development-branch skill and presents your branch-handling options. You must choose explicitly — the AI will not select based on recommendations or current branch state:- Merge to main branch locally
- Push and create a PR
- Keep the branch (handle later)
- Discard work
branch_status: handled written to .comet.yaml.Guard validates evidence and advances state
The phase guard checks two hard prerequisites before allowing the transition to archive:
verification_reportpoints to an existing filebranch_status: handled
.comet.yaml to phase: archive, sets verify_result: pass, and records verified_at.Verify Result Values
Theverify_result field in .comet.yaml reflects the current verification state:
| Value | Meaning |
|---|---|
pending | Verification has not yet completed (initial state after build) |
pass | All verification checks passed and the guard has confirmed evidence |
fail | Verification failed; the workflow has rolled back to phase: build for fixes |
Verification Failure Handling
Required Evidence
The guard enforces two conditions as hard prerequisites beforeverify-pass can be recorded:
verification_reportmust point to a file that actually exists on disk at the recorded pathbranch_status: handledmust be set in.comet.yaml
Spec Drift Handling
If full verification finds that the delta spec was modified during Phase 3 but the Design Doc doesn’t reflect those changes, the AI pauses and asks you to choose one of three options:| Option | Action |
|---|---|
| A — Document the divergence | Append an “Implementation Divergence” section to the Design Doc explaining why the implementation drifted. This is a verify-phase artifact and does not re-trigger dirty-worktree checks. |
| B — Fix the Design Doc | Roll back to build phase; the Superpowers brainstorming skill updates the Design Doc and delta spec to reflect the actual implementation. |
| C — Accept the deviation | Confirm the drift is acceptable and continue. The Design Doc will be marked superseded-by-main-spec during archiving. |
Context Compaction Recovery
The verify phase may trigger context compaction, especially during full verification of large changes. To recover, run:verify_result is already pass and branch_status is handled, the recovery action will direct you straight to the guard for transition.