mcpField
C
code-review

code-review

github.com/yeachan-heo测试与质量33.7k125 次安装今天更新
代码仓库

关于 code-review

code-review 是用于合并前审查指定变更范围的显式启用技能。它汇总 code-reviewer 与 architect 的独立意见，批准必须有双方证据，且技能本身不会实施修复。

主要功能

  1. 01审查指定差异或文件范围
  2. 02并行开展代码与架构审查
  3. 03提供带证据的分级问题
  4. 04依据确定的标准作出审查结论
  5. 05只读审查，不自动修复

适用场景

  1. 01在合并前评估变更
  2. 02检查安全性、质量和可维护性
  3. 03识别架构阻碍与风险
  4. 04在 Autopilot 交接记录审查结果

安装

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

$npx skills add https://github.com/yeachan-heo/oh-my-codex --skill code-review

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

详细介绍

代码审查任务卡

在合并就绪审查中，请显式选择启用此卡。共享的操作不变量位于 templates/AGENTS.md；此卡仅定义审查相关行为。

何时使用

  • 用户要求进行代码审查或质量/安全评估。
  • 变更已准备好进行合并前审查，或重大功能需要独立审查。
  • 不要为实现、广泛规划或自动清理启用此卡。

输入

  • 范围：请求的文件、提交、PR 或整个 diff。
  • 需求/规格、验收标准，以及相关测试/CI 证据。
  • 现有审查产物和已知风险（如有）。
  • 如果用户说 continue，应推进当前已验证的审查步骤，而不是重新开始发现。

先记录范围：

git status --short
git diff --stat
git diff -- <scope>

执行

  1. 识别变更文件和审查边界；不要静默扩大范围。
  2. 并行启动 code-reviewer 和 architect Agent。两条通道都在干净上下文上并行运行，并带有明确范围和产物。如果任一通道无法启动或未返回证据，请报告 independent review unavailable；不要用当前/编写通道替代，也不要批准或将审查标记为合并就绪。
  3. 尊重用户当前的模型和推理/effort 选择。不要在审查通道调用中传入 model 或 reasoning_effort 覆盖。
task(
  agent_type="code-reviewer",
  prompt="CODE REVIEW TASK

Review the supplied scope for spec compliance, security, quality, performance, and maintainability.
Return files reviewed, severity-rated findings with file:line evidence and concrete fixes,
and a recommendation: APPROVE / REQUEST CHANGES / COMMENT. Do not review architecture.
Scope: [scope and artifacts]"
)

task(
  agent_type="architect",
  prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK

Review the same scope for boundaries, interfaces, hidden coupling, long-term tradeoffs,
and the strongest counterargument against approval. Return file:line evidence,
recommendations, and Architectural Status: CLEAR / WATCH / BLOCK.
Scope: [scope and artifacts]"
)

审查分类

  • code-reviewer 检查安全性、代码质量、性能、最佳实践和可维护性。
  • 对每项发现评级：CRITICAL（安全或数据丢失阻塞项）、HIGH（bug/重大坏味道）、MEDIUM（重要改进）或 LOW（风格/建议）。
  • architect 检查显式边界/接口、隐藏耦合、长期权衡和魔鬼代言人担忧。状态为 CLEAR、WATCH（非阻塞担忧）或 BLOCK（合并阻塞项）。
  • 每项发现都要指明 file:line、问题、风险和具体修复；区分事实与建议。

状态/HUD 阶段契约

  • 独立 $code-review 依赖 hook 拥有的 skill-active-state.json（skill:"code-review"，phase:"planning"）；不要创建 code-review-state.json。
  • 在 Autopilot 中，保持 mode:"autopilot" 处于活动状态，并使用 current_phase:"code-review" / skill-active phase:"code-review"；不要激活同级工作流。
  • 在干净审查时，先将产物持久化到 Autopilot 的 handoff_artifacts.code_review 下，再进入 ultraqa。在非干净审查时，持久化发现，并按需使用 rework 或 ralplan。
omx state write --input '{"mode":"autopilot","active":true,"current_phase":"code-review"}' --json

最终综合与 gate

架构状态契约

合并 code-reviewer 建议和 architect 状态。批准需要来自两条独立通道的明确证据；缺失或失败的委派是阻塞性的不可用审查状态，而不是批准回退。最终报告必须让 architect 阻塞项不可能被忽略。

  • 如果 architect 状态为 BLOCK，最终建议为 REQUEST CHANGES。
  • 否则如果 code-reviewer 建议为 REQUEST CHANGES，最终建议为 REQUEST CHANGES。
  • 否则如果 architect 状态为 WATCH，最终建议为 COMMENT。
  • 否则最终建议跟随 code-reviewer 通道。

批准标准：仅当 code-reviewer 返回 APPROVE、architect 状态为 CLEAR，且两条独立通道都返回证据时，才 APPROVE。对于阻塞项、未解决的高/严重发现或不可用通道，应 REQUEST CHANGES。COMMENT 可以记录非阻塞发现。

不要以自审作为回退。如果 code-reviewer 或 architect 路径缺失、不可用、被跳过或失败，应阻止批准，直到存在独立通道证据。在受支持的 omx ralph CLI 兼容路径上，发现项可以触发自动修复后续操作，而无需再次权限提示；普通 code-review 本身仍是只读的，并且不承诺自动修复。

证据/输出契约

返回一份简洁报告，其中包含：

CODE REVIEW REPORT
Files Reviewed: <count>
Total Issues: 0
Architectural Status: CLEAR | WATCH | BLOCK
CRITICAL (0) | HIGH (0) | MEDIUM (0) | LOW (0)
Findings: file:line -> issue, risk, concrete fix (or none)
ARCHITECTURE WATCHLIST: concern, status, recommendation (or none)
- code-reviewer recommendation: COMMENT
- architect status: WATCH
- final recommendation: COMMENT
RECOMMENDATION: COMMENT

将示例性计数和结论替换为实际观察到的值。包含范围、 lane 证据/工件引用、未解决的风险以及验证缺口。

退出条件

当限定范围内的 diff 具有两个独立的 lane 结果和确定性的最终 建议时停止。仅在满足批准标准时报告 APPROVE；否则给出有边界的 REQUEST CHANGES、COMMENT 或不可用评审结果。切勿在缺少所需证据的情况下声称已可合并。

评论

支持 Markdown