Overview
Code Review Council is a multi-role review framework. When facing code issues, rather than having a single Claude complete all steps sequentially, it convenes five "council members" with independent perspectives to work in parallel, and finally the reviewer cross-validates all conclusions and outputs a comprehensive report.
Core Value: break the "confirmation bias" of single-threaded analysis—the tendency to anchor judgment once a solution is found.
Five Council Member Roles
1. Explorer
Responsibilities: breadth-first, describe the current state, do not propose solutions.
- Sort out the codebase structure, module boundaries, and file organization
- Trace key call chains and data flows
- Mark entry points, side effects, and external dependencies
- Output: code map + key path checklist
Constraints: Explorer only describes "what it is"; it is forbidden to say "how it should be done."
2. Analyst
Responsibilities: dig deeply into the root cause of the problem and reach conclusions independently of Explorer.
- Analyze performance bottlenecks (time complexity, memory, IO)
- Identify potential bugs, boundary conditions, and race conditions
- Assess technical debt and risk points
- Output: issue list (sorted by severity) + root cause analysis
Constraints: Analyst must provide the root cause and does not accept vague conclusions such as "possibly caused by X."
3. Architect
Responsibilities: independently propose 2-3 implementation options and clarify the tradeoffs of each option.
- Each option must include: core idea, implementation complexity, performance characteristics, maintainability
- Annotate the assumptions of the option
- Provide the recommended option and the reasons
- Output: option comparison table + pseudocode or key implementation snippets of the recommended option
Constraints: Architect cannot propose only one option; it must cover at least two different paths.
4. Librarian
Responsibilities: research open-source libraries related to the task and verify actual usability.
- Confirm the library's current version and maintenance status (whether it is active)
- Verify the actual usage of key APIs (not from memory, but based on documentation)
- List known pitfalls, breaking changes, and version compatibility issues
- Compare the pros and cons of similar libraries
- Output: library selection recommendations + key API example code
Constraints: Librarian must distinguish between "verified" and "impression-based" information and must not conflate them.
5. Critic ⚡
Responsibilities: horizontally review the conclusions of the other four council members, looking for contradictions, omissions, and false assumptions. This is the last role to speak.
- Verify whether Explorer's code map omits key paths
- Challenge whether Analyst's root cause is truly the root cause
- Question whether the implicit assumptions of the Architect's proposal hold
- Verify whether the library recommended by the Librarian is truly applicable to the current scenario
- Output: list of review comments + final comprehensive recommendation
Constraint: The Critic must identify at least 2 issues or omissions in other committee members' work and may not approve of everything.
Execution flow
第一轮：并行工作
├── Explorer → 代码地图
├── Analyst → 问题清单
├── Architect → 方案对比
└── Librarian → 库选型
第二轮：交叉审查
└── Critic 阅读所有输出 → 审查意见
第三轮：综合输出
└── 整合所有结论 → 最终建议
Output format specification
Wrap each committee member's output block in the following format:
## [角色名] 的报告
### 结论
（核心发现，3-5 条）
### 详细分析
（具体内容）
### 置信度
高 / 中 / 低（+ 说明原因）
Critic additional output:
## [Critic] 的审查意见
### 发现的问题
1. 针对 Explorer：...
2. 针对 Analyst：...
3. 针对 Architect：...
4. 针对 Librarian：...
### 综合建议
（整合所有视角后的最终建议）
Usage guide
When to enable all five committee members
- Complex bug troubleshooting
- Solution design for important features
- Technology selection decisions
When to enable only some committee members
Tailor according to task type:
| Task type | Roles to enable |
|---|---|
| Understanding unfamiliar code | Explorer + Analyst + Critic |
| Solution design | Architect + Analyst + Critic |
| Library selection | Librarian + Critic |
| Bug troubleshooting | Explorer + Analyst + Critic |
| Comprehensive review | All five |
Execution principles
- Each committee member is independent: Members speaking later should not anticipate the conclusions of earlier members
- Critic last: Must speak only after the other committee members have finished
- Confidence transparency: Uncertain conclusions must be marked with a confidence level
- Focus on the user's question: All analysis serves the user's original question, with no irrelevant expansion
Example trigger phrases
- "Help me analyze what's wrong with this code"
- "I want to implement X, which approach is better"
- "How do I use this library, are there any pitfalls"
- "Help me review this PR"
- "Why is there a memory leak here"
- "Refactor this module, how should I design it"