PR review

Follow ../../shared/policy.md. Run dev-skills:project-profile first. Host commands: ../../shared/references/pr-hosts.md.

1. Fetch

• PR metadata, diff, target branch (may be a stacked branch, not the default branch).
• git fetch origin <head> <base>; read full files with git show "origin/<head>:<path>" (quote the ref). Never review from the diff alone.
• Project rules: repo CLAUDE.md, CONTRIBUTING, .claude/rules/, and the profile's ### pr-review notes.
• Requirements: find ticket keys in the title, branch, description and commits. If found, run dev-skills:gather-context on the ticket; if none, review against the PR description alone.

2. Mode

• review (default): full pass, steps 3-4.
• re-review (or the user already reviewed this PR): fetch your earlier review threads and the commits pushed after your last review. No new commits and no new replies on your threads: say No new commits or replies since your review on <date>. and stop. For each of your threads: addressed / partly / not addressed / answered with a reason (judge whether the reason holds). Then review only the new diff. Do a full pass again only if the new changes are large (rewrote the approach, many new files) or touch a critical path; say which you did.

3. Verify, don't guess

• Trace every changed function's callers and the data flowing in: filters already applied upstream, callbacks/validations that normalize values, other paths that bypass the change.
• A finding needs a concrete failure scenario: inputs/state → wrong result, crash, or slowdown. No scenario, no finding.
• Test the PR description's stated assumptions against the code.
• Check acceptance criteria from the ticket: any not implemented or implemented differently?

4. Filter hard

Report only:

• Correctness bugs, data loss/corruption, race conditions, broken edge cases.
• Security/authz holes (tenant scoping, IDOR, injection, secrets).
• Requirements not met, or features that silently don't work in a reachable case.
• Performance regressions on real paths (N+1, unbounded loads, missing index for a new query, extra calls per request/loop, quadratic work on growing data), with likely scale and a cheaper alternative.
• Missing tests for a risky path the PR changes. Do not report: style, naming, refactors, polish, test nits, speculative micro-optimizations, things the author called out as deliberate limits, or a "checked and fine" list.

Output

PR <link> — <title> → <target> · Requirements: <ticket link | PR description only>
Re-review: <thread — addressed/partly/not addressed/answered> (re-review only)
Findings:
1. `file:line` — <claim>. Scenario: <...>. Fix: <...>. Test: <missing test, if relevant>
Verdict: approve | approve with nits skipped | request changes

No findings: one line saying so.

Approve without asking

When the verdict is approve and you are confident: no findings, requirements met, every risky path traced and tested, nothing you could not verify. Submit the approval yourself with no confirmation (this is the user's standing permission, so it overrides the confirmation rules in the policy for approvals only) and reply with one line: Approved <PR link>. No report, no draft comments. A failed submit: say so and stop, no retry with another tool.

If you recommend approval but something is tricky (a risky area, an assumption you could not verify, a judgment call, a behavior change worth a human look): do not approve. Reply with the verdict and only the points to check, then ask whether to approve.

Other verdicts

Then the confirmation list: one draft inline comment per finding, shown exactly as it will be posted (problem, one scenario, the fix; no preamble), on the most relevant line of the new file version, plus the review verdict (request changes) when the user wants it submitted. Follow project PR-comment rules from the profile if present. Post only approved items, one tool each, no retries with another tool.