| name | code-review |
| description | Structured code review workflow for files, directories, and git diffs. Use when reviewing code for bugs, regressions, maintainability, missing tests, or refactor opportunities. |
Code Review
Use this skill for targeted code review requests, including file reviews, module reviews, and current diff reviews.
Review goals
- Find the most important issues first.
- Prefer concrete, evidence-based findings over broad stylistic commentary.
- Call out missing tests or risky edge cases when they matter.
- Do not edit files unless the user explicitly asks for changes.
Review modes
Infer the mode from the user request:
- General review — correctness, readability, maintainability, and missing tests
- Bug-focused review — correctness, runtime failures, invalid assumptions, edge cases, regressions
- Refactor review — simplification, structure, naming, duplication, cohesion, maintainability
- Test review — missing coverage, brittle assertions, edge cases, regression protection
- Diff review — review the current git diff or requested change set for regressions and missing validation
- GitHub PR review — when given a GitHub pull request URL, inspect it with
gh pr view and gh pr diff before concluding
Workflow
-
Identify the exact review scope.
- If the user named a file, directory, symbol, or diff, stick to that scope.
- If the scope is ambiguous, ask one concise clarifying question.
-
Inspect the relevant code before concluding.
- Read the relevant files or inspect the diff.
- For GitHub pull request URLs, use
gh pr view <url> and gh pr diff <url> to inspect the change.
- Follow nearby code only when needed to confirm behavior or impact.
-
Prioritize findings.
- Lead with issues that can cause incorrect behavior, regressions, security problems, crashes, or data loss.
- Lower-priority maintainability notes should come after correctness issues.
-
Summarize succinctly.
- Start with a short summary ordered by severity.
- If there are no meaningful issues, say so clearly.
-
Make findings actionable.
- For each finding, explain:
- what is wrong
- why it matters
- where it occurs
- what change would improve it
Output format
Use this structure unless the user asked for something else:
Summary
- <highest-severity finding or "No major issues found">
- <next item>
Findings
1. Severity: <high|medium|low>
- Location: <file or diff area>
- Issue: <what is wrong>
- Impact: <why it matters>
- Fix: <concrete suggestion>
2. ...
Test gaps
- <missing test or "None noted">
Guardrails
- Do not invent behavior you did not inspect.
- Do not pad the review with weak style nits.
- Prefer a small number of strong findings over a long noisy list.
- If the review target is large, focus on the most relevant files first and say what you sampled.
- If you are uncertain, state the uncertainty explicitly.
