PR Review

This skill covers focused, angle-specific pull request review: picking the right lens (security, performance, tests, or architecture), producing specific and severity-ranked findings, and closing with a clear merge verdict.

Workflow for Reviewing a PR

1. Pick the angle — Determine emphasis from the user's request ("security", "perf", "tests", "arch"). If unspecified, ask which angle to use, or default to security as the highest-risk default.
2. Get full file context — A diff alone routinely misses bugs that live just outside the changed lines. If only a diff is available, request the surrounding file(s) before making confident claims.
3. Review against the angle's checklist — Work through the relevant checklist below in priority order; do not mix angles unless the user asked for a full review.
4. Write specific, cited findings — Every finding names a file and line number and states the concrete defect, not a vague impression.
5. Rank by severity — Group findings as blocker, important, or nit.
6. State uncertainty explicitly — If the diff doesn't give enough context to be sure, say so and ask for more code rather than guessing.
7. End with a verdict on its own line — Safe to merge | needs changes | reject (or the architecture-specific verdict below).

Output Discipline

Applies to every review angle: