Reviewer

Reviewer assesses whether work can move forward. It checks the requirements, design, implementation, tests, and other relevant evidence for errors or gaps. It explains concrete problems and who needs to fix them.

Start in an independent session

When the workflow reaches a review state, open a fresh chat separate from the conversations that created the work under review. This includes requirements, design, context, tests, and documentation, as well as code.

For implementation review:

Codex:       $reviewer Continue IMPLEMENTATION review from .standards/STATE.md.
Claude Code: /reviewer Continue IMPLEMENTATION review from .standards/STATE.md.

For final review, use FINAL_DELIVERABLE instead. During recovery, also ask Reviewer to read the active recovery frame.

Ideally, choose a different model of equal or higher capability when those details are known. This is advice, not a requirement. Reviewer can resume its own assessment conversation. Unknown session or model details are disclosed rather than guessed; see the independent-session rules.

Inputs and output

Reviewer checks saved requirements and role reports against the actual files, history, and results. A completion label or a passing command does not prove that all required behavior is correct.

The review reports are saved under .standards/docs/reviews/<Active Work.Id>/:

• implementation.md assesses implementation in standard and expedited cycles.
• final-deliverable.md assesses assembled work in standard and documentation cycles.

In documentation cycles, final Reviewer independently checks saved documentation and Documenter’s evidence against scope, technical contracts, and existing behavior. Missing current-cycle Developer/Tester/implementation-review reports are intentional omissions; missing evidence needed for accuracy still blocks. Success goes to Synchronizer.

Each report records the work inspected, evidence, findings, unanswered questions, and whether this review can pass.

You can select a user style you keep at .standards/user-styles/reviewer/<name>.md. Each report saves the selection, and Reviewer reloads it when it resumes. A style shapes how findings and summaries are written, never their severity, the evidence required, or whether the review passes.

Modes

The saved state determines which review runs. Re-review uses the same mode: Reviewer checks fixes and changed inputs before reusing earlier conclusions. Only Reviewer resolves or withdraws its findings; an author’s statement that a problem is fixed is not enough.

IMPLEMENTATION

In REVIEWING_IMPLEMENTATION, Reviewer checks the implementation against the requirements and design, including Tester evidence in standard work. Expedited review checks the bounded request and Developer’s evidence.

FINAL_DELIVERABLE

In REVIEWING_FINAL, Reviewer checks the assembled standard or documentation deliverable after documentation, including whether earlier evidence still applies and all required outcomes are supported.

Understanding findings

A finding describes a concrete failure, its impact, supporting evidence, the responsible role, and the correction needed. Severity indicates urgency:

• P0: immediate, severe consequences.
• P1: a serious failure in a core requirement or important protection.
• P2: a narrower but still significant defect that needs correction.

All unresolved findings at these levels prevent a pass. Cosmetic preferences and speculative improvements are not findings. No material findings is a valid outcome after sufficient assessment, but missing important evidence can still prevent completion.

Reviewer assesses and reports; the responsible role makes the fix. See Handling Review Findings.

Completion and handoff

Reviewer explains whether work can move forward, what was checked, and what remains unverified. A pass requires sufficient current evidence and no unresolved material findings, assessment gaps, or blocking questions.

With FULL_DELIVERABLE, standard implementation review goes to Documenter. A requirement that depends on that later work can remain explicitly pending at this point. Final review must have evidence for every current requirement and normally goes to Synchronizer.

With IMPLEMENTATION_REVIEWED, Reviewer separately checks whether the cycle can finish after implementation review. The ordinary review may pass while this separate check fails: required documentation or another later dependency may still be unfinished. Reviewer records the unmet work and sends it to its owner.

Only a passing ordinary review and a current ELIGIBLE closure result allow this shorter cycle to reach your sign-off decision. The report saves your choice, the inputs and evidence assessed, and the checks being omitted. Reviewer reassesses it after relevant changes or a return to the shorter policy, keeping earlier conclusions as history. See Finishing After Implementation Review.

Expedited implementation review can go directly to your sign-off decision once its narrower completion requirements are met. It does not claim the skipped standard checks passed. If one becomes necessary, the cycle moves to standard work. During corrections, recovery determines the next step instead.