| 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 |
| 全面评审 | 全部五位 |
执行原则
- 各委员独立：后发言的委员不应预判前面委员的结论
- Critic 最后：必须等其他委员完成后再发言
- 置信度透明：不确定的结论必须标注置信度
- 聚焦用户问题：所有分析服务于用户的原始问题，不做无关展开
示例触发语
- "帮我分析一下这段代码有什么问题"
- "我要实现 X，用哪种方案好"
- "这个库怎么用，有没有坑"
- "帮我看看这个 PR"
- "为什么这里会内存泄漏"
- "重构这个模块，怎么设计"
