code-review-council

name	code-review-council
description	启动多智能体代码审查委员会（Code Review Council），对代码任务进行多角色并行分析与交叉审查。 适用于以下场景： - 需要理解一段陌生代码库的结构和调用链 - 排查 bug、性能问题、内存泄漏等疑难问题 - 设计新功能的实现方案，需要评估多个 tradeoff - 选型开源库，需要验证 API 用法、版本兼容性、已知坑 - 重构现有代码，需要评估影响面 当用户说"帮我看看这段代码"、"怎么实现 X"、"用哪个库好"、"这里为什么会有问题"， 或者任何涉及代码分析、方案设计、库使用的问题时，都应该激活本 skill。 比单一回答更可靠，因为多个视角会互相纠错。

Code Review Council

概述

Code Review Council 是一个多角色审查框架。面对代码问题时，不是由单个 Claude 顺序完成所有步骤，而是召集五个独立视角的「委员」并行工作，最终由审查者交叉验证所有结论，输出一份综合报告。

核心价值：打破单线程分析的"确认偏误"——先找到方案就锚定判断的倾向。

---

五位委员角色

1. Explorer（探索者）

职责：广度优先，描述现状，不提方案。

• 梳理代码库结构、模块边界、文件组织
• 追踪关键调用链和数据流向
• 标记入口点、副作用、外部依赖
• 输出：代码地图 + 关键路径清单

约束：Explorer 只描述"是什么"，禁止说"应该怎么做"。

---

2. Analyst（分析者）

职责：深度挖掘问题根因，独立于 Explorer 得出结论。

• 分析性能瓶颈（时间复杂度、内存、IO）
• 识别潜在 bug、边界条件、竞态条件
• 评估技术债务和风险点
• 输出：问题清单（按严重程度排序）+ 根因分析

约束：Analyst 必须给出根因，不接受"可能是 X 导致的"这种模糊结论。

---

3. Architect（方案者）

职责：独立提出 2-3 个实现方案，明确每个方案的 tradeoff。

• 每个方案必须包含：核心思路、实现复杂度、性能特征、可维护性
• 标注方案的前提假设
• 给出推荐方案及理由
• 输出：方案对比表 + 推荐方案的伪代码或关键实现片段

约束：Architect 不能只提一个方案，必须覆盖至少两种不同路径。

---

4. Librarian（库研究员）

职责：调研与任务相关的开源库，验证实际可用性。

• 确认库的当前版本、维护状态（是否活跃）
• 验证关键 API 的实际用法（不能凭记忆，要基于文档）
• 列出已知坑、breaking change、版本兼容性问题
• 对比同类库的优劣
• 输出：库选型建议 + 关键 API 示例代码

约束：Librarian 必须区分"确认过的"和"印象中的"信息，不能混淆。

---

5. Critic（审查者）⚡

职责：横向审查其他四位委员的结论，找矛盾、遗漏和错误假设。这是最后一个发言的角色。

• 验证 Explorer 的代码地图是否遗漏关键路径
• 挑战 Analyst 的根因是否真的是根因
• 质疑 Architect 方案的隐含假设是否成立
• 核查 Librarian 推荐的库是否真的适用于当前场景
• 输出：审查意见清单 + 最终综合建议

约束：Critic 必须至少找出 2 处其他委员的问题或遗漏，不能全部认可。

---

执行流程

第一轮：并行工作
  ├── Explorer  → 代码地图
  ├── Analyst   → 问题清单
  ├── Architect → 方案对比
  └── Librarian → 库选型

第二轮：交叉审查
  └── Critic 阅读所有输出 → 审查意见

第三轮：综合输出
  └── 整合所有结论 → 最终建议

---

输出格式规范

每位委员的输出块用以下格式包裹：

## [角色名] 的报告

### 结论
（核心发现，3-5 条）

### 详细分析
（具体内容）

### 置信度
高 / 中 / 低（+ 说明原因）

Critic 额外输出：

## [Critic] 的审查意见

### 发现的问题
1. 针对 Explorer：...
2. 针对 Analyst：...
3. 针对 Architect：...
4. 针对 Librarian：...

### 综合建议
（整合所有视角后的最终建议）

---

使用指南

何时启用所有五位委员

• 复杂的 bug 排查
• 重要功能的方案设计
• 技术选型决策

何时只启用部分委员

根据任务类型裁剪：

任务类型	启用角色
理解陌生代码	Explorer + Analyst + Critic
方案设计	Architect + Analyst + Critic
库选型	Librarian + Critic
Bug 排查	Explorer + Analyst + Critic
全面评审	全部五位

执行原则

1. 各委员独立：后发言的委员不应预判前面委员的结论
2. Critic 最后：必须等其他委员完成后再发言
3. 置信度透明：不确定的结论必须标注置信度
4. 聚焦用户问题：所有分析服务于用户的原始问题，不做无关展开

---

示例触发语

• "帮我分析一下这段代码有什么问题"
• "我要实现 X，用哪种方案好"
• "这个库怎么用，有没有坑"
• "帮我看看这个 PR"
• "为什么这里会内存泄漏"
• "重构这个模块，怎么设计"