# Intelligent review

Make review the fast part - the riskiest changes first with the reason why, boilerplate folded away, a reading budget, and a second model checking the work against what you asked for.

Your agent writes code faster than anyone can review it. Warden's review tools don't try to replace you; they decide what you need to read and in what order, and send your comments straight back to the agent.

## The change walkthrough

Open a pull request in the project's **Pull requests** tab (it opens on **Walkthrough**), or press **Review the change** on a Software Factory item.

- **Risk per change, with the reason.** Each part of the diff gets a risk level from fixed rules, never a model:
  - **High**: authentication, sessions, tokens, crypto, permissions; migrations and schemas; policy and sandbox files; CI and deploy configuration; process spawning or `eval`; tests deleted or skipped.
  - **Medium**: source code and dependency manifests.
  - **Low**: tests added, docs.
- **Riskiest first.** High-risk changes come first, then changes linked to a requirement, then by size.
- **Boilerplate folded away**, and listed last: lockfiles, generated and vendored files, snapshots, translation catalogues, whitespace-only and import-only changes, pure renames.
- **Grouped by intent.** A source file sits with its tests. **Group by intent** asks your review model to group the change by what each part is for.
- **Read, skim or skip.** Each group is marked. *Skim* has to be earned (a requirement met, or tests changed with it and passing), and is never given to high-risk code.
- **A reading budget.** *Read N of M changed lines*, with a **Mark reviewed** tick per group and your progress through the must-reads.

### The evidence beside it

- **Checks that ran**, and their results.
- **Policy verdicts on the work**: every decision from the chats that produced it.
- **What the agent chose not to do**: `Not done:` notes in commit messages, open spec tasks, unmet requirements, and calls that were blocked.

### Comments become fixes

Click a line number to comment ({{kbd:⌘+Enter}} saves). **Send as fix** sends one comment; **Send comments to the build** sends them all to the chat that built the change (for a PR with no build chat, **Send review to an agent** opens one in its worktree). Each comment is marked as sent, so nothing goes twice.

When you are done with a PR, post **Comment**, **Approve** or **Request changes** to GitHub as the project's GitHub account.

## A second model checks it against the ask

Agents grade their own work generously. A separate, read-only reviewer that never saw the build chat checks the change against the original ask, word for word, and the approved plan or spec. It marks each requirement met or not met, with file and line evidence, and lists any gaps by severity.

In the Software Factory this runs automatically for the Assured lane and from L2 up, and sends gaps back to the build. See [Review against the original ask](factory-review#review-against-the-original-ask).

Set the reviewer's model in the **Code review · the grader** role of your [Model policy](models#a-model-for-each-job). Pick a different model from the one that writes the code; Warden warns you when they are the same.

## Intelligent Review in Files

In a chat's **Files** view, **Intelligent Review** triages your uncommitted changes: *which files need a human review*. **Run Intelligent Review** asks your chosen model, against a **review policy** you can edit per project or for all projects. The default flags authentication, secrets, schemas and migrations, payments and public APIs.

## Four ways to get review off your plate

1. **Any pull request**: the walkthrough, plus **Review with agent** for a line-by-line review on a model you pick.
2. **Software Factory items**: the walkthrough plus the review against the original ask, automatically.
3. **A step in a workflow**: put a review skill in a [workflow](workflows), and bind that skill to a different model in **Models → Skill models**.
4. **Before every commit**: the **Review my changes before I commit** [automation](automations).

> [!LIMIT]
> Risk levels come from path and keyword rules, not from understanding the code, so treat *low* as an ordering hint, not a clean bill of health. The review against the original ask runs on Software Factory items only.