About code-review
A code-review guide for maintainers that starts from the intended change and examines the complete diff and related behavior. It limits findings to actionable issues introduced by the change, with impact, triggering conditions, and relevant code locations.
Key features
- 01Establish review scope and intended behavior
- 02Trace behavior through callers, dependencies, and tests
- 03Check correctness, regressions, and error handling
- 04Exclude unrelated or speculative concerns
- 05Report actionable findings by severity
Use cases
- 01Review behavioral changes in a pull request
- 02Check whether a fix covers edge cases and regressions
- 03Decide whether unrelated changes should be split out
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/code-reviewin Claude Code to confirm it loaded.
Details
From the project READMECode Review
Review the proposed changes as a senior maintainer. Focus on actionable defects introduced by the changes, especially correctness issues, regressions, and changes that are not necessary for the stated goal.
Establish the Review Scope
Before reviewing:
- Determine the intended change from the request, pull request description, linked issue, and maintainer comments.
- Identify the complete diff against the appropriate base.
- Account for every changed file and subsystem.
Do not infer the purpose solely from the implementation. If the intended behavior is unclear, state the assumption used for the review.
Review the Changes
Trace the changed behavior through its callers, dependencies, and tests. Check for:
- Incorrect logic, broken edge cases, or behavior that contradicts the stated goal.
- Regressions in existing behavior, including platform-specific and lifecycle behavior.
- Missing or incorrect error handling.
- Unsafe assumptions about data, ordering, concurrency, or object lifetime.
- Tests that do not cover the changed behavior or that would pass without the fix.
- Changes whose connection to the stated goal is unclear.
Keep fixes tied to the underlying cause. Do not accept unrelated changes to behavior, state management, or architecture merely because they make the reported symptom disappear.
Treat prerequisite or tightly coupled changes as in scope only when their necessity is clear from the implementation or pull request description. A changed file should be necessary for the stated goal or be a directly related test, documentation update, generated artifact, or required refactor. Independent cleanup and speculative improvements belong in a separate change.
Report Findings
Report only findings that are:
- Introduced or made materially worse by the changes under review.
- Specific and actionable.
- Supported by the code or by a concrete missing validation.
For each finding:
- State the user-visible or engineering impact.
- Explain the conditions that trigger it.
- Point to the smallest relevant changed line or range.
- Explain why the current implementation is incorrect.
Prioritize findings by severity. Do not report stylistic preferences, speculative concerns, or pre-existing problems unrelated to the change. If no actionable findings remain, say so explicitly and mention any meaningful validation gaps.
Flag changes whose connection to the stated goal is unclear even when tests pass or the resulting behavior appears correct. Ask for the causal link to be explained; if none exists, recommend reverting the change or moving it to a separate pull request.