verify

name	verify
description	Use when the user explicitly invokes /verify or asks for an independent review of completed plan work, diff evidence, or a finished BDC change before shipping.
when_to_use	Use after /execute or direct work has produced a diff and verification evidence. Do not use to run the plan's test command; /execute owns fresh verify execution. If the user says 别走流程, 直接做, 简单点, or 不走地图, skip this skill and answer directly unless safety review is required.
argument-hint	[plan-or-scope]
user-invocable	true
allowed-tools	["Bash","Task","Read","Grep"]

/verify — Independent Review Gate

Step 0: Escape Hatch

If the user says 别走流程, 直接做, 简单点, or 不走地图, do not force /verify. Acknowledge once and do the smallest direct action.

Exception: do not bypass safety review for auth, secrets, PII, database, deploy, public upload, or destructive changes.

Step 0.5: Project Goal Check

If PROJECT_GOAL.md exists in the current project root or plan target root, read it before review. If the diff conflicts with current_phase, exit_criteria, or out_of_scope, return REQUEST_CHANGES unless the owner explicitly accepts the conflict.

Contract

/verify is a review gate, not the test runner.

It must inspect the current diff, relevant plan/spec, expected files, and verification evidence, then return one of:

• APPROVE
• REQUEST_CHANGES

Every verdict must include Verified HEAD: <short-sha> from git rev-parse --short HEAD when inside a git repository. /ship treats a verdict as stale if HEAD changes.

For plan-driven work, /verify must use an independent reviewer context when available. The orchestrating session gathers evidence and merges the report; it does not silently approve its own work.

Process

1. Identify scope:
   • active plan if one exists
   • otherwise current git diff
2. Gather evidence:
   • git diff --stat
   • relevant plan step or task spec
   • latest verify command output if available
   • expected files / scope boundaries when plan-driven
3. Review for:
   • requirement mismatch
   • scope drift
   • missing tests or weak oracle
   • safety issues
   • release blockers
4. Return a terse verdict with blockers first.

Fan-Out Mode (--deep)

Use this mode when the user invokes /verify --deep, or when a future risk classifier routes high-risk completed work into deep review.

/verify --deep runs three read-only specialist reviewers and merges their reports:

• verify-code-reviewer
• verify-test-engineer
• verify-security-auditor

The verify-* agents are the executable layer. Their contracts live in ${BDC_HOME:-$HOME/.bdc}/standards/personas/*.md. Do not spawn general-purpose for this path and do not create or use same-name user-level agents such as code-reviewer.

Use this exact contract map:

Agent	Contract
verify-code-reviewer	${BDC_HOME:-$HOME/.bdc}/standards/personas/code-reviewer.md
verify-test-engineer	${BDC_HOME:-$HOME/.bdc}/standards/personas/test-engineer.md
verify-security-auditor	${BDC_HOME:-$HOME/.bdc}/standards/personas/security-auditor.md

Phase A — Parallel Spawn

Dispatch all three Task calls in the same assistant turn so they can run in parallel. Each subagent prompt must include:

• project/root path and current branch
• Verified HEAD: <short-sha>
• review scope and git diff --stat
• relevant plan/spec and expected files when present
• latest /execute verify evidence when available
• instruction: read the matching ${BDC_HOME:-$HOME/.bdc}/standards/personas/*.md contract before analysis
• instruction: no file edits, no write commands

Phase B — Merge

The main /verify session merges returned reports. Any of these makes the merged verdict REQUEST_CHANGES:

• code reviewer returns REQUEST_CHANGES
• test engineer returns GAPS_FOUND or NEEDS_RED_FIRST
• security auditor returns REQUEST_CHANGES
• any subagent cannot read its persona contract
• any subagent edits files or attempts writes

After all three reports return, write the durable verify record with:

bdc verify --deep --subreport-dir <dir-containing-the-three-json-reports> --evidence "<summary>"

Do not call bdc verify --deep without subreports as an approval path. Without --subreport-dir, the CLI only writes host review request files and returns REQUEST_CHANGES so the orchestrator cannot fabricate empty approvals.

Phase C — Output

Return one merged report:

Verdict: APPROVE | REQUEST_CHANGES
Verified HEAD: <short-sha>
Blockers:
- ...
Required fixes:
- ...
Test gaps:
- ...
Security findings:
- ...
Evidence reviewed:
- ...
Subreports:
- verify-code-reviewer: APPROVE | REQUEST_CHANGES
- verify-test-engineer: SUFFICIENT | GAPS_FOUND | NEEDS_RED_FIRST
- verify-security-auditor: APPROVE | REQUEST_CHANGES

Cross-Model Boundary

• Writer family and reviewer family should differ for coding/chore/docs plan work.
• Static family checks belong in plan-lint.sh using ${BDC_HOME:-$HOME/.bdc}/standards/model-router.md.
• Do not perform a runtime "current session family" check. Because: the current session is the orchestrator, not the reviewer.
• Independent subagent context is not the same thing as cross-model review. Use model-router.md role/family data when family distinction matters.

Rules

• Do not run the implementation verify command as a substitute for review. Because: /execute already owns fresh verification evidence.
• Do not approve a diff you have not inspected. Because: review without diff evidence is a self-report.
• Do not let the implementing context silently approve its own work when an independent reviewer is available. Because: confirmation bias is the failure mode this gate exists to catch.

Verification

• Inspect git diff --stat and the relevant diff.
• Inspect the plan/spec when one exists.
• Inspect fresh verify evidence when available.

Red Flags

• The same context that wrote the change returns APPROVE without independent review.
• The verdict ignores expected files or plan stop conditions.
• The report has no blockers section and no evidence list.

Common Rationalizations

Rationalization	Response
"I already tested it, so review is redundant."	Do not skip review for meaningful changes. Incident: standards/debugging.md 2026-04-04 says written rules were violated for weeks until automated/review gates enforced them.
"Opus vs Sonnet is cross-model enough."	Not for family checks. This is an advisory rule from model-router.md: same-family models do not provide the same independence as Anthropic vs Codex/Qwen.

Output

Verdict: APPROVE | REQUEST_CHANGES
Verified HEAD: <short-sha>
Blockers:
- ...
Required fixes:
- ...
Test gaps:
- ...
Security findings:
- ...
Evidence reviewed:
- ...