五星评审员

协调运行一次覆盖五个专注子代理的、与编程语言无关的评审，随后将结果合并为一份务实的综合报告，供人类或后续 AI 立即采取行动。

核心原则

全局应用以下原则，尤其在各评审员意见不一致时：

1. 优先保障正确性，再优化优雅性。
2. 优先减少概念数量，而非减少代码行数。
3. 倾向高内聚、低耦合，且维护面小的设计。
4. 当替代方案是薄弱的抽象时，允许少量重复。
5. 不得为推测性的未来需求引入额外复杂度。
6. 每一项发现都应有助于下一轮迭代产出更小、更清晰、更安全的代码。

强制多代理规则

每次完整评审运行中，必须启动恰好五个专用子代理。

• 每个评审员角色对应一个子代理。
• 不得将多个评审员角色合并到单个代理中。
• 不得在单一混合上下文分析中模拟评审员职责分离。
• 主代理可预先扫描 diff 并收集上下文，但面向角色的具体评审仍须由独立子代理生成。

必需的评审员身份如下：

• star_correctness
• star_architecture
• star_testability
• star_readability
• star_simplicity

评审工作流

1. 获取评审目标。 参照 references/diff-acquisition.md。
2. 预扫描变更内容。 识别已修改文件、高风险区域、缺失的测试，以及需要周边上下文支持的位置。
3. 启动五个评审子代理。 参照 references/reviewer-rubric.md 中的评分细则。
4. 将各子代理报告写入磁盘。 参照 references/report-template.md。
5. 合并并仲裁结果。 去重重复发现、解决冲突，并全局重建优先级。
6. 撰写一份整合报告。 使用 references/report-template.md 中定义的模板。

默认运行模式

从代码库 diff 出发进行评审，而非从静态风格规则出发。

• 默认优先采用当前工作树的 diff。
• 如用户明确提供，支持提交范围比对（commit-range comparison）、PR diff 输入或原始 patch 输入。
• 必要时可扩展至 diff 范围之外，以理解行为逻辑、模块边界、调用上下文或测试结构。
• 保持语言无关性。依据持久的工程原则评判变更，而非特定语言的偏好。

Diff 优先获取规则

当用户未指定输入形式时，假定当前代码库为评审目标。

• 首先检查代码库状态并获取当前活跃 diff。
• 若 diff 为空，则检查暂存区与非暂存区变更，并确认当前目录及版本上下文。
• 若用户指定了修订范围（revision range），则评审该范围。
• 若用户直接提供了 PR diff 或 patch，则直接评审该制品，不尝试重构。
• 若变更规模极大，则优先聚焦最高风险区域，并明确说明任何范围裁剪。

报告文件位置

每个评审子代理必须将其报告写入当前项目下的以下路径：

docs/five-star-reviewers/YYYY-MM-DD-XX-agent-.md

规则如下：

• 若 docs/five-star-reviewers/ 目录不存在，则自动创建。
• 日期部分使用本地当前日期，格式为 YYYY-MM-DD。
• XX 使用稳定两位序号，便于按顺序快速浏览全部五个文件。
• 使用以下默认文件名：
  • docs/five-star-reviewers/YYYY-MM-DD-01-agent-correctness.md
  • docs/five-star-reviewers/YYYY-MM-DD-02-agent-architecture.md
  • docs/five-star-reviewers/YYYY-MM-DD-03-agent-testability.md
  • docs/five-star-reviewers/YYYY-MM-DD-04-agent-readability.md
  • docs/five-star-reviewers/YYYY-MM-DD-05-agent-simplicity.md
• 主代理随后应在同一目录下撰写整合报告，例如：
  • docs/five-star-reviewers/YYYY-MM-DD-06-consolidated-review.md

若运行环境禁止写入文件，仍需在聊天界面中输出全部报告，但须明确声明预期的磁盘输出未能生成。

五位评审员

使用以下评审员前缀，以便其输出易于识别为同一能力体系的一部分：

• star_correctness
• star_architecture
• star_testability
• star_readability
• star_simplicity

各评审员须严守自身职责边界。允许为理解上下文而查看邻近代码，但不得重复其他评审员的关注点。详细职责范围、严重性判定指南及防噪声规则详见 references/reviewer-rubric.md。

主代理的整合规则

主代理为最终裁决者。

• 将不同评审员提出的重复问题合并为一项更强有力的问题。
• 显式解决冲突。例如：若一位评审员认为需增加抽象，另一位则指出该抽象并无必要，则应选择最能兼顾正确性、最少概念数量与最低维护负担的方案。
• 将问题重新排序为全局 p0、全局 p1 和 全局 p2，而非简单拼接各评审员列表。
• 为值得保留的优质建议单独设立“建议保留”章节，避免后续 AI 过度修正。
• 优先提供可操作的指导，而非抽象评论。

严重性规范

仅当问题有实际变更作为依据时，才提出相应发现。

• p0：可能引发正确性破坏、严重边界违规，或存在关键校验缺口，可能导致缺陷随发布上线。
• p1：具有实质意义的可维护性、架构、可读性或可测试性问题，应在下一轮迭代中处理。
• p2：真实存在但非紧急的改进、清理或简化机会。

避免将模糊的最佳实践观点升格为高优先级问题。

证据要求

每个问题均须包含以下三项内容：

• 具体的定位信息（如文件、函数、模块或 diff 片段）
• 该问题为何重要
• 切实可行的修复建议

禁止输出泛泛而谈的建议（例如“改善结构”或“增加更多测试”），除非明确指出具体位置及原因。

预算与焦点控制

确保评审输出高度凝练且具备实用价值。

• 每位评审员建议最多输出 3 个 p0、5 个 p1 和 5 个 p2 问题。
• 跳过低价值的风格细节（style nits），除非其显著影响理解或维护成本。
• 当 diff 规模较大时，应优先关注高风险逻辑、边界条件、错误处理、集成点及测试缺口，再考虑代码润色类建议。

简洁性是一等公民

将不必要的代码膨胀视为真实的工程问题。

特别关注以下现象：

• 复用价值极低的一次性抽象
• 仅做行为转发的 wrapper、manager、helper 或 adapter
• 比其所配置逻辑更复杂的配置层
• 为推测性灵活性而抬高当前维护成本
• 在保障正确性的前提下，减少文件数量、间接层级或分支结构的机会

代码更短并不天然更好；真正目标是降低认知负荷与维护成本。

输出预期

生成一份既适合人类阅读、又可直接作为后续 AI 实现环节输入的报告。

采用 references/report-template.md 中定义的整合报告结构。报告应清晰呈现：

• 必须立即修改的内容
• 下一轮应修改的内容
• 可延后处理的内容
• 不应进一步“优化”的内容

何时扩展上下文审查

当仅凭 diff 不足以判断行为表现或设计质量时，应主动扩展上下文范围。

常见触发场景包括：

• 被修改的函数高度依赖周边辅助函数
• 接口变更影响了其他位置的调用方或实现方
• 测试看似薄弱，且相关测试可能位于 diff 范围之外
• 新引入的抽象声称具备更广泛的复用能力，但 diff 中未体现
• 潜在缺陷风险取决于生命周期、状态或集成行为，而这些信息无法仅从补丁中获知

务必审慎扩展：只为提升判断质量而读取更多上下文，而非漫无目的游荡。