titans

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/titans — Code Review Triad

/titans — 代码审查三元组

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?"

完成大量工作后 — 执行/close前，当功能/修复/重构已“完成”时
上线前 — 最终质量把关
定期维护 — “哪些未被注意到的部分正在恶化？”

When NOT to Use

不适用场景

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

少于50行的快速修复
探索性实验代码
一次性脚本（除非它已不再是一次性的）
更注重速度而非全面性的场景

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.

三维审查模式不仅适用于代码。其核心结构（后见之明/工艺性/前瞻性）可应用于任何需要全面审查的产物：

领域	Epimetheus 关注	Metis 关注	Prometheus 关注
文档	哪些内容过时或有误导性？	内容是否清晰且结构合理？	是否能满足未来读者的需求？
架构	哪些部分脆弱或存在技术债务？	是否遵循良好的设计模式？	是否能支撑我们未来的构建目标？
流程	哪些环节存在问题或痛点？	是否高效且清晰？	是否能随团队规模扩展？
CLAUDE.md	哪些内容错误或过时？	结构是否清晰？	未来的Claude需要了解哪些信息？

2026年1月发现： 运用三元组模式审查trousse本身，以更新CLAUDE.md。三个视角发现了不同类别的问题——基础设施漏洞（Epimetheus）、过时引用（Metis）、未记录的约定（Prometheus）——这些问题在单次审查中很容易被遗漏。

适配时注意： 根据不同领域调整审查者的任务说明。输出结构（发现、假设、无法评估的内容、问题）无论审查什么产物都同样适用。

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.

Titan	视角	核心问题	关注重点
Epimetheus	后见之明	“哪些问题已经存在，或将会出现？”	漏洞、技术债务、脆弱性、安全性
Metis	工艺性	“当前实现是否优质、符合目标？”	清晰度、编码规范、结构、测试
Prometheus	前瞻性	“是否能支撑我们未来的构建目标？”	愿景、可扩展性、知识留存

为什么是这三个？ 后见之明捕捉已存在的问题，工艺性保障当前质量，前瞻性保护未来的你。存在少量重叠是正常的——它们是不同视角，而非严格划分的领域。

Orchestration

执行流程

1. Scope the review

1. 确定审查范围

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.

调度审查者前，需明确：

审查对象 — 具体文件、目录，或“本次会话中修改的所有内容”
可用上下文 — CLAUDE.md、README、架构文档
已知目标 — 路线图项、目标用户、生命周期

如果范围不明确，请询问。避免意外审查整个代码库。

2. Dispatch reviewers

2. 调度审查者

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).

发起三个并行的Task调用。使用

Explore

子Agent并指定

model: "opus"

——深度审查需要Opus级别的推理能力，而非Haiku的速度。

每位审查者会收到：

对应视角的审查者任务说明（来自references/REVIEWERS.md）
确定范围的文件/上下文
知晓其他两位审查者的存在（以减少重复工作）
输出结构模板

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

在同一条消息中调度三个审查者（并行执行）。

3. Collect outputs

3. 收集输出结果

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

每位审查者返回结构化的审查结果。详见下方的输出结构。

部分失败处理： 如果某个审查者超时、出错或返回格式错误的输出：

基于已有输出继续（两次审查好过没有）
在汇总结果中注明缺失的视角（“Epimetheus未完成——缺少后见之明视角”）
考虑缩小范围后重新运行失败的审查者

4. Synthesize

4. 汇总结果

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.

将输出结果合并为可执行的总结：

高优先级发现（多位审查者达成共识）
冲突揭示权衡点（值得关注的分歧）
“无法评估”→文档债务
上线前的关键路径

汇总模式详见references/SYNTHESIS.md。

Output Structure (All Reviewers)

所有审查者的输出结构

Each reviewer uses this template:

markdown

undefined

每位审查者需使用以下模板：

markdown

undefined

[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

编号列出问题，每个问题包含：

问题内容：具体问题
位置：文件/行号/函数
严重程度：critical | warning | note
修复复杂度：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"

哪些缺失的信息导致无法评估：

“无法了解目标用户”
“无法评估是否符合设计模式——无法访问代码库的其他部分”
“Token刷新流程未记录”

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.

---

具体、可回答的问题：

“该组件是被其他Agent调用还是仅被编排层调用？”
“预期生命周期是多久？”
“目标用户是谁？”


**“无法评估”本身就是诊断信息。** 如果Prometheus持续询问“我们的构建目标是什么？”，说明代码库存在需要解决的文档债务。

---

Synthesis Output

汇总输出结果

After collecting all three reviews, produce:

markdown

undefined

收集到三个审查结果后，生成：

markdown

undefined

Review Triad Synthesis

High-Priority Findings (Multiple Reviewers)

Finding	E	M	P	Action
[issue]	✓	✓	—	[fix]

发现	E	M	P	行动
[问题]	✓	✓	—	[修复方案]

Conflicts Reveal Trade-offs

Trade-off	Metis says	Prometheus says	Resolution
[tension]	[position]	[position]	[decision]

权衡点	Metis 观点	Prometheus 观点	决议
[矛盾点]	[观点]	[观点]	[决议]

"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

[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

参考文档	阅读时机
REVIEWERS.md	各Titan角色的详细任务说明
SYNTHESIS.md	结果合并模式、冲突处理方法

Observed Token Consumption

观测到的Token消耗情况

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.

测试运行显示，审查者的Token消耗顺序如下：

Epimetheus 消耗最多——需要深入探索代码路径
Metis 消耗中等——侧重结构分析，探索较少
Prometheus 消耗最少——基于少量代码进行架构评估

Token消耗会因代码库规模和范围清晰度而变化。如果某个审查者陷入循环，通常意味着范围不明确——考虑中断并重新定义范围，而非等待。

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

模式	问题	解决方法
范围模糊	审查者陷入循环，偏离重点	明确列出文件或“自X以来的变更”
跳过汇总	生成三份报告，但无行动指引	务必汇总审查结果
忽略部分失败	遗漏视角	报告哪个审查者失败，基于已有结果继续
工作未“完成”就审查	审查时机过早	先完成功能开发

Integration with /open and /close

与/open和/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

/open
  ↓
[完成大量工作]
  ↓
/titans  ← 当前位置
  ↓
[处理高优先级发现]
  ↓
/close

/titans的审查结果可用于/close流程：

关键问题 → “当前” bucket（关闭前修复）
低优先级问题 → “下一步” bucket（创建跟踪项）
文档债务 → 移交至Gotchas部分