review-changes

name	review-changes
description	Review a ticket's branch diff freshly and independently — spec conformance, tests, correctness, quality, security, docs — producing blocking findings that must be fixed before a PR. Use after implement and before open-pr, or when the user asks to review changes / check the diff before shipping.
model	opus
effort	high
allowed-tools	["Read","Grep","Glob","Bash"]
argument-hint	<ticket id>
triggers	["review the changes","review this diff","check before shipping","is this ready to merge"]
tags	["review","verify","quality","security","pipeline"]

Review Changes

Judge the change as a fresh reviewer, not as its author. This is pipeline step 4 (plan → track → implement → review → pr) and it IS the quality gate — nothing opens a PR until this passes. Reviewing is judgment-heavy — strong model, high effort.

Start

Read the diff and the plan fresh. Do not trust the implementer's narrative — re-derive correctness from the code and re-run the checks yourself.

node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" show <ticket-id>
DEFAULT=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|origin/||' || echo main)
git diff "$DEFAULT...HEAD"
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review in_progress

Dimensions (each produces blocking findings)

1. Plan conformance — every planned item implemented as specified; note deviations.
2. Tests — re-run the full suite (don't trust a prior run). New tests genuinely exercise the acceptance criteria, not just line coverage.
3. Correctness — behavior is right; edge cases, error paths, and inputs handled.
4. Quality — readable, no dead code, no debug leftovers, no needless complexity (route obvious bloat to code-reducer).
5. Security — no injected vulnerabilities, no secrets committed, input/authz safe.
6. Docs — every affected doc updated and consistent with the code.

Verdict

• Zero findings → pass. Mark it and unblock the PR.
• Any finding → block. List each finding with file:line, severity, and the fix. Hand back to implement to remediate, then re-review. Do not open a PR with open blocking findings.

# pass:
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review done --note "0 findings"
# findings:
node "${CLAUDE_PLUGIN_ROOT}/hooks/pipeline.mjs" step <ticket-id> review failed --note "<n> findings: <summary>"
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep "<ticket-id> review: <key finding>" --kind note --tags review

Rules

• Fresh judgment. Re-read, re-run — the diff and the checks are the truth.
• All findings block. There is no "minor, ship it" here; either it's fine or it's a finding with a fix.
• Never pass by weakening the check (lowering a threshold, skipping a test).
• Be specific. Every finding needs a location and a concrete remedy.

Finish

Report pass/fail, the findings (or "none"), and the next step: open-pr on a pass, or back to implement on findings. Under ship, return the verdict + findings count.