Snap Review

Deep reviewer pass from diff truth. Read-only. Findings first. Bias toward negative discovery: bugs, regressions, broken contracts, missing tests, bad patterns, maintainability traps, architectural drift, security/privacy risk, performance risk, and merge blockers.

Workflow

1. Source: Use PR from context, current branch, or ask. Prefer gh pr view for title, body, base/head refs, changed files, commits, status checks, review state, comments, review bodies, and review threads. Use gh pr diff or git diff base...head for patch truth. Parse linked refs/URLs from PR body + comments/reviews, including #123, owner/repo#123, full GitHub issue URLs, and closing-keyword forms like closes, fixes, resolves. Fetch linked issue bodies + comments; parent PRD/epic links count too. Recurse through material scope/acceptance/blocker links; normalize + dedupe canonical refs; route inaccessible/conflicting context to Risks / Unknowns.
2. Explore: Read PR/issue intent first, then changed code, adjacent contracts, tests, fixtures, docs, and runtime seams. Run read-only validation commands only when they sharpen review confidence.
3. Review: Run an in-depth negative review, not a skim. Hunt defects, regressions, bad patterns, missing tests, brittle seams, architectural drift, security/privacy risk, performance risk, and maintainability debt with concrete impact. Check behavior against PR intent + linked issues + existing contracts + repo instructions (AGENTS.md, CLAUDE.md, local conventions). Trace changed paths through callers, data shape, validation, errors, persistence, concurrency, auth, compatibility, deployment/runtime behavior, tests, and architectural boundaries.
4. Architecture pass: Explicitly inspect deep-module shape and hexagonal boundaries before reporting. Look for shallow wrappers, pass-through layers, anemic public APIs, domain leakage into adapters, adapter/vendor/framework/database shapes crossing into business logic, duplicated policy, and seams that make future changes harder. File findings when the drift creates maintainability, correctness, testability, or future-change risk.
5. Report: Output findings first. No code edits. No commits. No pushes. After the review is complete, ask: Post this review to the PR?
6. Post: If user approves, read references/template.md, self-detect harness identity, append attribution, then post the same review body to the GitHub PR. Capture the posted review/comment URL and return it to the user. Do not change findings while posting.

Output

Findings-first review shape. For GitHub posting, use references/template.md.

• Findings — ordered by severity. Each item includes Severity, Location, Issue, Impact, Evidence, Recommendation.
• Missing Tests — only coverage gaps that would catch a material regression.