# Module 6 — The Reviewer Role

> The Reviewer is the last line of defense before the real world sees your work.

---

## What Is the Reviewer?

The **Reviewer** evaluates completed work against the original requirements. It checks for correctness, quality, security, and completeness — and produces a findings list that the Executor can act on.

The Reviewer is not a critic. It is a quality gate with a clear mandate: *does this do what it was supposed to do, safely and correctly?*

---

## The Reviewer's Responsibilities

- Compare output against the original task specification
- Identify bugs, gaps, security risks, and logic errors
- Produce a clear, actionable findings list
- Approve when work meets the bar — not hold it forever
- **Not rewrite the work itself** — that goes back to the Executor

---

## What the Reviewer Is NOT

| Not the Reviewer's job | Who does it |
|------------------------|-------------|
| Deciding what to build | Planner |
| Fixing the issues | Executor |
| Researching solutions | Researcher |
| Nitpicking style | That's not a quality gate, that's a preference |

---

## Best Models for Review

| Model | Why |
|-------|-----|
| Claude Opus 4 | Deepest reasoning, catches subtle logic errors |
| Claude Sonnet 4.5 | Fast review for straightforward tasks |
| GPT-4.1 | Strong at structured review checklists |

**Use Opus for:** security review, compliance review, complex logic review  
**Use Sonnet for:** code style, output formatting, quick sanity checks

---

## The Review Checklist

A good Reviewer checks five things:

### 1. Correctness
- Does the output do what was asked?
- Does it handle edge cases?
- Does it produce the right output for valid inputs?

### 2. Completeness
- Are all requirements addressed?
- Are there missing pieces the Executor skipped?

### 3. Security
- Are there injection vulnerabilities? (SQL, XSS, command injection)
- Is sensitive data exposed?
- Are inputs validated and sanitized?

### 4. Efficiency
- Does it work, or does it work *well*?
- Any obvious performance problems (N+1 queries, large loops)?

### 5. Maintainability
- Can a human read and understand this code?
- Are variable names sensible?
- Is there anything that will be confusing in 6 months?

---

## Writing a Reviewer Prompt

```
You are a Reviewer. Review the following [code/document/output]:

[paste the output]

Original task specification:
[paste what was asked for]

Review for:
1. Correctness — does it do what was asked?
2. Completeness — is anything missing?
3. Security — any vulnerabilities?
4. Edge cases — what inputs could break this?

Output format:
- PASS or FAIL (overall)
- Findings (numbered list, severity: Critical / Major / Minor)
- Each finding: description + line reference + suggested fix direction
- Do NOT rewrite the code — describe what needs to change
```

---

## Reviewer in Practice

**After an Executor completes a task:**
1. Paste the output + original spec into a Reviewer prompt
2. Get the findings list
3. Send findings back to the Executor with "Fix finding #1, #3, #5"
4. Repeat until PASS

**For security-sensitive work:**
- Always use Opus, not Sonnet
- Run a dedicated security review pass (separate from correctness)
- Check OWASP Top 10 explicitly

**For documents and proposals:**
- Check against the original brief: does it answer the brief?
- Check for internal contradictions
- Check tone and audience fit

---

## Reviewer Failure Modes

| Failure | Cause | Fix |
|---------|-------|-----|
| Reviewer rewrites the work | Role confusion | Enforce: findings only, no rewrites |
| Nothing gets approved | Standards too high | Define the minimum bar explicitly |
| Critical bugs missed | Checklist too shallow | Add security + edge case sections |
| Review ignored | Findings not actionable | Require fix direction per finding |

---

## Closing the Loop

The Reviewer completes the cycle:

```
Planner → Researcher → Executor → Reviewer → Executor (fixes) → Reviewer (re-check) → PASS
```

In practice, most tasks don't need every role every time. A simple edit might be: Executor → Reviewer → done. A complex build might cycle multiple times.

The discipline is the same either way: **never skip the Reviewer.**

---

## Checkpoint

You've completed the core curriculum. You should now be able to:

- [ ] Describe all four roles and when to use each
- [ ] Choose the right model for each role
- [ ] Choose the right tool for each role
- [ ] Write prompts for all four roles
- [ ] Run a complete Planner → Executor → Reviewer cycle on a real task

---

## What's Next

This curriculum is the foundation of the **Formatica Light Workshop**.

The full workshop covers:
- Building your organization's first multi-agent workflow
- Compliance and governance for AI systems
- Measuring ROI on AI implementations
- Customizing agent roles for your specific domain

**[Book the full workshop →](https://formatica.ai/start/)**

---

*Published by Formatica |  | [formatica.ai](https://formatica.ai)*