| name | code-review-skill |
| description | Reviews code for correctness, security vulnerabilities, performance issues, readability,
and adherence to best practices and team conventions. Use this skill when a user asks for
a code review, PR review, feedback on code quality, a security audit of code, style or
pattern improvements, or a second opinion on an implementation. Common phrasings: "review
this code", "check my PR", "look at this function", "is this secure?", "any issues with
this?", "code feedback please", "audit this module", "does this follow best practices?".
Do NOT use when the user wants code written from scratch (no existing code to review),
or when the request is purely about running/executing code, deploying, or testing
infrastructure — this skill reads and critiques existing code only.
|
Code Review Skill
Overview
The Code Review Skill performs structured code reviews covering correctness, security,
performance, maintainability, and style. It provides actionable, prioritized feedback
with specific line-level suggestions and explanations. Reviews are scoped to the provided
code and context — this skill reads and critiques; it does not execute, deploy, or merge.
When to Use / When NOT to Use
Use this skill when:
- User shares code and asks for review, feedback, or critique
- User wants a pull request reviewed before merging
- User asks if code is secure, performant, or follows best practices
- User wants to understand issues or anti-patterns in existing code
- User asks "is there a better way to write this?"
Do NOT use this skill when:
- No existing code is provided (use a code-generation skill instead)
- User wants the code executed or its output explained
- The request is about infrastructure, CI/CD pipelines, or deployment (not code logic)
- User needs full test suites written from scratch without code to review
Inputs
- Code: The code to review (paste, file path, or PR diff)
- Language/framework (optional): Inferred from code if not provided
- Context (optional): What the code is supposed to do, team conventions, prior art
- Focus areas (optional): Security, performance, style, correctness — defaults to all
Outputs
- Summary: One-paragraph overall assessment (pass/needs-work/major-issues)
- Findings: Prioritized list — Critical, High, Medium, Low — each with:
- Location (file/line or function name)
- Issue description
- Recommended fix or improvement
- Positive observations: What the code does well (don't skip this)
- Suggested rewrites (optional): Inline code suggestions for key fixes
Workflow
- Read all provided code; identify language, framework, and apparent purpose.
- If context is missing, infer intent from code and proceed; note any assumptions.
- Check for correctness: logic errors, off-by-one errors, unhandled edge cases.
- Check for security: injection, insecure deserialization, hardcoded secrets, improper
auth, SSRF, XSS, CSRF, insecure dependencies.
- Check for performance: N+1 queries, unnecessary allocations, blocking I/O, poor
algorithmic complexity.
- Check for maintainability: naming, complexity, duplication, test coverage signals.
- Check style against inferred or stated conventions.
- Produce a prioritized findings list; include at least one positive observation.
Stop conditions:
- Stop and ask if code is too large to review in one pass; request a scoped subset.
- Do not silently skip security findings — always surface them even if minor.
Edge Cases
- Hardcoded secrets found: Flag immediately as Critical; do not reproduce the secret
in the review output.
- Very large diff: Ask user to scope to the most important files or functions.
- No context provided: Infer from code; clearly state your interpretation.
- Generated/boilerplate code: Note if findings are in generated code vs user-written.
- Conflicting conventions: Ask which style guide or standard applies.
Safety & Secrets
- Never log, commit, print, or reproduce real secrets, tokens, or credentials found in code.
- Flag hardcoded secrets as Critical findings — mask the value in the output.
- Do not suggest insecure patterns as "fixes."
- Warn if reviewed code contains dangerous operations (file deletion, DB drops, etc.).
Examples
Example 1: SQL injection vulnerability
User prompt: "Review this Python function that fetches user data from our database:
def get_user(name): return db.execute(f'SELECT * FROM users WHERE name = {name}')"
Expected output:
- Critical — SQL Injection: Direct string interpolation in SQL query allows SQL
injection. Use parameterized queries:
db.execute('SELECT * FROM users WHERE name = ?', (name,)).
- Medium — No result handling: Function returns raw cursor; handle empty results.
- Low — Naming:
get_user implies single result; return one record or rename to
find_users.
- Positive: Function is concise and has a clear single responsibility.
Example 2: React component performance review
User prompt: "Can you review this React component? It re-renders constantly and I'm
not sure why." (component code attached)
Expected output:
- Identify missing
useMemo/useCallback causing child re-renders
- Flag inline object/array literals as new references on each render
- Note missing keys in list rendering
- Suggest
React.memo wrapping if appropriate
- Overall: medium-priority performance issues; no security concerns found
Testing / Evals
See evals/evals.json for test prompts. Run 2–3 prompts and compare outputs against
expected_output descriptions.
References
