code-reviewlisted

Reviewing a change as an engineering activity: setting review depth from the change's risk rather than its size, looking in the order that finds the expensive defects first, refusing to spend human attention on what a formatter or linter should own, writing a finding that can be acted on, separating blocking objections from preferences, and receiving review without either capitulating or defending. Use when reviewing a pull request or a diff, when a review has become a list of style comments, when reviews are slow or rubber-stamped, when a reviewer and an author are deadlocked, when a defect reached production through an approved change, or when deciding what a review must catch versus what CI should. Does not cover the smell catalogue (java-code-smells), SOLID as review criteria (java-solid), readability heuristics (java-clean-code), or which automated gates to run (quality-gates).
robsonkades/agent-skills · ★ 2 · Code & Development · score 75

Install: claude install-skill robsonkades/agent-skills

# Code Review ## Purpose Review connects a change to its requirements, callers and operational consequences. Automated checks help, but passing them does not establish that the right behavior was built. Repeated formatting comments consume attention that could expose a reachable correctness defect. Two failure modes: the review that blocks for a week over preferences, and the approval that was a formality. Both come from not deciding, up front, what this particular review is for. ## Workflow 1. **Establish scope and purpose.** Read the request, description and repository guidance; identify the base/head commits or staged/unstaged files being reviewed. Inspect callers, tests and relevant contracts before assuming intended behavior. If the requirement remains ambiguous, ask a focused question while continuing checks independent of that answer. 2. **Set the depth from the risk**, not the diff size: what breaks if this is wrong, how quickly would it be noticed, and can it be rolled back? A 400-line refactoring under test is a lighter review than a 4-line change to a payment path. 3. **Look in payoff order** (`references/what-to-look-for.md`): does it do the right thing; does it fail well; concurrency and data; compatibility and migration; security; can it be operated; are the tests capable of failing. Reorder by concrete risk: authentication changes deserve security review first, and unreadable control flow may prevent a correctness judgment. 4. **Ver