Comet Phase 4: Verification and Wrap-up (Verify)

Prerequisites

Code has been submitted (Phase 3 completed)
All tasks in tasks.md have been completed

Steps

0. Entry Check

Perform entry verification:

bash

COMET_SEARCH_ROOTS=("." "$HOME/.claude/skills" "$HOME/.codex/skills" "$HOME/.cursor/skills")
COMET_STATE="${COMET_STATE:-$(find "${COMET_SEARCH_ROOTS[@]}" -path '*/comet/scripts/comet-state.sh' -type f -print -quit 2>/dev/null)}"
COMET_GUARD="${COMET_GUARD:-$(find "${COMET_SEARCH_ROOTS[@]}" -path '*/comet/scripts/comet-guard.sh' -type f -print -quit 2>/dev/null)}"
bash "$COMET_STATE" check <change-name> verify

Proceed to Step 1 after passing verification. The script will output specific failure reasons if verification fails.

1. Change Scale Assessment

Perform scale assessment:

bash

bash "$COMET_STATE" scale <change-name>

The script automatically counts the number of tasks, incremental specification items, and changed files, determines whether to use light or full verification mode, and sets the verify_mode field.

Before starting verification, check and handle uncommitted changes according to the

comet/reference/dirty-worktree.md

protocol. Special handling during the verify phase:

If the dirty diff belongs to the current change and involves changes to implementation, tests, tasks, delta spec, or design doc, do not directly fix or commit during the verify phase; record the failure first and roll back to the build phase
If the dirty diff is only a product of the verify phase (e.g., draft verification report, branch handling records), you can continue to complete it in the verify phase and record the status
If the dirty diff has been implemented but not checked in tasks.md, it is considered that the build status is lagging; record the failure first and roll back to the build phase, then invoke
```
/comet-build
```
to verify the implementation, check off the tasks and submit

Roll back to build phase:

bash

bash "$COMET_STATE" transition <change-name> verify-fail

Note: If every task in the build phase has been submitted, the number of files based on the workspace diff calculated by the script may underestimate the scale of changes. In this case, you must read the

base-ref

in the plan file header and review it using the commit range:

bash

PLAN=$(bash "$COMET_STATE" get <change-name> plan)
BASE_REF=$(grep '^base-ref:' "$PLAN" 2>/dev/null | head -1 | sed 's/^base-ref: *//')
git diff --stat "$BASE_REF"...HEAD

If the commit range shows changes exceeding the light threshold (> 5 files, cross-module coordination, or delta spec with more than 1 capability), manually set to full verification:

bash

bash "$COMET_STATE" set <change-name> verify_mode full

2a. Light Verification (Small Changes)

When the scale assessment result is "small", skip

openspec-verify-change

and directly perform the following checks:

All tasks in tasks.md are completed
```
[x]
```
Changed files match the description in tasks.md (compare with tasks content using
```
git diff --stat
```
/
```
git diff --cached --stat
```
/
```
git diff --stat <base-ref>...HEAD
```
)
Compilation passes (execute the project's corresponding build command, such as
```
npm run build
```
,
```
mvn compile
```
,
```
cargo build
```
etc.)
Relevant tests pass
No obvious security issues (no hardcoded secrets, no new unsafe operations)

Pass Criteria: All 5 items are OK, no CRITICAL issues.

If Not Passed: Report failed items, record the failure and roll back to the build phase, then invoke

/comet-build

to fix.

bash

bash "$COMET_STATE" transition <change-name> verify-fail

Report Format: A simple table listing the results of the 5 checks + PASS/FAIL.

Skipped Items (not checked in light verification):

spec scenario coverage
in-depth comparison of design doc consistency
code pattern consistency suggestions
delta spec and design doc drift detection

2b. Full Verification (Large Changes)

When the scale assessment result is "large":

Immediate Action: Use the Skill tool to load the

openspec-verify-change

skill. Skipping this step is prohibited.

After loading the skill, verify according to its guidelines. Check items:

All tasks in tasks.md are completed (
```
[x]
```
)
Implementation complies with design decisions in design.md
Implementation complies with brainstorming design documents
All capability specification scenarios pass
Goals in proposal.md are met
No contradictions between delta spec and design doc (if there are incremental spec modifications in the Build phase, check whether the design doc has corresponding records)
Associated design documents in
```
docs/superpowers/specs/
```
are locatable (files exist and are relevant to the current change)

If verification fails: Report missing items, record the failure and roll back to the build phase, then invoke

/comet-build

to supplement.

bash

bash "$COMET_STATE" transition <change-name> verify-fail

Spec Drift Handling:

If contradiction is found in check item 6 (delta spec has content but not reflected in design doc), prompt the user:
- Option A: Append an "Implementation Divergence" section in the design doc to record the reason for deviation
- Option B: Roll back to the Build phase, supplement brainstorming and update the design doc
- Option C: Confirm the deviation is acceptable and continue verification (the design doc will be marked as
```
superseded-by-main-spec
```
  during archiving)

3. Wrap-up (Superpowers)

Immediate Action: Use the Skill tool to load the

superpowers:finishing-a-development-branch

skill. Skipping this step is prohibited.

superpowers:finishing-a-development-branch

is unavailable, stop the process and prompt to install or enable the Superpowers skill; do not replace this step with ordinary dialogue.

After loading the skill, wrap up according to its guidelines. Branch handling options:

Merge locally to the main branch
Push and create a PR
Keep the branch (handle later)
Discard work

Confirmation Items:

All tests pass
No hardcoded secrets or security issues

4. Record Verification Evidence

The verification report must be saved to disk and recorded in

.comet.yaml

; branch handling status must also be written to the status field after completion. Do not manually set

verify_result: pass

; let the guard automatically transition.

bash

mkdir -p docs/superpowers/reports
# Write the verification conclusion to the report file, for example:
# docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md

bash "$COMET_STATE" set <change-name> verification_report docs/superpowers/reports/YYYY-MM-DD-<change-name>-verify.md
bash "$COMET_STATE" set <change-name> branch_status handled

Exit Conditions

Verification report is approved
Branch has been handled
```
.comet.yaml
```
contains
```
verification_report
```
pointing to an existing verification report file
```
.comet.yaml
```
contains
```
branch_status: handled
```

Phase Guard: Run

bash "$COMET_GUARD" <change-name> verify --apply

, and after all items PASS, automatically transition to

phase: archive

via

comet-state transition verify-pass

After verification and branch handling are completed, run the guard to automatically transition:

bash

bash "$COMET_GUARD" <change-name> verify --apply

The status file will be automatically updated to

phase: archive

verify_result: pass

verified_at: YYYY-MM-DD

Automatic Transition

After meeting the exit conditions, do not wait for user input again, directly execute the next phase:

REQUIRED NEXT SKILL: Invoke the
comet-archive
skill to enter the archiving phase.

comet-verify

NPX Install

Tags

SKILL.md Content (Chinese)

Comet Phase 4: Verification and Wrap-up (Verify)

Prerequisites

Steps

0. Entry Check

1. Change Scale Assessment

2a. Light Verification (Small Changes)

2b. Full Verification (Large Changes)

3. Wrap-up (Superpowers)

4. Record Verification Evidence

Exit Conditions

Automatic Transition