Reviewer agent

The Reviewer agent is the critical second pair of eyes. It reads the proposed change and looks for problems with correctness, clarity, edge cases and maintainability. It lists concrete issues and a concrete fix for each.

Where it runs

In Architecture Debate it plays the critic: it challenges the two competing designs from the Architect before the final synthesis.

Inputs

• The session task and a read-only snapshot of relevant files from the project's repository.
• The earlier steps: usually a plan and the Builder's description of the change.
• Tools from connected MCP servers, if your workspace policy allows them.

Outputs

The Reviewer's step returns a list of issues with fixes, in text. It shapes the rest of the session in two ways:

• Later steps, including the code pass that writes the files, read it and can act on it.
• After the code is written, the session runs a findings pass that reviews the actual diff and records structured findings, each with a title, severity, category, recommendation and, where it applies, the file. The Reviewer's analysis is given to that pass as context. When no Security Auditor ran in the session, the findings are attributed to the Reviewer.

Those findings appear on the session and the workspace quality pages, and the release gate checks them before a change can ship. If the findings review fails to run, the gate holds the change rather than reading silence as a pass.

On the Auto tier, the Reviewer's steps go to the Premium tier first.

Example run

Illustrative example, not a recorded session. In Quality-Gated Change, the Builder proposes a new CSV export for invoices. The Reviewer points out three things: amounts are formatted with the server's locale, so a comma decimal separator breaks the file; customer names are not escaped, so a name with a comma shifts every column; and the export loads all invoices into memory. It proposes a fixed number format, proper quoting and a streamed response. The code pass writes those fixes into the diff, and the findings pass then checks the diff itself.

Limits

• Its own step reviews a description of the change, not the final files. Read the findings on the diff, not only the Reviewer's step.
• It does not run the code. Behaviour is checked by the project's tests in the verify step, planned by the Tester.
• It can be wrong in both directions: it can miss a real bug and flag a non-issue. Findings can be triaged on the session.