mcpField
R
requesting-code-review

requesting-code-review

github.com/ganyuanran测试与质量1.4k51 次安装5 天前更新
代码仓库

关于 requesting-code-review

面向方法包实现工作的代码审查请求流程，供协调审查子 Agent 的开发者使用。它要求提供结构化的范围与证据，并优先呈现具体问题；审查仅供参考，不等同于完成批准。

主要功能

  1. 01结构化审查背景
  2. 02明确 Git 审查范围
  3. 03优先列出具体问题
  4. 04核对需求与架构基线
  5. 05检查兼容性与淘汰安排

适用场景

  1. 01合并前请求代码审查
  2. 02子 Agent 开发中逐项审查
  3. 03为复杂缺陷修复寻求独立意见

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ganyuanran/aegis --skill requesting-code-review

安装后在 Claude Code 中输入/requesting-code-review确认已加载。

附带文件code-reviewer.md

详细介绍

请求代码审查

使用规范的 code-reviewer.md 模板派遣审查子代理，以便在问题扩散前发现它们。为审查者精心准备恰到好处的评估上下文——绝不提供你会话的历史记录。这样可以让审查者专注于工作成果，而非你的思考过程，并为你继续工作保留自己的上下文。

此技能是方法包实现工作的规范审查请求工作流。只有在掌握了足够的证据和上下文，并明确了要求审查者评估的权限边界后，才能使用它请求审查。

核心原则： 尽早审查，频繁审查。

发现优先： 审查应先列出具体发现，再给出总结。先讲缺陷、风险和测试结果。优点和总体评估同样有用，但不能掩盖正确性、证据、架构或退役方面的问题。

审查就绪不等于获准合并。审查可以减少不确定性并建议是否就绪，但不能取代 verification-before-completion，也不授予完成权限。

何时请求审查

必须：

  • 在子代理驱动开发中的每项任务完成后
  • 完成重大功能后
  • 合并到 main 前

可选但有价值：

  • 陷入困境时（获取全新视角）
  • 重构前（检查基线）
  • 修复复杂错误后

必需输出

在结束此工作流前，你必须能够说明：

  1. 审查的确切范围
  2. 定义成功标准的计划、要求或契约
  3. 定义已接受行为和非目标的产品／需求基线
  4. 定义预期架构状态的架构／运行时边界基线
  5. 已有的最新证据
  6. 必须继续保持的兼容性边界
  7. 旧有所有者／回退方案／补丁将保留、缩减还是退役
  8. 审查者必须具体验证的内容
  9. 审查者仅提供咨询性审查，还是也会给出更高层级的合并建议
  10. Aegis 可见性：说明为何发现优先的排序、证据充分性、基线一致性、兼容性或退役风险对本次审查请求很重要
  11. 语义上下文范围：本次审查必须保留哪些相关规范术语、已弃用别名或公共命名边界

此方法包中的审查仅供参考并以证据为导向，本身不构成权威的完成认定。

从两个方向对比要求与结果：检查是否存在遗漏或弱化，以及是否存在无依据的新增或强化。在授权转换范围内保留相关关系、行为、所有权和限定条件。将有证据支持的缺陷与相关的有效案例配对；不要新增验收标准、拒绝已授权的摘要或更正，也不要要求穷尽所有等价项。

如何请求

1. 收集最少的审查信息：

  • 实现了什么
  • 应符合哪些需求、计划、规范或 ADR
  • 差异必须与哪些基准文档或当前权威文档保持一致，包括 需求／产品对齐，以及架构／当前权威依据对齐
  • 已有哪些证据（测试、命令、日志、截图、差异摘要）
  • 哪些兼容性边界或风险值得审查者留意
  • 是否有应淘汰的旧路径、回退方案、重复负责人或临时补丁
  • 差异是否包含需要 ADR 记录的持久架构决策 Auto Backfill 或基准同步的发现
  • 如果 ADR 操作或基准同步收尾在范围内，是否已使用或应使用 recording-architecture-decisions
  • 涉及公开／领域命名时，相关的有效 CONTEXT.md 内容； 被动阅读不会加载有效建模

如果无法回答这些问题，请先停止并收集信息，再派发审查。

2. 定义 Git 审查范围：

# Before the coordinator's task commit
REVIEW_SCOPE=working-tree
BASE_SHA=$(git rev-parse HEAD)

# Or for already committed work
REVIEW_SCOPE=committed-range
BASE_SHA=<known-start>
HEAD_SHA=$(git rev-parse HEAD)

审查工作区时，明确指出任务涉及的未跟踪路径。不要仅为了让审查者看到它们而暂存文件。

3. 派发审查子 Agent：

使用 Task 工具，并选择通用审查子 Agent。填写规范模板 requesting-code-review/code-reviewer.md；不要依赖单独命名的 Agent 提示词。

占位符：

  • {WHAT_WAS_IMPLEMENTED} - 刚刚构建的内容
  • {PLAN_OR_REQUIREMENTS} - 应实现的功能
  • {EVIDENCE} - 已有的最新测试、命令、日志或验证结果
  • {COMPATIBILITY_BOUNDARY} - 不得破坏的现有行为或接口
  • {RETIREMENT_NOTES} - 旧负责人／回退方案／补丁／重复分支及预期处置方式
  • {REVIEW_SCOPE} - working-tree 或 committed-range
  • {BASE_SHA} - 起始提交
  • {HEAD_SHA} - 结束提交，或 WORKTREE
  • {DESCRIPTION} - 简要摘要

4. 处理反馈：

  • 立即修复严重问题
  • 继续之前修复重要问题
  • 将次要问题记录下来，稍后处理
  • 如果审查者有误，应提出异议并说明理由
  • 如果反馈指出证据不足，应运行缺失的验证，而不是只凭信心争辩
  • 如果反馈指出设计缺陷／实现偏差、过时逻辑或类似架构偏移的 旧别名，应明确决定是现在修复、纠正基准，还是记录淘汰条件

示例

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[Dispatch reviewer subagent using requesting-code-review/code-reviewer.md]
  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
  PLAN_OR_REQUIREMENTS: Task 2 from docs/aegis/plans/deployment-plan.md
  EVIDENCE: pytest tests/index/test_verify.py -v -> 12 passed
  COMPATIBILITY_BOUNDARY: Existing index format and CLI flags must remain stable
  RETIREMENT_NOTES: Legacy repair fallback still exists in old helper; remove once new path covers all four issue types
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

与工作流集成

子 Agent 驱动开发：

  • 每项任务完成后都进行审查
  • 在问题累积前发现它们
  • 完成修复后再进入下一项任务

执行计划：

  • 每批任务（3 项）完成后进行审查
  • 获取反馈、应用反馈，然后继续

临时开发：

  • 合并前进行审查
  • 遇到阻碍时进行审查

审查者必须检查的内容

审查请求必须提示审查者至少检查以下内容：

  • 先列发现：优先检查 Bug、风险和测试
  • 证据是否充分
  • 基线与当前权威信息是否一致
  • 需求／产品是否与已接受的问题、成功证据和非目标一致
  • 架构／当前权威信息是否与负责人、契约、事实来源、兼容性和退役边界一致
  • 将设计缺陷／实现偏移分类，并使用 scope: requirements | architecture | both
  • 旧术语映射：基线缺陷、架构缺陷和架构偏移必须映射回设计缺陷／实现偏移，而不能形成并行的结果术语体系
  • 是否存在重复负责人风险
  • 兼容性边界
  • 是否缺少针对持久性架构决策的 ADR 自动回填或基线同步发现
  • 如果 ADR 行动或基线同步收尾在范围内，是否缺少 recording-architecture-decisions 交接
  • 是否存在未经验证的声明或缺失的证明
  • 旧逻辑应该退役、暂时保留还是逐步收敛
  • 是否存在公共名称偏移、已弃用术语重新出现，或在代码／文档中记录语义变更却未组合 establishing-project-context

如果审查只问“这段代码写得好吗？”，那么请求的说明就不够明确。

危险信号

切勿：

  • 因为“很简单”就跳过审查
  • 忽略严重问题
  • 在重要问题未修复时继续推进
  • 反驳有效的技术反馈
  • 将审查者批准视为权威性完成
  • 不说明已有证据就请求审查
  • 添加新逻辑，却不告知审查者旧路径将如何处理

如果审查者有误：

  • 以技术理由提出异议
  • 展示能证明其有效的代码／测试
  • 请求澄清

审查边界

  • 审查可以建议是否已具备合并条件、指出剩余风险并提出后续工作
  • 审查本身不能授予权威性完成
  • 审查应减少不确定性，而不是掩盖它

参见模板：requesting-code-review/code-reviewer.md

评论

支持 Markdown