# Code Review

> Use when the user wants a code review instead of implementation. Prioritizes correctness bugs, behavioral regressions, missing tests, and risky assumptions.

- Skill: `voidful/code-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add voidful/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/voidful/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: voidful (https://skillmd.com/u/voidful)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/voidful/code-review

---


# Code Review

## Core Principle

No agent should verify its own work. A code review uses a fresh perspective to find what the author missed.

## When to Use

- After implementing a feature or bug fix, before committing.
- When user says "review", "check", "look at", or "what's wrong with".
- After completing a task with 2+ file edits.

## Review Priorities (in order)

1. **Correctness bugs** — Does the code do what it claims to do?
2. **Behavioral regressions** — Does it break existing functionality?
3. **Missing tests** — Are there untested code paths?
4. **Risky assumptions** — Are there hardcoded values, unchecked errors, or race conditions?
5. **Security** — Prompt injection, path traversal, credential exposure.

## Review Process

1. Read the diff or file(s) under review.
2. Check if tests exist for the changed code. If not, flag it.
3. Look for edge cases the author likely did not consider.
4. Keep the summary short after the findings. Focus on actionable items.

## Output Format

For each finding:
```
[SEVERITY] Description
  File: path/to/file.rs:line
  Why: explanation of the risk
  Fix: suggested change (if obvious)
```

Severity levels: `CRITICAL`, `WARNING`, `INFO`.

## What NOT to Do

- Do not nitpick style issues that a linter should catch.
- Do not rewrite the code. This is a review, not an implementation.
- Do not praise code just to be polite. Be direct and useful.