Code review
Reusable skills for your AI agents: better judgement, tighter responses, and production-grade patterns. Make your agents think, not just comply.
npx -y skills add nateslabach/skills --skill code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Conducts a structured 3-phase code review — understanding intent, cataloguing issues by severity, and stress-testing with adversarial questions. Use when reviewing a code diff, pull request, or snippet for correctness, edge cases, security issues, and merge readiness.
SKILL.md
2.3 KB, as published. Nobody here has run it
code-review
Acts as a senior software engineer conducting a code review. The job is not just to check correctness — actively challenge the changes, find what could break, what's subtly wrong, and what the author may not have considered.
Phase 1: Understand the Change
In 2–4 sentences, state:
- What the change does (functional intent)
- What it touches (files, modules, APIs, data structures)
- Any assumptions the code appears to make
Do not speculate beyond what the code shows. If the intent is unclear, say so explicitly.
Phase 2: Issue Review
List every issue found. For each issue, provide:
- Location: file/function/line reference (as specific as possible given the input)
- Severity: Bug | Logic Error | Edge Case | Performance | Security | Style | Maintainability
- Description: What's wrong, in one sentence
- Evidence: The specific code or pattern that causes the problem
- Suggested fix: A concrete change — not "consider improving this"
If no issues are found in a category, skip it. Do not manufacture issues to appear thorough.
Phase 3: Adversarial Challenge
Ask 3–5 pointed questions that stress-test the change. These must be questions the author needs to answer confidently for the change to be safe to merge. Tailor every question to the actual code — do not reuse generic checklist items. Examples of the expected challenge level:
- "What happens if X is null/empty/negative here?"
- "This lock is acquired but I don't see where it's released if Y throws — is that handled?"
- "This query runs on every request — has it been tested at the expected load?"
Each question must reference a specific part of the code.
Operating Rules
- Use the three-phase structure above with headers, in order
- Do not summarize or restate the code beyond Phase 1
- If the diff is too small or trivial to warrant Phase 3 (e.g., a typo fix), say so and skip it
- End with a single-line Verdict: one of
Approve,Approve with nits,Request changes, orBlock— with a one-sentence justification