メニュー
以架构师视角审查代码变更，关注模块边界、DRY 复用性、测试完整性、协议合规和长期可维护性。当需要审查 PR、工作区变更或提交代码时使用。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | code-review |
| description | 以架构师视角审查代码变更，关注模块边界、DRY 复用性、测试完整性、协议合规和长期可维护性。当需要审查 PR、工作区变更或提交代码时使用。 |
| argument-hint | <可选：PR 编号、commit range 或文件路径，留空则审查当前工作区变更> |
| model | opus |
目标不是"代码能不能跑"，而是"这段变更是否让项目更健康"。
复用：本 skill 的审查 rubric 是全项目唯一来源。
code-reviewer子代理（隔离上下文消偏见）与 add-feature / fix-issue 的内嵌审查门控均复用本 rubric，不另写。内嵌门控流水线见skills/code-review/resources/embedded-review-gate.md。
根据输入确定代码变更集：
| 输入 | 取变更方式 |
|---|---|
| 无参数 | git diff + git diff --cached |
| PR 编号 | gh pr diff <number> |
| commit range | git diff <range> |
| 文件路径 | 直接审查指定文件 |
输出变更文件清单，按模块/crate 分组，标注变更类型（新增/修改/删除）。
重要：读变更涉及的完整文件，不要只看 diff。很多问题只有在上下文中才能发现。
检查变更是否违反项目的分层/依赖方向约束。
按项目参见
{baseDir}/resources/<project>.md"模块边界"章节。
如果变更引入了新的公开类型/方法：
逐条检查，一经发现标记 🔴：
搜索项目中已有的工具函数、基类、公共模块，确认变更是否与之重复。如已有封装能力不足，正确做法是增强已有封装而非新建。
对新增函数/逻辑块，搜索是否已有相似实现。重点关注：错误处理逻辑、超时/重试逻辑、序列化辅助函数。
各项目的已有抽象和已知重复区域参见
{baseDir}/resources/<project>.md。
涉及协议类型/事件/数据结构的变更，此步骤为强制检查。
变更涉及 SMCP 协议类型时：
docs/specification/ 规范文档变更涉及 OASP 事件/DTO 时：
{namespace}:{action}:{target}协议详情参见
skills/add-feature/resources/a2c.md和skills/add-feature/resources/oasp.md。
| 变更类型 | 测试要求 |
|---|---|
| 新增公开 API | 必须有单元测试 |
| Bug 修复 | 必须有复现测试（修复前失败、修复后通过） |
| 行为变更 | 现有测试是否需要更新 |
| 新增事件/DTO | 必须有序列化/反序列化测试 |
一经发现直接标记 🔴 阻塞合并：
assert True / assert!(true) 等与被测逻辑无关判定标准：如果被测函数实现替换为空函数，测试还能通过吗？如果能，就是欺骗性测试。
变更不得导致测试覆盖率下降。审查时须运行覆盖率检查，确认达到项目要求的最低标准：
各项目覆盖率要求和检查命令参见
{baseDir}/resources/<project>.md"测试覆盖度"章节。
如果变更新增了代码但未新增对应测试，导致覆盖率下降，标记 🔴 阻塞合并。
测试默认不允许跳过。仅在依赖外部重量级服务时允许，且必须注释说明原因。不得跳过因代码缺陷而失败的测试。
测试约定按项目参见
{baseDir}/resources/<project>.md。
检查变更中是否存在对上游问题的不当回避：
仅适用于有上游依赖的项目（如 tfrobot-client → rust-sdk）。
## 审查摘要
- 审查范围：<变更文件数、涉及模块>
- 总体评价：✅ 可合并 / ⚠️ 需修改后合并 / ❌ 需重新设计
## 发现的问题
### 🔴 必须修复（阻塞合并）
<编号>. <文件:行号> — <问题描述> — <修复建议>
### 🟡 建议改进（不阻塞但推荐）
<编号>. <文件:行号> — <问题描述> — <改进方向>
### 🟢 值得肯定
<变更中做得好的地方——好的抽象、好的测试覆盖、消除技术债务等>
## 测试覆盖评估
- 覆盖率变化：<变更前> → <变更后>（是否达标：✅/❌）
- 新增/修改的公开 API 是否有测试：✅/❌
- 测试是否遵循项目约定：✅/❌
- 建议补充的测试用例：<列表>
只报告发现的问题，没问题的维度不需要列出。
审查完成后，建议变更作者执行项目对应的验证命令。
验证命令按项目参见
{baseDir}/resources/<project>.md。
A2C-SMCP 体系新增功能的流程门控。强制协议先行——任何涉及协议的 Feature 必须先在协议仓库通过评审、合并、发布后，代码仓库才可跟进实现。当用户提出新功能需求或 Feature Request 时调用。
以架构师视角分析并修复问题，强制 plan 模式，杜绝补丁式修复。涉及协议时严格按协议来，协议有问题则协议先行调整，代码再跟进。当遇到 Bug 反馈、错误日志或功能异常时使用。
把一个较大的 A2C-SMCP Epic / Story / GitHub Issue（或 Jira / CNB Issue）科学拆成多个可独立交付的子任务，输出含依赖图与集成回归守护的拆分方案，并在对应平台用 sub-issue 能力下单。A2C 特有：涉及协议的拆分强制「协议先行」——协议子任务置于依赖图根，代码仓库子任务 blocked-by 它。当用户说「拆分这个任务」「把 Epic 拆成子任务」「分解 Story」「给个切刀方案」时触发。
指导第三方 MCP Server 开发者通过标准 MCP Resource 协议暴露 window://（桌面状态）与 skill://（能力包）资源，接入 A2C-SMCP Desktop / SKILL 通道。当为 MCP Server 增加 A2C-SMCP 集成、把服务实时状态暴露给 Desktop、或通过 MCP 分发 SKILL 时使用。
反馈 A2C-SMCP Marketplace Skill 的问题或改进建议。自动识别当前会话中使用的 Skill，提取优化点，收集版本信息，提交 GitHub Issue 到 a2c-smcp-skills 仓库。当使用某个 Skill 时发现步骤错误、分支遗漏、文档过时等问题时调用。
审查 enhance-skill 提交的 GitHub Issue，评估建议合理性，与用户商议后实施改进。用于 marketplace 维护者持续提升 Skill 质量。