Ad-hoc AI code review is inconsistent. Ask for a review twice and you get two different things — different depth, different format, different focus. A code review skill fixes this by giving your agent a defined procedure to follow every time.
Here's what makes a great code review skill and where to find the best ones.
Why skills beat ad-hoc review prompts
When you ask an agent to "review this code," it improvises. Quality varies based on how you phrased the request, what's in its context window, and which patterns it happened to weigh most. You can't predict the output, and you can't share the approach with your team.
A code review skill externalises your team's standards into a file:
- Exactly what to check
- How to rate severity
- What format to return findings in
- What to skip (linting — your CI handles that; typos — not engineering issues)
Commit the skill to your repo. Every developer, every agent, every PR — same procedure.
What a strong code review skill covers
The best review skills are opinionated. They check specific things rather than "everything." Here's a breakdown by category:
Correctness
| Check | What to look for |
|---|---|
| Logic errors | Off-by-one, incorrect conditionals, unhandled edge cases |
| Race conditions | Shared mutable state, unsynchronised concurrent access |
| Type safety | Unsafe casts, implicit conversions, null dereferences |
| Error handling | Swallowed exceptions, missing fallbacks, incorrect error propagation |
Security
| Check | What to look for |
|---|---|
| Injection | SQL, command, LDAP — string concatenation in queries |
| Authentication | Missing auth checks, insecure token handling |
| Data exposure | PII in logs, secrets in code, overly broad API responses |
| Dependencies | New packages added — any known CVEs |
Maintainability
| Check | What to look for |
|---|---|
| Complexity | Functions exceeding a complexity threshold |
| Duplication | Logic that already exists elsewhere in the codebase |
| Naming | Unclear variable or function names that require a comment to explain |
| Test coverage | New logic without corresponding tests |
A skill should specify which of these your team cares about most — a security-focused skill checks everything in the security column deeply; a fast-review skill focuses on correctness only.
Finding review skills in the directory
Search from your terminal:
npx mdskill search "code review"
Or browse the code category for ranked skills with security audit scores. Filter for skills with a score of 85+ — low-scoring review skills may themselves contain problematic instructions.
Install the one that matches your stack:
npx mdskill add owner/repo/skill-name
Stack-specific review skills
Generic review skills catch generic issues. Stack-specific skills are more valuable — they know the footguns in your ecosystem:
- Node.js / Express — async/await misuse, callback error handling, middleware ordering
- React — missing dependency arrays in hooks, unnecessary re-renders, key prop misuse
- Python — mutable default arguments, subprocess shell injection, pickle deserialization
- Go — goroutine leaks, unchecked errors, nil pointer patterns
- SQL — N+1 query patterns, missing indexes on filtered columns, unbounded queries
Search for your stack:
npx mdskill search "react code review"
npx mdskill search "python security review"
Building a custom review skill
Your team's review standards are specific to your codebase. A custom skill captures them:
# team-pr-reviewer
## Purpose
Review pull requests against our engineering standards for correctness,
security, and maintainability. Skip style issues — that's the linter's job.
## Instructions
1. Read each changed file in the diff
2. Check for logic errors and unhandled edge cases
3. Flag any SQL query using string concatenation
4. Check that new API endpoints have authentication middleware applied
5. Verify new async functions have proper error handling
6. Check for new dependencies — flag any with known CVEs
## Output format
Return findings grouped by severity:
critical: [findings that must block the PR]
high: [findings that should be addressed before merge]
medium: [findings to address in a follow-up]
For each finding:
- location: file:line
- issue: what the problem is
- recommendation: how to fix it
See how to build a skill for the full process.
Making reviews part of your workflow
Once installed, trigger the review naturally:
"Review this PR" "Check these changes for issues before I merge" "What are the problems with this diff?"
The agent reads the skill and follows the procedure. The output format stays consistent — findings are categorised, located, and actionable.
Commit .claude/skills/ (and the equivalent for Cursor, Cline) to your repo and the review standard is shared automatically with your whole team.
What's next?
- Browse code review skills in the directory
- Add security depth with a security skill alongside your review skill
- Share skills across your team's agents — Claude Code, Cursor, and Cline