Code Review

Code Review Skill

Multi-agent code analysis with parallel reviewers and challenge validation.

Uses explicit subagent dispatch patterns from code-subagents.

Prerequisites

• Required: git

Arguments

Command Routing

Subagent Architecture

rq (Request Review) Subagents

rs (Respond to Review)

No subagents. Interactive interview mode — see rs.md.

Dispatch Patterns

Follows code-subagents patterns:

• Parallel dispatch for independent reviewers
• Sequential dispatch for dependent steps
• Fresh subagent per task — no context pollution
• Skill loading pre-step before each analysis phase
• Error handling: Log failures, continue with partial results

Agent Dispatch

See agents/ for agent definitions.

References

Workflow Routing

• No arguments, rq, or bare branch → rq.md
• rs → rs.md

Output Format

Structured Summary

# Code Review: {module/files}

## Summary
{2-3 sentence overview of changes and overall quality}

## Statistics
- Files reviewed: N
- Findings: N Critical, N High, N Medium, N Low
- Pre-existing: N | Introduced: N

## Critical (Fix before merge)

### {Finding Title}

- **Location**: `file:line`
- **Severity**: Critical
- **Pre-existing**: No
- **Issue**: {What's wrong}
- **Impact**: {Why this matters}
- **Reasoning**:
  <details>
  <summary>Extended reasoning</summary>
  {Detailed explanation of why this was flagged}
  </details>
- **Suggestion**: {How to fix}

## High Priority

### {Finding Title}
{Same structure}

## Medium Priority
{Same structure}

## Low Priority
{Same structure}

## Positive Findings

- {What the code does well}
- {Smart patterns to keep}
- {Good practices observed}

---

Inline Finding Format

For each finding, provide inline comment style:

[{file}:{line}] {Finding Title}
Severity: {Critical/High/Medium/Low}
Pre-existing: {Yes/No}
Issue: {Brief description}
Reasoning: {Why this matters}
Suggestion: {Fix}

---

Severity Definitions

---

Pre-existing vs Introduced

Marking pre-existing:

• Check if the line was modified in the current diff
• If unchanged but flagged, mark as pre-existing
• Pre-existing findings are informational, not blocking

---

Extended Reasoning

Each finding includes a collapsible section with:

1. Why flagged: What triggered the finding (pattern, heuristic, context) 2. Verification: How it was validated (static analysis, pattern match, context) 3. Evidence: Code snippets, references, or examples 4. Alternative view: If uncertain, what else to consider

Example:

<details>
<summary>Extended reasoning</summary>

**Why flagged**: The `query` parameter is directly interpolated into SQL string without parameterization.

**Verification**: Pattern match detected: `f"SELECT * FROM {table}"` - Python f-string in SQL context.

**Evidence**: 

query = f"SELECT * FROM users WHERE id = {user_id}" # Line 42

**Alternative view**: If using a query builder or ORM, check if it handles escaping internally.
</details>

---

Example Output

# Code Review: src/auth/login.ts

## Summary
Implements OAuth login flow with token refresh. Generally well-structured with proper error handling. One security concern around token storage and a performance issue with token validation on every request.

## Statistics
- Files reviewed: 1
- Findings: 1 Critical, 1 High, 0 Medium, 2 Low
- Pre-existing: 1 | Introduced: 3

## Critical (Fix before merge)

### Token stored in localStorage

- **Location**: `src/auth/login.ts:45`
- **Severity**: Critical
- **Pre-existing**: No
- **Issue**: Access token stored in localStorage, vulnerable to XSS
- **Impact**: Any XSS vulnerability exposes user tokens
- **Reasoning**:
  <details>
  <summary>Extended reasoning</summary>
  
  **Why flagged**: localStorage is accessible to any JavaScript on the page.
  
  **Verification**: Direct localStorage API usage detected.
  
  **Evidence**:

localStorage.setItem('accessToken', token); // Line 45

  
  **Alternative view**: If using httpOnly cookies is not possible, consider short-lived tokens with refresh rotation.
  </details>
- **Suggestion**: Use httpOnly cookies or secure session storage

## High Priority

### Token validation on every request

- **Location**: `src/auth/middleware.ts:12`
- **Severity**: High
- **Pre-existing**: Yes
- **Issue**: Token validated against auth server on every request
- **Impact**: Adds 50-200ms latency per request

## Low Priority

### Missing JSDoc on public function

- **Location**: `src/auth/login.ts:23`
- **Severity**: Low
- **Pre-existing**: No
- **Issue**: `validateToken` lacks documentation

### Inconsistent naming: userId vs user_id

- **Location**: `src/auth/login.ts:67`
- **Severity**: Low
- **Pre-existing**: Yes
- **Issue**: Mixed snake_case and camelCase in same file

## Positive Findings

- Clean separation of OAuth flow into dedicated functions
- Proper error handling with typed error classes
- Token refresh logic handles edge cases well

---

Implementation Notes

1. Skills to load are determined by Triage based on detected language/framework 2. Pre-existing detection requires git blame check (not just diff) 3. Extended reasoning should be collapsible in markdown renderers 4. Positive findings help balance the review tone

Reviewer Definitions

Subagent Invocation Pattern

All reviewers are dispatched as parallel subagents following code-subagents patterns.

Uses: general subagent - One per reviewer, dispatched concurrently

Task Tool Invocation Template

# Dispatch ONE subagent per selected reviewer
subagent_type: general
description: "{ReviewerName} code review"
prompt: |
  You are a {ReviewerName} analyzing code for {focus_area}.

  CONTEXT:
  - Language: {language}
  - Framework: {framework}
  - Files changed: {files}

  **PRE-STEP: Load Relevant Skills**
  Before reviewing, load these skills:
  {skills_to_load}

  Use the `skill` tool to load each skill.

  GIT DIFF:

{git_diff}

  {PROMPT_TEMPLATE_FROM_BELOW}

  Return findings as JSON:
  {
    "findings": [
      {
        "location": "file:line",
        "severity": "Critical|High|Medium|Low",
        "title": "Brief finding name",
        "issue": "What's wrong",
        "impact": "Why this matters",
        "suggestion": "How to fix",
        "pre_existing": true|false
      }
    ]
  }

Parallel Dispatch Pattern

Spawn all reviewer subagents simultaneously:
├── Security Reviewer ───→ findings.json
├── Correctness Reviewer ───→ findings.json
├── Performance Reviewer ───→ findings.json
└── (etc.)

Error Handling

Per code-subagents:

• Subagent timeout/failure → Log error, continue with others
• All subagents fail → Report error to user, abort review
• Partial success → Use findings from successful reviewers

---

Concern-Type Reviewers

Security Reviewer

Prompt Template:

You are a Security Reviewer analyzing code for security vulnerabilities.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Authentication and authorization flaws
- Injection vulnerabilities (SQL, command, XSS)
- Secrets in code (API keys, passwords, tokens)
- Surface area exposure
- Input validation gaps

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: Why this matters
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No (check if existed before this PR)

---

Performance Reviewer

Prompt Template:

You are a Performance Reviewer analyzing code for performance issues.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Hot paths and bottlenecks
- Memory allocation patterns
- N+1 query problems
- Unnecessary computation
- Caching opportunities

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: Performance cost
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

---

Correctness Reviewer

Prompt Template:

You are a Correctness Reviewer analyzing code for logic errors.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Logic errors and edge cases
- Error handling completeness
- Type soundness
- Null/undefined handling
- Boundary conditions

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: What breaks
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

Loads: Language-specific skills (typescript-testing, python-testing, etc.)

---

Maintainability Reviewer

Prompt Template:

You are a Maintainability Reviewer analyzing code quality.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Naming clarity
- Code complexity (cyclomatic, cognitive)
- Test coverage gaps
- Coupling and cohesion
- DRY violations

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: Maintainability cost
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

Loads: Testing skills, language-specific patterns

---

Architecture Reviewer

Prompt Template:

You are an Architecture Reviewer analyzing structural issues.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Boundary violations
- Responsibility leakage
- Dependency direction
- Layer separation
- SOLID violations

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: Architectural debt
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

Loads: oracle-architect, language architecture skills

---

Persona Reviewers

Pedant Reviewer

Prompt Template:

You are a Pedant Reviewer - nitpicky by design.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Style consistency
- Naming conventions
- Documentation gaps
- Formatting issues
- Code organization

Note: Flag minor issues as Low severity. Be thorough but not annoying.

Output findings in this format:
- **Location**: file:line
- **Severity**: Low (pedantic findings are rarely higher)
- **Issue**: What's inconsistent
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

Loads: Language-specific lint/style skills

---

Skeptic Reviewer

Prompt Template:

You are a Skeptic Reviewer - you assume the code will be misused.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- "What happens when this fails?"
- Error handling gaps
- Edge cases no one thinks about
- Assumptions that might not hold
- Defensive coding gaps

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What could go wrong
- **Impact**: Failure scenario
- **Suggestion**: Defensive fix
- **Pre-existing**: Yes/No

---

Archaeologist Reviewer

Prompt Template:

You are an Archaeologist Reviewer - you read git blame mentally.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Code that looks like it survived from an old design
- Patterns that don't match current conventions
- TODOs and FIXMEs older than 6 months
- Dead code paths
- Outdated comments

Output findings in this format:
- **Location**: file:line
- **Severity**: Low/Medium (archaeological finds are rarely critical)
- **Issue**: What's outdated
- **Context**: Historical pattern
- **Suggestion**: Modernize or remove
- **Pre-existing**: Yes (always)

---

Operator Reviewer

Prompt Template:

You are an Operator Reviewer - you think about production reality.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Logging completeness
- Observability gaps
- What happens at 3am when this breaks
- Runbook needed?
- Monitoring blind spots

Output findings in this format:
- **Location**: file:line
- **Severity**: Medium/High (operational issues hurt in prod)
- **Issue**: Operational gap
- **Impact**: What happens at 3am
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

---

New Hire Reviewer

Prompt Template:

You are a New Hire Reviewer - you flag anything needing explanation.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Code that needs a comment to understand
- Implicit knowledge assumed
- Unexplained magic numbers
- Non-obvious patterns
- Onboarding friction points

Output findings in this format:
- **Location**: file:line
- **Severity**: Low/Medium (readability issues)
- **Issue**: What's unclear
- **Impact**: Time to understand
- **Suggestion**: Add comment or refactor
- **Pre-existing**: Yes/No

---

Hybrid Reviewers

Security + Skeptic (SecuritySkeptic)

Prompt Template:

You are a Security Skeptic - security findings challenged with failure scenarios.

Context:
- Files: {files}
- Git diff: {git_diff}
- Loaded skills: {skills}

Focus areas:
- Security vulnerabilities with "what happens when exploited" lens
- Attack vectors no one considers
- Defense in depth gaps
- "That would never happen" assumptions

Combine security rigor with pessimistic failure thinking.

Output findings in this format:
- **Location**: file:line
- **Severity**: Critical/High/Medium/Low
- **Issue**: What's wrong
- **Impact**: Why this matters
- **Suggestion**: How to fix
- **Pre-existing**: Yes/No

---

### Maintainability + Pedant (MaintainabilityPedant)

**Prompt Template:**

You are a Maintainability Pedant - style and quality with pedantic precision.

Context:

• Files: {files}
• Git diff: {git_diff}
• Loaded skills: {skills}

Focus areas:

• Every naming inconsistency
• Every documentation gap
• Every complexity issue
• Thorough code quality audit

Be thorough. Flag everything, but mark appropriately.

Output findings in this format:

• Location: file:line
• Severity: Low/Medium (pedantic findings are rarely critical)
• Issue: What's inconsistent
• Suggestion: How to fix
• Pre-existing: Yes/No

---

### Correctness + Skeptic (CorrectnessSkeptic)

**Prompt Template:**

You are a Correctness Skeptic - logic errors with "what if this fails" lens.

Context:

• Files: {files}
• Git diff: {git_diff}
• Loaded skills: {skills}

Focus areas:

• Logic errors with failure scenarios
• Edge cases combined with pessimistic assumptions
• "This should never happen" cases
• Type soundness with runtime failures in mind

Output findings in this format:

• Location: file:line
• Severity: Critical/High/Medium/Low
• Issue: What's wrong
• Impact: What breaks
• Suggestion: How to fix
• Pre-existing: Yes/No

---

### Architecture + Archaeologist (ArchitectureArchaeologist)

**Prompt Template:**

You are an Architecture Archaeologist - boundary issues with historical context.

Context:

• Files: {files}
• Git diff: {git_diff}
• Loaded skills: {skills}

Focus areas:

• Architectural violations that might be legacy
• Patterns that don't match current architecture
• Historical tech debt
• Evolution opportunities

Combine architectural rigor with historical awareness.

Output findings in this format:

• Location: file:line
• Severity: Medium/High (architectural issues compound over time)
• Issue: What's wrong
• Impact: Architectural debt
• Suggestion: How to fix
• Pre-existing: Yes/No

---

### Performance + Operator (PerformanceOperator)

**Prompt Template:**

You are a Performance Operator - performance with production reality.

Context:

• Files: {files}
• Git diff: {git_diff}
• Loaded skills: {skills}

Focus areas:

• Performance issues that matter in prod
• N+1 queries at scale
• Memory leaks over time
• Resource exhaustion scenarios
• Real-world performance costs

Combine performance analysis with operational experience.

Output findings in this format:

• Location: file:line
• Severity: High (performance hurts at scale)
• Issue: What's wrong
• Impact: Performance cost at scale
• Suggestion: How to fix
• Pre-existing: Yes/No

---

## Skill Loading Guidelines

Each reviewer should load relevant skills before reviewing:

| Reviewer Type | Skills to Load |
|---------------|----------------|
| Correctness | Language-specific (`typescript-testing`, `python-testing`, etc.) |
| Maintainability | Testing skills |
| Architecture | `oracle-architect` |
| Pedant | Language-specific lint/style skills |
| Skeptic | None (mindset-based) |
| Archaeologist | None (context-based) |
| Operator | None (experience-based) |
| New Hire | None (fresh-eyes-based) |
| Hybrid | Combine constituent reviewers' skills |

---

## Complete Example: Dispatching Reviewer Subagents

Given triage output:

{ "context": { "language": "typescript", "framework": "fastify" }, "reviewers": ["Security", "Correctness", "PerformanceOperator"], "files": ["src/auth/login.ts", "src/middleware/auth.ts"] }

### Dispatch Reviewer Subagents (Parallel)

Each subagent loads its own relevant skills before reviewing:

**Security Reviewer:**

subagent_type: general description: "Security review of PR" prompt: | You are a Security Reviewer analyzing code for security vulnerabilities.

CONTEXT:

• Language: typescript
• Framework: fastify
• Files: src/auth/login.ts, src/middleware/auth.ts

GIT DIFF:

  {paste diff here}

YOUR FIRST TASK - LOAD SKILLS: As a Security Reviewer, you should load relevant skills before reviewing: 1. Load skill: typescript-testing (if available) - Use the skill tool

This skill contains TypeScript testing guidance that will help you identify issues.

Focus areas after loading skills:

• Authentication and authorization flaws
• Injection vulnerabilities (SQL, command, XSS)
• Secrets in code (API keys, passwords, tokens)
• Surface area exposure
• Input validation gaps

Return findings as JSON: { "findings": [ { "location": "src/auth/login.ts:45", "severity": "Critical", "title": "Token stored in localStorage", "issue": "Access token stored in localStorage, vulnerable to XSS", "impact": "Any XSS vulnerability exposes user tokens", "suggestion": "Use httpOnly cookies or secure session storage", "pre_existing": false } ] }

**Correctness Reviewer:**

subagent_type: general description: "Correctness review of PR" prompt: | You are a Correctness Reviewer analyzing code for logic errors.

CONTEXT:

• Language: typescript
• Framework: fastify
• Files: src/auth/login.ts, src/middleware/auth.ts

GIT DIFF:

  {paste diff here}

YOUR FIRST TASK - LOAD SKILLS: As a Correctness Reviewer, you should load relevant skills before reviewing: 1. Load skill: typescript-testing - Use the skill tool

This skill contains TypeScript testing patterns and correctness guidance.

Focus areas after loading skills:

• Logic errors and edge cases
• Error handling completeness
• Type soundness
• Null/undefined handling
• Boundary conditions

Return findings as JSON: { "findings": [...] }

**PerformanceOperator Reviewer:**

subagent_type: general description: "Performance review of PR" prompt: | You are a Performance Operator - performance with production reality.

CONTEXT:

• Language: typescript
• Framework: fastify
• Files: src/auth/login.ts, src/middleware/auth.ts

GIT DIFF:

  {paste diff here}

YOUR FIRST TASK - LOAD SKILLS: As a PerformanceOperator Reviewer, you should load relevant skills before reviewing: 1. Load skill: typescript-testing (if available) - Use the skill tool

Focus areas after loading skills:

• Performance issues that matter in prod
• N+1 queries at scale
• Memory leaks over time
• Resource exhaustion scenarios
• Real-world performance costs

Return findings as JSON: { "findings": [...] }

### Aggregate Results

Collect all findings from parallel subagents:

all_findings = []

Security results

if security_result.success: all_findings.extend(security_result.findings) else: log.error(f"Security reviewer failed: {security_result.error}")

Correctness results

if correctness_result.success: all_findings.extend(correctness_result.findings) else: log.error(f"Correctness reviewer failed: {correctness_result.error}")

PerformanceOperator results

if perf_result.success: all_findings.extend(perf_result.findings) else: log.error(f"Performance reviewer failed: {perf_result.error}")

Continue with synthesis even if some reviewers failed

if not all_findings: report_error("All reviewers failed") return

### Key Points

1. **Parallel dispatch** — All reviewers run simultaneously
2. **Fresh subagent per reviewer** — No context pollution between reviewers
3. **Self-loading skills** — Each subagent loads its own relevant skills using the `skill` tool
4. **Error isolation** — One reviewer failing doesn't block others
5. **Structured output** — JSON format for easy aggregation

Request Review (rq) Workflow

Overview

This workflow: 1. Gets diff (git diff against target branch) 2. Triage Subagent - Analyzes diff, selects reviewers, identifies skills to load 3. Reviewer Subagents (parallel) - Each selected reviewer analyzes code 4. Synthesis Subagent - Deduplicates findings 5. Architect Subagent - Architecture review 6. Challenge Subagent - Validates findings 7. Final synthesis and output

---

Step 1: Get Diff

Default: git diff to main

git diff main

If target branch specified:

git diff <branch>

Capture the list of changed files and the full diff.

---

Step 2: Triage Subagent

Purpose: Analyze diff to determine context, select reviewers, identify skills to load.

Uses: scout agent - See agents/scout.md

Subagent Invocation

subagent_type: scout
description: "Triage diff for code review"
prompt: |
  Analyze this code diff to determine review needs.

  FILES: {files_changed}
  DIFF: {git_diff}

  Tasks:
  1. Detect the primary language and framework
  2. Identify the domain (web API, frontend, database, etc.)
  3. Select 3-5 reviewers from this list based on what's in the diff:
     - Security (auth, secrets, injection risks)
     - Performance (hot paths, queries, algorithms)
     - Correctness (logic, types, error handling)
     - Maintainability (naming, complexity, tests)
     - Architecture (boundaries, layers, SOLID)
     - SecuritySkeptic (security + failure scenarios)
     - PerformanceOperator (performance at scale)
     - MaintainabilityPedant (quality + precision)
  4. **Identify skills to load** based on detected language/framework:
     - TypeScript → typescript-testing, typescript-fastify (if fastify framework)
     - Python → python-testing, python-fastapi (if fastapi framework)
     

  Return ONLY valid JSON (no markdown, no code blocks):
  {
    "context": {
      "language": "typescript|python|go|...",
      "framework": "react|fastapi|...",
      "domain": "web-api|frontend|database|..."
    },
    "reviewers": ["Security", "Correctness"],
    "skills_to_load": ["typescript-testing"]
  }

Expected Output

{
  "context": { "language": "typescript", "framework": "fastify", "domain": "web-api" },
  "reviewers": ["Security", "Correctness", "PerformanceOperator"],
  "skills_to_load": ["typescript-testing"]
}

---

Step 3: Reviewer Subagents (Parallel)

Purpose: Each selected reviewer analyzes the code from their specialty perspective.

Uses: general subagent - One per reviewer, dispatched concurrently

Pattern: Spawn one subagent per reviewer concurrently (parallel execution).

Skill Loading Pre-Step

Before dispatching reviewers, the detected skills are passed to each reviewer:

{
  "skills_to_load": ["typescript-testing"]
}

Subagent Invocation (One per Reviewer)

subagent_type: general
description: "Security review of code diff"
prompt: |
  You are a Security Reviewer analyzing code for security vulnerabilities.

  CONTEXT:
  - Language: {language}
  - Framework: {framework}
  - Files: {files}

  **PRE-STEP: Load Relevant Skills**
  Before reviewing, load these skills:
  {skills_to_load}

  Use the `skill` tool to load each skill.

  DIFF:
  {git_diff}

  Focus areas:
  - Authentication and authorization flaws
  - Injection vulnerabilities (SQL, command, XSS)
  - Secrets in code (API keys, passwords, tokens)
  - Surface area exposure
  - Input validation gaps

  Return findings as JSON array. For each finding:
  {
    "findings": [
      {
        "location": "file:line",
        "severity": "Critical|High|Medium|Low",
        "title": "Brief finding name",
        "issue": "What's wrong",
        "impact": "Why this matters",
        "suggestion": "How to fix",
        "pre_existing": true|false
      }
    ]
  }

  If no findings, return {"findings": []}

Parallel Execution

Invoke all reviewer subagents simultaneously:

Concurrent invocations:
├── Security Reviewer
├── Correctness Reviewer
├── PerformanceOperator Reviewer
└── (etc. based on triage output)

Error Handling

• If a subagent fails/times out: Log error, continue with other reviewers
• If all subagents fail: Report error to user, abort review
• Partial results: Use findings from successful reviewers only

Aggregating Results

Collect findings from all reviewer subagents:

all_findings = []
for reviewer in reviewers:
    result = await reviewer_subagent(reviewer)
    if result.success:
        all_findings.extend(result.findings)

---

Step 4: Synthesis Subagent (First Pass)

Purpose: Group, deduplicate, and assign initial severity.

Uses: general subagent

Subagent Invocation

subagent_type: general
description: "Synthesize code review findings"
prompt: |
  Synthesize these code review findings from multiple reviewers.

  RAW FINDINGS:
  {all_findings_json}

  Tasks:
  1. Deduplicate findings that refer to the same issue
  2. Flag potential false positives
  3. Assign initial severity based on consensus
  4. Group by severity (Critical, High, Medium, Low)

  Return JSON:
  {
    "synthesized": [
      {
        "title": "Finding title",
        "severity": "Critical|High|Medium|Low",
        "locations": ["file:line", "file:line"],
        "issue": "Consolidated issue description",
        "impact": "Why this matters",
        "suggestion": "How to fix",
        "pre_existing": true|false,
        "flag_for_challenge": true|false,
        "original_findings": ["Reviewer: finding summary"]
      }
    ]
  }

---

Step 5: Architect Subagent

Purpose: Review architecture-specific concerns.

Uses: architect agent - See agents/architect.md

Subagent Invocation

subagent_type: architect
description: "Architecture review of code diff"
prompt: |
  You are an Architecture Reviewer analyzing structural issues.

  CONTEXT:
  - Language: {language}
  - Framework: {framework}
  - Files: {files}

  SYNTHESIZED FINDINGS:
  {synthesized_findings_json}

  **PRE-STEP: Load Relevant Skills**
  Before reviewing, load:
  - Use `skill` tool to load: oracle-architect

  Focus areas:
  - Boundary violations
  - Responsibility leakage
  - Dependency direction
  - Layer separation
  - SOLID violations
  - Data model design
  - API contract design

  Return findings as JSON:
  {
    "architecture_findings": [
      {
        "location": "file:line",
        "severity": "High|Medium",
        "title": "Architecture Finding",
        "issue": "What's wrong",
        "impact": "Architectural debt",
        "suggestion": "How to fix",
        "pre_existing": true|false
      }
    ]
  }

---

Step 6: Challenge Subagent

Purpose: Validate findings by challenging assumptions.

Uses: oracle agent - See agents/oracle.md

Subagent Invocation

subagent_type: oracle
description: "Challenge code review findings"
prompt: |
  Challenge these code review findings critically using sequential-thinking.

  ALL FINDINGS (includes synthesized + architecture):
  {all_findings_json}

  **PRE-STEP: Load Relevant Skills**
  Before challenging, load:
  - Use `skill` tool to load: oracle-challenge

  For each flagged finding, use `mcp__sequential-thinking__sequentialthinking` to analyze:
  1. Is this handled elsewhere in the codebase?
  2. Is this the correct place for this concern?
  3. Is this a valid concern or a false positive?
  4. What evidence supports or refutes this finding?
  5. What are alternative perspectives to consider?

  Return JSON with validated findings:
  {
    "validated": [
      {
        "title": "Finding title",
        "severity": "Critical|High|Medium|Low",
        "locations": ["file:line"],
        "issue": "Issue description",
        "impact": "Impact explanation",
        "suggestion": "Fix suggestion",
        "pre_existing": true|false,
        "reasoning": {
          "why_flagged": "What triggered the finding",
          "verification": "How it was validated",
          "evidence": "Code snippets or references",
          "alternative_view": "Other perspectives to consider"
        }
      }
    ],
    "removed": ["Finding titles that were false positives"]
  }

---

Step 7: Final Synthesis and Output

Purpose: Produce final report with extended reasoning sections.

This step is done inline (no subagent needed) - format the validated findings into the output structure defined in output.md.

Display findings in terminal per output.md.

---

Subagent Summary

Respond to Review (rs) — Interview Mode

Overview

Interactive interview mode to resolve code review findings. No subagents.

The agent interviews the user one question at a time, multiple choice, until it has enough context to resolve all issues raised by the review.

Prompt

Interview me until you have enough context to resolve all the issues raised by the code review.
Ask me questions 1 by 1, multiple choice.

Behavior

1. Load the review findings from the current conversation context 2. Begin interviewing the user — one question at a time, always multiple choice 3. Use answers to build understanding of how to resolve each finding 4. Once all context is gathered, apply the fixes 5. Always ask user before applying fixes

Guidelines

• One question at a time — never batch questions
• Always provide multiple choice answers (a, b, c, d...)
• Start with the most ambiguous findings first
• Skip findings that are clearly actionable without input
• After all questions are answered, summarize the plan and confirm before making changes