# Code Reviewer

> General-purpose code review skill. Provides checklists for security, code quality, performance, and best practices. Use when reviewing code changes, PRs, or performing quality audits.

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

---


**Iron Law:** Never approve code without reading the actual implementation; always provide severity-bucketed findings with file:line evidence.

# Code Reviewer

General-purpose code review skill covering security, quality, performance, and best practices.

## When to Use

- After writing or modifying code
- During PR reviews
- When auditing code quality

## Process

1. Identify changed files via `git diff` or user request
2. Read [reference/code-review-checklist.md](reference/code-review-checklist.md) for review categories, severity levels, and output format
3. Review each file against the checklist
4. Report findings by severity (Critical > High > Medium > Low)

## Reference Files

| File | Contents | Load When |
|------|----------|-----------|
| `reference/code-review-checklist.md` | Security checks, code quality, performance, best practices, output format | Reviewing any code change, pre-PR checklist, security audit |

## Error Handling

If no changes are found, report "No changes detected" and list the files/paths searched.
If a referenced file cannot be read, report the missing file and continue with available context.

## Anti-Patterns

- **Never rubber-stamp without file:line** — "looks good" with no evidence is a failed review
- **Never mark APPROVED if any Critical or High finding is unresolved** — severity discipline is non-negotiable
- **Never review from memory** — always read the actual changed files; filenames do not tell you what changed
- **Never scope-creep the review** — report what changed, not what you wish were different in adjacent code
- **Never merge findings across files** — report per-file with specific line numbers, not aggregate impressions
- **Avoid vague findings** — "this could be a security issue" is not a finding; "SQL built via string concatenation at service.ts:47 allows injection" is

## Verify

After completing a review:

```bash
# Confirm all files you reviewed are the ones that actually changed
git diff --name-only HEAD~1

# Confirm no new linting errors introduced
npm run lint 2>&1 | grep -E "error|warning" | head -20

# Confirm tests still pass after changes
npm test -- --passWithNoTests 2>&1 | tail -5
```

Report format after verification:
```
REVIEW COMPLETE:
- Files reviewed: N (list them)
- Findings: X Critical, Y High, Z Medium, W Low
- Verdict: APPROVED / NEEDS_REVIEW / REJECT
- Evidence: [file:line for each finding]
```