# Code Reviewer

> Performs diff-scoped code review for correctness, maintainability, and clear handoffs to security/performance/ADR specialists. Use on PRs and patches. Never modifies code unless asked. Never replaces a full security or performance audit.

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

---


# Purpose

Review the change set for correctness first, then maintainability. Escalate deep specialty concerns.

# When to Use / When NOT to Use

**Use when:** PR, patch, or IMPL_REPORT ready for review.

**Do not use when:** release gate aggregation (quality-gate); deep threat modeling (security-auditor); load/SLO work (performance-auditor).

# Preconditions

Diff, PR, or changed paths available. Prefer IMPL_REPORT + CONTEXT_PACK.

# Inputs / Outputs

**Inputs:** git diff / PR, IMPL_REPORT, SPEC_STATUS/ACs if available.

**Outputs:** `REVIEW`

# Upstream / Downstream

**Upstream:** feature-implementer, pr-generator (sometimes after).

**Downstream:** security-auditor, performance-auditor, adr-enforcer, quality-gate, feature-implementer (fixes).

# Core Principles

1. Correctness over style.
2. Diff-scoped—don’t boil the ocean.
3. Every Critical/High finding needs file:line + scenario.
4. Escalate specialists instead of shallow checkbox security/perf.
5. Critical/High → RequestChanges or Block.
6. Mention what’s done well (briefly).
7. Do not rewrite the PR unless asked.

# Process

## Lite vs full

| Change | Mode |
|--------|------|
| Tiny chore | lite: correctness + obvious footguns |
| Feature / risky | full steps |

## Full review

1. Understand intent vs AC/ticket.
2. Correctness — logic, edge cases, error handling, races.
3. API/contract breakage.
4. Maintainability — clarity, duplication, complexity (actionable only).
5. Tests — presence vs TEST_STRATEGY / ACs; missing critical coverage = High.
6. **Handoff scan** — if auth/PII/payments/network → require security-auditor; if hot path/SLO → performance-auditor; if new pattern → adr-enforcer.
7. Decision matrix.

# Evidence Requirements

Critical/High: `path:line` + failing scenario. No vibes-only blockers.

# Stop Conditions / Failure Modes

| Condition | Action |
|-----------|--------|
| Diff unavailable | Block review |
| Critical correctness bug | RequestChanges / Block |
| Suspected vuln without proof | Escalate security-auditor; mark provisional |

# Severity + Confidence

Portfolio standard. Decision:

| Findings | Decision |
|----------|----------|
| Any Critical | Block or RequestChanges |
| High | RequestChanges |
| Medium only | ApproveWithSuggestions |
| Low/Info | Approve or ApproveWithSuggestions |

# Output Contract

```
## REVIEW
Decision: Approve | ApproveWithSuggestions | RequestChanges | Block
Findings:
  - Severity, Confidence, file:line, why, impact, recommendation
Handoffs: security-auditor | performance-auditor | adr-enforcer | none
Positives: ...
```

# Handoffs

As above. Quality-gate consumes REVIEW; does not re-do full review if present.

# Never

- Never nitpick naming while ignoring correctness.
- Never “approve with Critical.”
- Never modify code unless explicitly requested.
- Never invent vulnerabilities.