Review

Review the change by running the passes in

passes/

, in order. Each pass is a skill in this directory — read it and apply it.

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

Before judging anything, know where this project keeps its decisions and standards.

First, check for a

REVIEW.md

at the repo root (generated by the

document-conventions

skill). If it exists, read it — it's authoritative: it maps each pass to the docs that define "correct" for this project. It's a table of contents written in natural language, so read it as guidance, then read the docs it points to. Use those paths.

If there's no

REVIEW.md

, discover:

Agent instructions. Read the repo's
```
AGENTS.md
```
(or
```
CLAUDE.md
```
) at the root. They usually point at the docs that matter; honor anything they state about conventions.
Documentation. Look for a
```
knowledge/
```
or
```
docs/
```
directory. If there's a
```
knowledge/table-of-contents.md
```
or
```
docs/README.md
```
, read it — it's the index. Otherwise list the directory and read anything that looks like standards.
Conventions. Find the project's stated standards —
```
knowledge/technical/conventions.md
```
,
```
CONTRIBUTING.md
```
,
```
.cursor/rules/
```
, or similar. "Conventions" in the passes below means these, not generic advice.
Stack. Identify the frameworks from
```
composer.json
```
/
```
package.json
```
/
```
Cargo.toml
```
. For each one, apply its conventions pack from the open-review repo (
```
skills/conventions/<name>
```
— e.g.
```
laravel
```
,
```
react
```
,
```
inertia
```
): if the pack is installed locally, read it; otherwise resolve it at runtime (
```
npx skills use elliottlawson/open-review@<name>
```
, or fetch the pack's
```
SKILL.md
```
from GitHub). A pack is that framework's standard — its index routes you to sub-files based on what the change touches; apply the relevant sections at the matching passes. Precedence: this project's documented conventions override packs; packs override general merits.

Missing files are fine — skip them silently. If the project has no documented standards, say so in the verdict instead of inventing any. If you had to discover instead of using a

REVIEW.md

, that's fine — but if the project has conventions and no

REVIEW.md

, mention that the

document-conventions

skill would make future reviews more accurate.

Run: mission → architecture → implementation → craft → security → performance.

Then weigh the passes 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.

Report your findings in prose — severity (critical / warning / info), the pass that found it, the file and line, and why it matters. If you're running under CI, the

review-as-json

skill wraps this review and shapes the output as JSON instead.

review

NPX Install

Tags

SKILL.md Content

Review

Scope

Step 0 — Find the project's reference material