/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:

Domain	Epimetheus asks	Metis asks	Prometheus asks
Documentation	What's stale or misleading?	Is it clear and well-structured?	Does it serve future readers?
Architecture	What's fragile or debt-laden?	Does it follow good patterns?	Does it enable what we're building toward?
Process	What's broken or painful?	Is it efficient and clear?	Will it scale with the team?
CLAUDE.md	What's wrong or outdated?	Is it well-organized?	What should future Claude know?

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

Titan	Lens	Question	Focus
Epimetheus	Hindsight	"What has already gone wrong, or will bite us?"	Bugs, debt, fragility, security
Metis	Craft	"Is this well-made, right now, for what it is?"	Clarity, idiom, structure, tests
Prometheus	Foresight	"Does this serve what we're building toward?"	Vision, extensibility, knowledge capture

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

Reference	When to Read
REVIEWERS.md	Detailed briefs for each Titan
SYNTHESIS.md	Patterns for merging outputs, handling conflicts

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

Pattern	Problem	Fix
Vague scope	Reviewers loop, miss focus	Explicit file list or "changes since X"
Skip synthesis	Three reports, no action	Always synthesize findings
Ignore partial failures	Miss perspectives	Report which reviewer failed, proceed with others
Review before work is "done"	Premature review	Complete the feature first

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