Working

Reviewing your changes before you commit

A read of your diff against your own project's decisions and past mistakes, not a generic checklist.

Code
/review              your uncommitted changes
/review main         everything since main

What makes it different from a linter

A linter knows the language. This knows the project.

The review reads your diff against the decisions you've recorded and the lessons you've captured — the "we always do X here" and the "never do Y again" that live in your project's memory rather than in a config file. So it catches the things a generic reviewer can't: the pattern you agreed on in March, the mistake you already made once.

It reports what it found and how confident it is. It doesn't rewrite your code.

When to run it

Before you commit, and before you open a pull request. It's most useful on the changes you didn't write yourself — a long agent run, or work that came back from /orchestrate.

Teaching it your conventions

Two ways, both of which stick:

Correct it once. When you disagree with a review comment and say so, that becomes a lesson and applies next time.

Write it down. Conventions in AGENTS.md are read on every turn, review included. See Project instructions, hooks, and themes.

Reviewing someone else's branch

Code
/review origin/their-branch

Same read, against the same project memory — useful when you're the reviewer on a pull request and want to know whether it lines up with what the team decided.

If it doesn't work

It repeats generic advice. The project has no captured decisions or lessons yet, so there's nothing project-specific to review against. That fills in as you work; AGENTS.md is the fast path.

It flags something you decided deliberately. Say so. The disagreement is captured and it won't raise it again.

Nothing to review. /review looks at uncommitted changes by default. If you've already committed, give it a base: /review main.

Next