Skill: Code Reviewer

The Code Reviewer skill turns Claude into a senior engineer who reviews your code the way a picky but fair teammate would — the kind who actually reads the diff instead of rubber-stamping it. It enforces a consistent review structure so you stop getting vague feedback like "looks good" and start getting specific, actionable findings with fixed code attached.

What This Skill Does

When you trigger the skill, Claude runs your code through a four-part checklist before it writes a single word of feedback:

Safety — scans for injection points, hardcoded secrets, unsafe deserialization, missing auth checks, and other OWASP-class issues.
Performance — flags O(n²) loops inside hot paths, unnecessary re-renders in React, N+1 queries in ORMs, and unbounded allocations.
Readability — checks naming, function length, dead code, and whether comments explain why rather than what.
Types — rejects any in TypeScript, flags unchecked casts, and points out where stricter types would catch bugs at compile time.

The output is structured: a one-line verdict (Pass / Request Changes), a list of critical issues that block merge, a list of suggestions that are nice-to-have, and code snippets that show the fixed version — not just a description of the problem.

How to Install

Create the skills directory in your project if it doesn't exist:
```
mkdir -p .claude/skills/code-reviewer
```
Save the template below as .claude/skills/code-reviewer/SKILL.md.
Commit it to your repo so the whole team gets the same review baseline.
Trigger it with a prompt like: "Review src/auth/login.ts using the code-reviewer skill."

SKILL.md Template

# Code Reviewer Skill

## Triggers
- "Review this PR"
- "Check for bugs"
- "Optimize this code"

## Review Checklist
1.  **Safety:** Are there any security vulnerabilities? (OWASP)
2.  **Performance:** Are there O(n^2) loops? Unnecessary re-renders?
3.  **Readability:** Variable names, function length, comments.
4.  **Types:** No `any` types in TypeScript.

## Output Format
- **Summary:** High-level assessment (Pass/Request Changes).
- **Critical Issues:** Must fix.
- **Suggestions:** Nice to have.
- **Code Snippets:** Show the *fixed* code, not just the error.

Real-World Usage Example

Prompt:

Review this function using the code-reviewer skill.

async function getUser(id: any) {
  const res = await fetch(`/api/users?id=${id}`);
  const data = await res.json();
  return data;
}

Expected output:

Summary: Request Changes — 2 critical issues, 1 suggestion.

Critical Issues:

Injection (line 2): id is interpolated directly into the URL. A malicious id like 1&admin=true can manipulate the request. Parse it as an integer and reject non-numeric input.

Missing error handling (line 3): If fetch fails or res.json() throws, the function rejects with an unstructured error. Callers can't distinguish a 404 from a network failure.

Suggestions: 3. Type the parameter: id: any defeats TypeScript's purpose. Use id: string or id: number depending on your API.

Fixed code:
async function getUser(id: number): Promise<User> {
  if (!Number.isInteger(id) || id <= 0) {
    throw new TypeError('id must be a positive integer');
  }
  const res = await fetch(`/api/users/${encodeURIComponent(id)}`);
  if (!res.ok) {
    throw new Error(`getUser failed: ${res.status} ${res.statusText}`);
  }
  return res.json() as Promise<User>;
}

Customization Tips

Add a project-specific section. If your team bans certain libraries (e.g., lodash in favor of native methods), add a "Banned dependencies" line to the checklist. Claude will flag them during review.
Tighten the type rules. For strict codebases, change No any types to No any, no non-null assertions (!), no @ts-ignore. The stricter the rule, the more Claude catches.
Add a test coverage check. Append 5. Tests: Are edge cases covered? Are there tests for null/empty/large inputs? and Claude will call out missing test cases alongside the code review.
Scope it to a language. If your repo is Python-only, replace the TypeScript type rule with Python-specific checks: type hints, mutable default arguments, bare except: clauses.

Combining With Other Skills

security-auditor — Run code-reviewer first for general quality, then security-auditor for a deep pass on auth and data handling. They overlap on safety but the auditor goes deeper on OWASP.
technical-writer — After a review surfaces complex logic, hand the function to technical-writer to generate or update its documentation.
ux-designer — When reviewing React components, switch to ux-designer to check accessibility and design-token compliance in the same pass.

Common Mistakes to Avoid

Reviewing too much at once. Paste a single file or a focused diff, not the whole codebase. Large inputs dilute the review and Claude starts skipping issues.
Forgetting to commit the SKILL.md. If it lives only on your machine, teammates get a different review baseline. Commit it so reviews are consistent across the team.
Treating suggestions as optional noise. The "nice to have" items often reveal tech debt that becomes critical later. Track them even if you don't fix them immediately.
Not feeding back false positives. If Claude flags something that's actually fine (e.g., a deliberate any in a test helper), add an exception note to the skill so it doesn't repeat the noise.

Share this article