/review

name: review
description: "Verify the build matched the plan. Automated checks + walkthrough with you."
allowed-tools: Read, Write, Bash, Glob, Grep, Task, AskUserQuestion, Skill
argument-hint: "<phase-number> [--auto-fix] [--teams] [--model <model>] [--auto]"

**STOP — DO NOT READ THIS FILE. You are already reading it. This prompt was injected into your context by Claude Code's plugin system. Using the Read tool on this SKILL.md file wastes ~7,600 tokens. Begin executing Step 1 immediately.**

/pbr:verify-work — Phase Review and Verification

Reference: `@references/verification-overrides.md` for verification override handling and gap acceptance.

**References:** `@references/questioning.md`, `@references/ui-brand.md`

You are the orchestrator for `/pbr:verify-work`. This skill verifies that what was built matches what was planned. It runs automated three-layer checks against must-haves, then walks the user through a conversational UAT (user acceptance testing) for each deliverable. Your job is to present findings clearly and help the user decide what's good enough versus what needs fixes.

Context Budget

Reference: `skills/shared/context-budget.md` for the universal orchestrator rules. Reference: `skills/shared/agent-type-resolution.md` for agent type fallback when spawning Task() subagents.

Additionally for this skill:

• **Minimize** reading subagent output — read only VERIFICATION.md frontmatter for summaries. Exception: if `context_window_tokens` in `.planning/config.json` is >= 500000, reading full VERIFICATION.md bodies is permitted when gap details are needed for inline presentation.

Step 0 — Immediate Output

**Before ANY tool calls**, display this banner:

╔══════════════════════════════════════════════════════════════╗
║  PLAN-BUILD-RUN ► REVIEWING PHASE {N}                        ║
╚══════════════════════════════════════════════════════════════╝

Where `{N}` is the phase number from `$ARGUMENTS`. Then proceed to Step 1.

Multi-Session Sync

Before any phase-modifying operations (writing VERIFICATION.md, updating STATE.md/ROADMAP.md), acquire a claim:

acquireClaim(phaseDir, sessionId)

If the claim fails (another session owns this phase), display: "Another session owns this phase. Use `/pbr:progress` to see active claims."

On completion or error (including all exit paths), release the claim:

releaseClaim(phaseDir, sessionId)

Prerequisites

• `.planning/config.json` exists
• Phase has been built: SUMMARY.md files exist in `.planning/phases/{NN}-{slug}/`

Event-Driven Auto-Verification

When `features.goal_verification` is enabled and depth is "standard" or "comprehensive", the `event-handler.js` hook automatically queues verification after executor completion. The hook writes `.planning/.auto-verify` as a signal file. The build skill's orchestrator detects this signal and spawns the verifier agent.

**This is additive**: `/pbr:verify-work` can always be invoked manually regardless of auto-verification settings. If auto-verification already ran, `/pbr:verify-work` re-runs verification (useful for re-checking after fixes).

---

Argument Parsing

Parse `$ARGUMENTS` according to `skills/shared/phase-argument-parsing.md`.

| Argument | Meaning | |----------|---------| | `3` | Review phase 3 | | `3 --auto-fix` | Review phase 3, automatically diagnose and create gap-closure plans for failures | | `3 --teams` | Review phase 3 with parallel specialist verifiers (functional + security + performance) | | `3 --model opus` | Use opus for all verifier spawns in phase 3 (overrides config verifier_model) | | `3 --auto` | Review phase 3 with auto mode — skip interactive UAT, auto-accept if verification passes | | (no number) | Use current phase from STATE.md |

---

Orchestration Flow

Execute these steps in order.

---

Step 1: Parse and Validate (inline)

1. Parse `$ARGUMENTS` for phase number and `--auto-fix` flag

• If `--model <value>` is present in `$ARGUMENTS`, extract the value (sonnet, opus, haiku, inherit). Store as `override_model`. When spawning verifier Task() agents, use `override_model` instead of the config-derived `blob.verifier_model`. If an invalid value is provided, display an error and list valid values.
• If `--auto` is present in `$ARGUMENTS`: set `auto_mode = true`. Log: "Auto mode enabled — skipping interactive UAT walkthrough"

2. **CRITICAL — Init first.** Run the init CLI call as the FIRST action after argument parsing:

   node plugins/pbr/scripts/pbr-tools.js init verify-work {N}

Store the JSON result as `blob`. All downstream steps MUST reference `blob` fields instead of re-reading files. Key fields: `blob.phase.dir`, `blob.phase.name`, `blob.phase.goal`, `blob.phase.plan_count`, `blob.phase.completed`, `blob.verifier_model`, `blob.has_verification`, `blob.prior_attempts`, `blob.prior_status`, `blob.summaries`. **CRITICAL (hook-enforced): Write .active-skill NOW.** Write the text "review" to `.planning/.active-skill` using the Write tool. 3. Resolve depth profile: run `pbr-tools config resolve-depth` to get the effective feature/gate settings for the current depth. Store the result for use in later gating decisions. 4. Validate using blob fields:

• If `blob.error`: display error and stop
• If `blob.summaries` is empty: display "Phase hasn't been built yet" error (see error box below)
• If `blob.phase.plan_count === 0`: display "Phase has no plans" error (see error box below)

5. If no phase number given, use `blob.phase.number` (already resolved from STATE.md by init) 6. If `.planning/.auto-verify` signal file exists, read it and note the auto-verification was already queued. Delete the signal file after reading (one-shot, same pattern as auto-continue.js). 7. Resolve verification depth:

• Run: `pbr-tools trust-gate {N}`
• Parse the JSON response to get `depth` (light/standard/thorough)
• Log: "Verification depth: {depth} (trust-based)"
• Store as `ve