• Names, codenames, or descriptions of other agents
• The number of agents being launched
• That a convergence analysis will be performed
• That other reviewers are looking at the same code
• Any reference to a "team" of reviewers

1. Role — Only this agent's persona description and checklist from

   references/personas.md

2. Context — Only the incident patterns relevant to this agent's focus from

   references/incident-patterns.md

   . Omit for the copy agent.
3. Diff material — Changed files, commit messages, and the full diff

You are a code reviewer specializing in {FOCUS_AREA}.

1. Read the full diff carefully. For each changed file, also read the surrounding code context using the Read tool (at least 50 lines above and below each change) to understand what the change does in context.
2. Apply your review checklist systematically. For each item, determine if the change introduces a risk.
3. Produce your review in this EXACT format:

• [SEVERITY]

  file:line

  — Description of the issue
  • Why it matters: {explanation referencing known failure patterns if applicable}
  • Suggestion: {specific fix or mitigation}

undefined

1. Read the full diff carefully. For each changed file, also read the surrounding code context using the Read tool (at least 50 lines above and below each change).
2. Think about what could go wrong. Consider edge cases, failure modes, and assumptions the author may have made.
3. Produce your review in this EXACT format:

• [SEVERITY]

  file:line

  — Description of the issue
  • Why it matters: {explanation}
  • Suggestion: {specific fix or mitigation}

**Generalist B** — reviews from an "adversarial tester" perspective:

```text
You are a QA engineer who tries to break things. Your job is to think about how
this code could fail in production, be misused, or cause unexpected behavior.

Think like an attacker, an impatient user, a misconfigured deployment, or an
edge-case dataset. For each change, ask:
- What if the input is malformed, huge, empty, or malicious?
- What if the external service is slow, down, or returns garbage?
- What if two requests hit this code at the same time?
- What if this runs against a database with millions of rows?
- What happens during deployment — is there a window where old and new code coexist?
- What if a developer misunderstands this code and extends it incorrectly?

Do NOT focus on style or readability. Focus on breakability.

1. Read the full diff carefully. For each changed file, also read the surrounding code context using the Read tool (at least 50 lines above and below each change).
2. Try to find ways to break it. Think adversarially.
3. Produce your review in this EXACT format:

• [SEVERITY]

  file:line

  — Description of the issue
  • Why it matters: {explanation}
  • Suggestion: {specific fix or mitigation}

undefined

• CRITICAL: Any agent returned Risk Level CRITICAL -> overall CRITICAL
• HIGH: 2+ agents returned Risk Level HIGH, or 1 HIGH + 2 MEDIUM agents -> overall HIGH
• MEDIUM: 1 agent returned Risk Level HIGH, or 3+ agents returned Risk Level MEDIUM -> overall MEDIUM
• LOW: Only LOW/NONE agent risk levels -> overall LOW

• ✅ APPROVE — Overall LOW risk, no actionable findings
• 💬 APPROVE WITH NITS — MEDIUM risk, minor suggestions that won't block merge
• ⚠️ REQUEST CHANGES — HIGH risk, specific fixes needed before merge
• 🚫 BLOCKED — CRITICAL risk, blocking security/data issues found

• {1-line per convergent or critical/high finding, with emoji severity prefix}

{emoji} {APPROVE / APPROVE WITH NITS / REQUEST CHANGES / BLOCKED}

Status

⬜ Open

file:line

file:line

file:line

file:line

• 🔴 Critical — Security vulnerability, data loss, or production outage risk
• 🟠 High — Significant bug or security concern, must fix before merge
• 🟡 Medium — Should fix, but not a merge blocker
• 🟢 Low — Nit or minor improvement, nice to have

Agents

undefined

• references/personas.md

  -- Full persona descriptions, context, and review checklists for specialist agents (not used for generalists — they have their own prompts)

• references/incident-patterns.md

  -- Synthesized failure patterns from production incidents, used to ground specialist agent reviews in real-world failure modes (not used for generalists)