code-reviewlisted

Use when reviewing a pull request, diff, or proposed code change for correctness, clarity, security, performance, and conformance to project conventions — whether the author is a human, an AI agent, or a peer. Covers the pre-review fact-gathering pass, the read-order strategy (tests first, then implementation, then call sites), the severity-grading rubric, the comment-phrasing discipline, and the no-rubber-stamp rule for AI-generated diffs. Do NOT use for AUTHORING the code (use `refactor` for behaviour-preserving changes or `skill-scaffold` for new skills), for chasing a known bug after merge (use `debugging`), or for security-only audits (use `owasp-security` for vulnerability-focused review).
jacob-balslev/skill-graph · ★ 0 · Code & Development · score 68

Install: claude install-skill jacob-balslev/skill-graph

# Code Review ## Coverage - Pre-review fact-gathering: understanding the PR's stated purpose, the linked issue, the size of the diff, and any context the author called out - Read-order strategy: tests first (do they describe the change correctly?), then the implementation, then the call sites that consume the changed surface - Severity-grading rubric: blocker / change-requested / suggestion / nit / praise — and when each is appropriate - Comment-phrasing discipline: how to ask questions instead of make accusations, how to cite line numbers and references, how to distinguish an objective rule from a stylistic preference - The no-rubber-stamp rule for AI-generated diffs: deliberate verification of the generated code's claims, especially around tests, error handling, and security - Self-review pass: how to review your own diff before opening the PR, catching the obvious issues so the human reviewer can focus on the non-obvious - Tools that complement the review: lint output, type-check output, test results, and how to interpret each in context - The merge decision: when "approve", "request changes", and "close without merge" are appropriate ## Philosophy A code review is a *conversation*, not a verdict. The reviewer's job is not to prove they could have written the code differently; it is to ensure the change ships in a state the team can maintain. Reviews fail when they are either rubber-stamped (no verification, just a thumbs-up) or weaponised (every review becomes a refer