Verifying

---
name: verifying
description: Post-implementation plan verification. Cross-references plans against actual changes for completeness and accuracy.
---

# Verifying

You are performing a post-implementation audit of a plan, cross-referencing it against actual changes to ensure nothing was missed, nothing is stale, and the implementation matches what was planned.

## Working Agreement

**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions.

**All read/research/validation work goes through sub-agents** — default to `run_in_background: true`.

File-review is on by default (unless Autopilot) — invoke it on the verification report when ready.

## When to Use

This skill activates when:
- User invokes `/verify-plan` command
- The implementing skill offers verification at completion
- User asks to audit or verify a completed plan

## Autonomy Mode

At the start of verification, adapt your interaction level based on the autonomy mode:

| Mode | Behavior |
|------|----------|
| **Autopilot** | Run all checks, update plan, report summary at end |
| **Critical** (Default) | Ask about discrepancies and blocking items |
| **Verbose** | Walk through each check, confirm interpretation |

The autonomy mode is passed by the invoking command. If not specified, default to **Critical**.

## Process Steps

### Step 1: Load Plan

Read the plan fully. If no path provided:
1. Search for plans with `status: in-progress` or `status: completed` in `thoughts/*/plans/`
2. If multiple found, use **AskUserQuestion** to let the user choose
3. If none found, report and stop

### Step 2: Checkbox Audit

Parse all `- [ ]` and `- [x]` items in the plan. Report:

| Metric | Description |
|--------|-------------|
| Total items | Count of all checkbox items |
| Checked items | Count of `- [x]` items |
| Unchecked Automated Verification | Items under `#### Automated Verification:` still unchecked |
| Unchecked Automated QA | Items under `#### Automated QA:` still unchecked |
| Unchecked Manual Verification | Items under `#### Manual Verification:` still unchecked |

Flag any Automated Verification or Automated QA items that are still unchecked — these are expected to be checked by the implementing/phase-running skills.

### Step 3: Git Diff Correlation

Check the plan's frontmatter for a `git_commit` field.

**If `git_commit` exists:**
1. Run `git diff <git_commit>..HEAD --name-only` to get changed files
2. Extract all file paths mentioned in the plan's "Changes Required" sections
3. Compare and flag:
   - **Unexpected changes**: Files changed that aren't mentioned in the plan
   - **Missing implementation**: Files mentioned in the plan that weren't changed

**If `git_commit` does not exist:**
- Skip this step with a note: "No git_commit in plan frontmatter — skipping git diff correlation"

**If on a different branch than the plan:**
- Note the branch difference and proceed with best-effort comparison

### Step 4: Scope Verification

Read the "What We're NOT Doing" section of the plan. Search the git diff for evidence of scope creep:
- Look for files or patterns related to explicitly out-of-scope items
- Check if any commits reference out-of-scope functionality

Be conservative here — flag only clear scope violations, not borderline cases.

### Step 5: Success Criteria Re-run

For each phase's Success Criteria, re-run both runnable buckets:

**Automated Verification** (commands):
1. Extract the commands from each checkbox item
2. Re-run each command
3. Report pass/fail

**Automated QA** (agent-driven scenarios):
1. For each scenario, re-execute via the appropriate tool (browser-use, screenshot diff, CLI walkthrough)
2. Report pass/fail per scenario

**Edge cases (apply to both):**
- Skip items that reference files or paths that clearly no longer exist
- If an item fails, capture the error/output for the report
- Don't re-run destructive or state-modifying items — only read-only checks
- If a phase's QA Spec links to an external QA doc, note its path in the report; re-running that doc is the qa skill's job, not this one's

**OPTIONAL SUB-SKILL:** When a verification command is missing, flaky, or so verbose that re-running it pollutes the report, invoke `desplega:script-builder` to wrap it into a re-runnable script. The generated script enforces PASS/FAIL + `/tmp` log output, so future verifications get a clean single-line result instead of a wall of stdout. The wrapped command stays in the plan; subsequent verifications discover the new script via the `<important if>` block script-builder adds to CLAUDE.md.

### Step 6: Plan Freshness Check

Compare phase descriptions against actual implementation:
- Are file paths in the plan still accurate?
- Do the "Changes Required" descriptions match what was actually done?
- Were any phases adapted significantly during implementation?

Flag phases where the description no longer matches reality as stale.

### Step 7: Verification Report

Present findings categorized as:

| Category | Meaning | Examples |
|----------|---------|----------|
| **Blocking** | Must be resolved before plan can be marked complete | Unchecked automated items, failing success criteria |
| **Warning** | Should be reviewed but don't block completion | Unexpected files changed, potential scope creep |
| **Info** | Informational, no action needed | Stale descriptions, minor mismatches, branch differences |

### Step 8: Status Update

If all blocking items are resolved:
- Offer to set plan `status: completed` in frontmatter
- Update `last_updated` and `last_updated_by` fields

If blocking items remain:
- List them clearly and suggest next steps

## Learning Capture

**OPTIONAL SUB-SKILL:** If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using `desplega:learning` to capture them via `/learning capture`. Focus on learnings that would help someone else in a future session.

## Integration with Reviewing Skill

After verification completes, use **AskUserQuestion** with:

| Question | Options |
|----------|---------|
| "Verification complete. What's next?" | 1. Run QA (→ `/qa`), 2. Run review (→ `/review`), 3. Done |

## Review Integration

File-review is on by default (unless Autopilot):
- After the verification report, invoke `/file-review:file-review <plan-path>` for inline human comments
- Process feedback with the `file-review:process-review` skill