# Review

> Reviews a change by running the mission, architecture, implementation, craft, security, and performance passes, then weighing them into a verdict.

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

---


# Review

Review the change against the passes, then weigh them into a verdict.

If a referenced skill isn't available locally, fetch it from the open-review repo at runtime — the whole directory, subdirectories included. Use `npx skills use elliottlawson/open-review@<name>` if npx is available; otherwise fetch the directory from GitHub.

## Scope

The change is the diff against the merge-base with the base branch (`git diff origin/main...HEAD`, or the base/range the caller gives). Confirm the ref resolves; if the diff is empty, say so and stop. Skip generated and vendored files.

## Step 0 — Find the project's reference material

Find the project's standards and stack with `/infer-conventions`; use what it loads throughout the passes. If the project has no documented standards, say so in the verdict instead of inventing any.

## Passes

Run in order: mission → architecture → implementation → craft → security → performance. Then weigh them into a verdict:

- **Approve** — mission met, no blocking findings.
- **Changes needed** — real issues found; name them.
- **Hold** — mission unclear, or an architectural concern needs discussion first.

**Depth calibration.** Match depth to scope — a 2-file bugfix is brief; a 30-file feature gets deep coverage.

**Verify before you flag.** A finding must point at a concrete line and a concrete consequence. If you can't verify it, ask a question instead.

## Reporting

Report your findings in prose — severity (critical / warning / info), the pass that found it, the file and line, and why it matters.

- **Judge the change, not the codebase.** Blocking findings only on new or meaningfully changed code; a pre-existing violation is advisory at most.
- **Cite the standard, state the target pattern.** When the project has documented standards, name the doc a finding violates and the pattern to follow instead.
- **Report repeated issues once.** The same issue across multiple files is one finding — note that it applies broadly.

Under CI, `/review-as-json` wraps this review and shapes the output as JSON.