Titans

/titans — Code Review Triad

Three reviewers, three lenses. Dispatch in parallel, synthesize findings.

When to Use

• After substantial work — Before /close, when a feature/fix/refactor is "done"
• Before shipping — Final quality gate
• Periodic hygiene — "What's rotting that I haven't noticed?"

When NOT to Use

• Quick fixes under 50 lines
• Exploratory spikes
• Throwaway scripts (unless they stopped being throwaway)
• When you need speed over thoroughness

Beyond Code Review

The three-lens pattern works for more than code. The underlying structure (hindsight/craft/foresight) applies to any artifact worth reviewing thoroughly:

Discovered Jan 2026: Used titans pattern to review trousse itself for CLAUDE.md updates. The three lenses surfaced different categories of findings — infrastructure bugs (Epimetheus), stale references (Metis), undocumented contracts (Prometheus) — that a single-pass review would have missed.

When adapting: Adjust the reviewer briefs for the domain. The output structure (findings, assumptions, could-not-assess, questions) remains useful regardless of what you're reviewing.

The Triad

Why these three? Hindsight catches what's broken. Craft ensures current quality. Foresight protects future-you. Small overlaps are fine — they're perspectives, not partitions.

Orchestration

1. Scope the review

Before dispatching, establish:

• What to review — specific files, directory, or "everything touched this session"
• Context available — CLAUDE.md, README, architecture docs
• Goals if known — roadmap items, intended consumers, lifespan

If scope is unclear, ask. Don't review the entire codebase by accident.

2. Dispatch reviewers

Launch three parallel Task calls. Use Explore subagent with model: "opus" — deep review needs Opus-level reasoning, not Haiku speed.

Each reviewer receives:

• The Reviewer Brief for their lens (from references/REVIEWERS.md)
• The scoped files/context
• Awareness of the other two reviewers (to minimize redundancy)
• The output structure template

Task(
  subagent_type: "Explore",
  model: "opus",
  description: "EPIMETHEUS review of [scope]",
  prompt: "[Reviewer brief from REVIEWERS.md] + [scoped files] + [output template]"
)

Dispatch all three in a single message (parallel execution).

3. Collect outputs

Each reviewer returns structured findings. See Output Structure below.

Partial failures: If a reviewer times out, errors, or returns malformed output:

• Proceed with available outputs (two reviews > none)
• Note the gap in synthesis ("Epimetheus did not complete — hindsight lens missing")
• Consider re-running the failed reviewer with tighter scope

4. Synthesize

Merge outputs into actionable summary:

• High-priority findings (multiple reviewers agree)
• Conflicts reveal trade-offs (disagreements worth surfacing)
• "Could not assess" → documentation debt
• Critical path before shipping

See references/SYNTHESIS.md for synthesis patterns.

Output Structure (All Reviewers)

Each reviewer uses this template:

## [TITAN] Review

### Findings
Numbered list of issues, each with:
- What: the problem
- Where: file/line/function
- Severity: critical | warning | note
- Fix complexity: trivial | moderate | significant

### Assessed Under Assumptions
State the assumption, then the conditional finding:
- "Assuming this is a long-lived component: [concern]"
- "If throwaway prototype, this concern evaporates"

### Could Not Assess
What's missing that blocks review:
- "No visibility into intended consumers"
- "Can't evaluate against patterns — no access to rest of codebase"
- "Token refresh flow undocumented"

### Questions That Would Sharpen This Review
Specific, answerable questions:
- "Is this called by other agents or only orchestration?"
- "What's the expected lifespan?"
- "Who are the intended consumers?"

"Could not assess" is itself diagnostic. A codebase that leaves Prometheus constantly asking "what are we building toward?" has a documentation problem worth surfacing.

Synthesis Output

After collecting all three reviews, produce:

## Review Triad Synthesis

### High-Priority Findings (Multiple Reviewers)
| Finding | E | M | P | Action |
|---------|---|---|---|--------|
| [issue] | ✓ | ✓ | — | [fix]  |

### Conflicts Reveal Trade-offs
| Trade-off | Metis says | Prometheus says | Resolution |
|-----------|------------|-----------------|------------|
| [tension] | [position]| [position]      | [decision] |

### "Could Not Assess" → Documentation Debt
Repeated across reviewers:
- [gap] — [what's needed]

### Critical Path Before Shipping
| # | Issue | Risk | Fix Complexity |
|---|-------|------|----------------|

### Lower Priority (Track as Tech Debt)
- [items to track but not block on]

### Questions to Resolve
1. [question surfaced by review]

Reference Files

Observed Token Consumption

From test runs, reviewers tend to use tokens in this order:

• Epimetheus uses the most — deepest spelunking through code paths
• Metis uses moderate — structural analysis, less exploration
• Prometheus uses the least — architectural assessment from less code

This varies by codebase size and scope clarity. If a reviewer seems to be looping, it usually indicates unclear scope — consider interrupting and re-scoping rather than waiting it out.

Anti-Patterns

Integration with /open and /close

/open
  ↓
[substantial work]
  ↓
/titans  ← you are here
  ↓
[address critical findings]
  ↓
/close

/titans findings can feed into /close:

• Critical issues → "Now" bucket (fix before closing)
• Lower priority → "Next" bucket (create tracker items)
• Documentation debt → handoff Gotchas section