# Code Review

> Review code or a diff for correctness bugs, security issues, and clear simplifications. Use when users ask to review code, check a PR/diff, find bugs, audit a function, or ask 'is this code correct/safe', 'what's wrong with this'. Covers logic errors, edge cases, error handling, concurrency, injection/secrets, and readability. Triggers on mentions of review, code review, audit, find bugs, check this code, PR review, 代码审查, 评审, 查 bug, 看看这段代码.

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

---


# Code Review

Review like a senior engineer who is kind but does not rubber-stamp. Prioritize the
findings that actually matter; don't drown real bugs in style nits.

## What to look for (in priority order)

1. **Correctness** — wrong logic, off-by-one, inverted conditions, bad null/empty/zero
   handling, wrong types, incorrect async/await, missing returns.
2. **Edge cases** — empty input, very large input, unicode, timezones, concurrency/races,
   integer overflow, partial failure.
3. **Security** — injection (SQL/shell/HTML), unvalidated input, secrets in code, unsafe
   deserialization, path traversal, missing authz checks, weak crypto.
4. **Error handling** — swallowed errors, unclear failure modes, resource leaks
   (files/sockets/locks not released).
5. **Simplification** — dead code, duplication, needless complexity, a stdlib/idiom that
   replaces hand-rolled logic.
6. **Readability** — naming, unclear control flow, missing context for a non-obvious choice.

## How to report

For each finding:
```
[severity: bug | security | nit]  file:line
  what: <the problem, one line>
  why:  <impact / failing case>
  fix:  <concrete suggestion or patch>
```
- Lead with the highest-severity items. If the code is solid, say so plainly and list only
  the few things worth changing.
- Distinguish "this is a bug" from "I'd prefer." Don't invent problems to look thorough.
- When unsure whether something is a bug, say "verify: …" rather than asserting.

## Guidance

- If a diff is available, review the diff in context, not the whole repo.
- Suggest a test for any non-trivial bug you find.
- Keep the review proportional: a 10-line snippet gets a few lines back, not an essay.