# Code Review

> Review code for bugs, security issues, performance problems, and style. Use when the user pastes code, shares a file, or asks "what's wrong with this code?".

- Skill: `jezweb/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jezweb/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jezweb/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: jezweb (https://skillmd.com/u/jezweb)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/jezweb/code-review

---


# Code Review

## When to use
- User pastes code in chat
- User attaches a code file
- User asks for review, audit, "find bugs", "security check"

## Steps

1. **Identify scope and language** — what's being reviewed, in what language? If multiple files involved, ask which to focus on first via `ask_questions`.

2. **Read the code carefully** — don't skim. For files in `fs`, call `fs_read`.

3. **Categorise findings**:
   - **Bugs** (incorrect behaviour, will fail at runtime)
   - **Security** (injection, auth bypass, exposed secrets, unsafe deserialization)
   - **Performance** (N+1 queries, unnecessary loops, blocking ops)
   - **Reliability** (missing error handling, race conditions, resource leaks)
   - **Style** (naming, formatting, idiomatic patterns)
   - **Design** (architecture, coupling, complexity)

4. **Filter ruthlessly** — only report issues you're confident about. Skip:
   - Style nits if the user asked about bugs
   - Theoretical problems with no evidence in this code
   - Personal preferences disguised as best practices

5. **For each finding, provide**:
   - **Severity**: critical / high / medium / low
   - **Line reference** if available
   - **What's wrong** (one sentence)
   - **Why it matters** (one sentence)
   - **Suggested fix** (code snippet)

6. **Display the findings**:
   - For 1-3 findings: render inline as markdown
   - For more: use `show_data_table` with columns: Severity, Line, Issue, Fix
   - Use `show_alert` (`error` type) for any critical findings at the top

7. **Summarise** — one paragraph: overall code quality, biggest concern, recommended next action.

8. **Offer next steps** via `offer_choices`:
   - "Apply the critical fix"
   - "Show me how to test this"
   - "Review another file"
   - "Explain finding [N]"

## Style
- Direct but not harsh. Critique the code, not the coder.
- Show, don't tell — code suggestions speak louder than abstract advice.
- Acknowledge what's good if there are bright spots.

## What not to do
- Don't make up issues to seem thorough
- Don't suggest sweeping rewrites unless asked
- Don't mix style nits with critical bugs in the same list (separate by severity)
- Don't claim certainty about runtime behaviour you can't verify (note assumptions)

## Optional: actually run the code
If `run_python` or `run_shell` tools are available and the code is safe to execute, run it with the user's permission to verify:
- Does it execute without errors?
- Does the output match expected behaviour?

Use `confirm_action` first: "Should I run this code in the sandbox to test it?"