2026/9/10 23:29:52
FEATURED · 精选文章 
oh-my-codex 双通道独立代码评审code-review Skill 的合并就绪门控实战指南【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读本文讲解 oh-my-codexOMX中code-reviewSkill 的完整运作机制它以显式 opt-in 的方式为合入前的变更提供双通道独立评审code-reviewer与architect并行、互不替代并通过确定性规则合成最终裁决APPROVE / REQUEST CHANGES / COMMENT把评审不可用与拒绝合入绑定为硬性门禁。读完本文你将掌握如何用$code-review触发合并就绪评审、如何构造双通道 agent 调用、如何解读评审分类法与状态契约以及如何对接 Autopilot / ultraqa / Ralph 等下游工作流。核心入口文档为 skills/code-review/SKILL.md配套的评审角色定义与运行态约束分别在 prompts/code-reviewer.md、prompts/architect.md 与 templates/AGENTS.md 中仓库对这份契约有专门的测试守卫见 src/hooks/tests/code-review-skill-contract.test.ts。何时使用 code-review一份明确的触发边界code-review是一个显式 opt-in的任务卡Task Card不是默认流水线的一部分。其使用时机在 skills/code-review/SKILL.md 中写得很清楚应该用用户明确要求代码评审、质量或安全评估变更在合并前已就绪、需要一次独立评审或一个大型功能需要独立于作者的第二双眼睛。不要用实现、广泛规划或自动清理类任务——这些场景有各自的 Skill如$deep-interview、$plan、$team、$ultragoal负责不应被评审卡抢占。这与仓库的关键词路由实现一致src/hooks/keyword-registry.ts 将code review、$code-review、review code三个触发词以 priority 6 路由到code-reviewSkill在 hook 上下文不可用时AGENTS.md 规定以显式$code-review调用为准。输入与作用域先记录再评审发起评审前卡片要求先锁定输入集Scope被请求评审的文件、commit、PR 或整个 diff。Requirements / specification验收标准、相关的测试 / CI 证据。已有评审产物与已知风险如有。continue语义如果用户说continue应在当前已验证的评审步骤上继续推进而不是重启发现流程。SKILL 建议用如下命令记录作用域基线git status --short git diff --stat git diff -- scope作用域一经记录识别变更文件与评审边界不要静默扩大范围就成为评审的第一个执行约束——这保证了评审结论可以精确回溯到被审对象。执行模型双通道并行禁绝自我评审评审执行的核心是两个独立 lane 并行运行、互不替代识别变更文件与评审边界。并行启动code-reviewer与architect两个 agent两者都在干净上下文clean context中、携带显式 scope 与产物运行。如果任一 lane 无法启动或未返回证据必须报告independent review unavailable不得用当前/作者 lane 顶替也不得批准或标记评审为合并就绪。尊重用户当前的模型与 reasoning/effort 选择不要在评审 lane 调用中传递model或reasoning_effort覆盖参数。SKILL 给出的原生调用模板如下两段task(...)并行task( agent_typecode-reviewer, promptCODE 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_typearchitect, promptARCHITECTURE / DEVILS-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] )注意模板刻意不携带model或reasoning_effort这正是 src/hooks/tests/code-review-skill-contract.test.ts 用doesNotMatch断言守卫的契约防止评审 lane 悄悄覆盖用户的选择。两个 lane 的角色定义在 agent 目录中两个角色都有显式定义src/agents/definitions.ts 与 #L170-L179角色检查面姿态 / 工具默认推理力度code-reviewer规格符合性、安全、质量、性能、最佳实践、可维护性frontier-orchestrator只读higharchitect边界/接口、隐藏耦合、长期权衡、魔鬼代言人反方论证frontier-orchestrator只读xhighprompts/code-reviewer.md 进一步定义了该 lane 的两阶段检查法Stage 1 — Spec Compliance确认每个需求都被覆盖、预期问题被解决、没有添加未经请求的行为。根因守卫root-cause guard拒绝那些吞掉失败、压制诊断、引入宽泛替代路径或绕过主契约的 fallback/workaround要求最小根因修复、显式失败行为与回归证据。Stage 2 — Code Quality检查正确性、安全、性能、可维护性与最佳实践并在可行时对每个变更文件运行诊断重点排查硬编码密钥、注入、XSS、不安全默认值、静默错误处理等模式。每条发现必须给出 CRITICAL/HIGH/MEDIUM/LOW 定级与具体file:line说明影响与根因再给出可落地的修复建议事实与建议必须区分。prompts/architect.md 则约束该 lane不评审没打开过的代码重要论断必须引用文件与行号范围先分离根因与症状、证据与不确定性在双通道评审中必须显式输出CLEAR/WATCH/BLOCK架构状态涉及共识评审时还要给出反题antithesis、权衡张力与综合synthesis。评审分类法统一的分级语言两个 lane 的产出用同一套分级语言汇总code-reviewer检查Security、Code Quality、Performance、Best Practices、Maintainability五个维度。每条发现按CRITICAL安全或数据丢失阻断项、HIGHbug/重大坏味道、MEDIUM重要改进、LOW风格/建议定级。architect输出架构状态CLEAR无问题、WATCH不阻断但有顾虑、BLOCK合并阻断项。每条发现必须包含file:line、问题描述、风险与具体修复方案并区分事实与建议。这套定级语言与 prompts/code-reviewer.md 的输出契约一一对应CRITICAL: X (must fix)/HIGH: Y (should fix)/MEDIUM: Z (consider fixing)/LOW: W (optional)保证多 lane 评审结果可以机械合并。状态 / HUD 阶段契约评审在哪运行code-review对运行时状态有明确归属约束避免与其它工作流互相污染独立运行$code-review依赖 hook 持有的skill-active-state.jsonskill:code-review、phase:planning不要自建code-review-state.json——这与 AGENTS.md 的hook 拥有正常 skill 激活与工作流状态持久化skills 不得复制或改写 hook 持有的状态一致。Autopilot 内运行保持mode:autopilot激活current_phase:code-review/ skill-activephase:code-review不要激活对等的兄弟工作流。评审通过在进入ultraqa前将产物持久化到 Autopilot 的handoff_artifacts.code_review评审未通过持久化发现结果并按需走rework或ralplan。Autopilot 阶段机把code-review与ultraqa列为合法的子阶段src/autopilot/fsm.ts且完成门控测试明确要求从 implementation 到 code-review 的转换以及进入 ultraqa 前的 code-review 证据src/autopilot/tests/completion-gate-advisory.test.ts。在附加 tmux 的 OMX CLI 运行时可用以下命令写入状态omx state write --input {mode:autopilot,active:true,current_phase:code-review} --jsonomx state命令支持read|write|clear|list-active|get-status子命令完整用法见 src/cli/state.ts。最终综合与门禁确定性的合并裁决架构状态契约Architectural Status Contract最终裁决必须同时合并两个独立 lane 的证据任一 lane 缺失或委托失败都属于阻断性不可用状态而不是批准的降级回退。合并规则是确定性的若架构状态为BLOCK→ 最终建议REQUEST CHANGES。否则若code-reviewer建议为REQUEST CHANGES→ 最终建议REQUEST CHANGES。否则若架构状态为WATCH→ 最终建议COMMENT。否则最终建议跟随code-reviewerlane。批准条件非常严格APPROVE 仅在code-reviewer返回 APPROVE、架构状态为 CLEAR、且两个独立 lane 都返回了证据时才能给出REQUEST CHANGES适用于出现阻断项、未解决的高/严重发现或 lane 不可用COMMENT用于记录非阻断性发现。这套映射在 src/hooks/tests/code-review-skill-contract.test.ts 中被逐条断言包括BLOCK → REQUEST CHANGESWATCH → COMMENT以及APPROVE 的双 lane 证据前提。不可用即不可批无自我评审回退禁止自我评审回退如果code-reviewer或architect路径缺失、不可用、被跳过或失败必须阻止批准直到存在独立 lane 证据。Ralph 例外在显式 Ralph 路径上发现结果可以触发自动修复跟进而无需再次征求权限但普通code-review本身是只读的不承诺自动修复。最终报告必须让架构阻断项不可能被漏看。证据 / 输出契约可被下游消费的评审报告评审结束必须返回一份紧凑的报告SKILL 提供了可直接套用的模板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模板中的计数与裁决为示例值需替换为真实观察结果报告还应包含 scope、lane 证据/产物引用、未解决风险与验证缺口。示例中的Total Issues: 0与分级计数之和相等这一自洽性同样被契约测试校验src/hooks/tests/code-review-skill-contract.test.ts。退出条件何时可以停当 scoped diff 拥有了两个独立 lane 结果与确定性的最终建议时评审结束只有在满足批准条件时才报告APPROVE否则留下有界的REQUEST CHANGES、COMMENT或评审不可用结果没有所需证据绝不宣称合并就绪。与周边工作流的衔接Autopilotcode-review是deep-interview → ralplan → ultragoal主链之外被显式挂载的评审阶段通过omx state write与handoff_artifacts.code_review与ultraqa交接见上文状态 / HUD 阶段契约。Ralph显式 Ralph 路径下评审发现可触发自动修复跟进普通code-review保持只读不会悄悄改动代码。团队模式AGENTS.md 将代码评审列为适合显式团队编排的多 lane 工作之一templates/AGENTS.md但在code-review卡内双 lane 委托必须走原生task(agent_type...)不携带model/reasoning_effort覆盖。小结把评审变成可验证的门禁oh-my-codex 的code-reviewSkill 用一个简单而强约束的模型解决了 AI 评审最大的隐患——自我背书两条独立 lane 必须都给出证据缺失即不可批裁决由确定性规则合成不依赖主观判断状态归属明确hook 持有不与兄弟工作流互踩报告模板结构化可被ultraqa、rework、ralplan等下游机械消费。对任何把合并前独立评审当作硬要求的团队这套契约都值得直接借鉴。参考路径速查skills/code-review/SKILL.md — 评审任务卡本体本文主体prompts/code-reviewer.md — code-reviewer lane 的完整角色指令prompts/architect.md — architect lane 的角色指令与输出契约src/agents/definitions.ts — architect 角色定义xhigh 推理、只读src/agents/definitions.ts — code-reviewer 角色定义high 推理、只读src/hooks/tests/code-review-skill-contract.test.ts — 评审契约的自动化守卫测试src/autopilot/fsm.ts — Autopilot 子阶段机中的code-review/ultraqasrc/cli/state.ts —omx state命令用法templates/AGENTS.md — 状态与 hook 归属的 SSOT 规则【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
oh-my-codex 双通道独立代码评审：code-review Skill 的合并就绪门控实战指南
oh-my-codex 双通道独立代码评审code-review Skill 的合并就绪门控实战指南【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex导读本文讲解 oh-my-codexOMX中code-reviewSkill 的完整运作机制它以显式 opt-in 的方式为合入前的变更提供双通道独立评审code-reviewer与architect并行、互不替代并通过确定性规则合成最终裁决APPROVE / REQUEST CHANGES / COMMENT把评审不可用与拒绝合入绑定为硬性门禁。读完本文你将掌握如何用$code-review触发合并就绪评审、如何构造双通道 agent 调用、如何解读评审分类法与状态契约以及如何对接 Autopilot / ultraqa / Ralph 等下游工作流。核心入口文档为 skills/code-review/SKILL.md配套的评审角色定义与运行态约束分别在 prompts/code-reviewer.md、prompts/architect.md 与 templates/AGENTS.md 中仓库对这份契约有专门的测试守卫见 src/hooks/tests/code-review-skill-contract.test.ts。何时使用 code-review一份明确的触发边界code-review是一个显式 opt-in的任务卡Task Card不是默认流水线的一部分。其使用时机在 skills/code-review/SKILL.md 中写得很清楚应该用用户明确要求代码评审、质量或安全评估变更在合并前已就绪、需要一次独立评审或一个大型功能需要独立于作者的第二双眼睛。不要用实现、广泛规划或自动清理类任务——这些场景有各自的 Skill如$deep-interview、$plan、$team、$ultragoal负责不应被评审卡抢占。这与仓库的关键词路由实现一致src/hooks/keyword-registry.ts 将code review、$code-review、review code三个触发词以 priority 6 路由到code-reviewSkill在 hook 上下文不可用时AGENTS.md 规定以显式$code-review调用为准。输入与作用域先记录再评审发起评审前卡片要求先锁定输入集Scope被请求评审的文件、commit、PR 或整个 diff。Requirements / specification验收标准、相关的测试 / CI 证据。已有评审产物与已知风险如有。continue语义如果用户说continue应在当前已验证的评审步骤上继续推进而不是重启发现流程。SKILL 建议用如下命令记录作用域基线git status --short git diff --stat git diff -- scope作用域一经记录识别变更文件与评审边界不要静默扩大范围就成为评审的第一个执行约束——这保证了评审结论可以精确回溯到被审对象。执行模型双通道并行禁绝自我评审评审执行的核心是两个独立 lane 并行运行、互不替代识别变更文件与评审边界。并行启动code-reviewer与architect两个 agent两者都在干净上下文clean context中、携带显式 scope 与产物运行。如果任一 lane 无法启动或未返回证据必须报告independent review unavailable不得用当前/作者 lane 顶替也不得批准或标记评审为合并就绪。尊重用户当前的模型与 reasoning/effort 选择不要在评审 lane 调用中传递model或reasoning_effort覆盖参数。SKILL 给出的原生调用模板如下两段task(...)并行task( agent_typecode-reviewer, promptCODE 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_typearchitect, promptARCHITECTURE / DEVILS-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] )注意模板刻意不携带model或reasoning_effort这正是 src/hooks/tests/code-review-skill-contract.test.ts 用doesNotMatch断言守卫的契约防止评审 lane 悄悄覆盖用户的选择。两个 lane 的角色定义在 agent 目录中两个角色都有显式定义src/agents/definitions.ts 与 #L170-L179角色检查面姿态 / 工具默认推理力度code-reviewer规格符合性、安全、质量、性能、最佳实践、可维护性frontier-orchestrator只读higharchitect边界/接口、隐藏耦合、长期权衡、魔鬼代言人反方论证frontier-orchestrator只读xhighprompts/code-reviewer.md 进一步定义了该 lane 的两阶段检查法Stage 1 — Spec Compliance确认每个需求都被覆盖、预期问题被解决、没有添加未经请求的行为。根因守卫root-cause guard拒绝那些吞掉失败、压制诊断、引入宽泛替代路径或绕过主契约的 fallback/workaround要求最小根因修复、显式失败行为与回归证据。Stage 2 — Code Quality检查正确性、安全、性能、可维护性与最佳实践并在可行时对每个变更文件运行诊断重点排查硬编码密钥、注入、XSS、不安全默认值、静默错误处理等模式。每条发现必须给出 CRITICAL/HIGH/MEDIUM/LOW 定级与具体file:line说明影响与根因再给出可落地的修复建议事实与建议必须区分。prompts/architect.md 则约束该 lane不评审没打开过的代码重要论断必须引用文件与行号范围先分离根因与症状、证据与不确定性在双通道评审中必须显式输出CLEAR/WATCH/BLOCK架构状态涉及共识评审时还要给出反题antithesis、权衡张力与综合synthesis。评审分类法统一的分级语言两个 lane 的产出用同一套分级语言汇总code-reviewer检查Security、Code Quality、Performance、Best Practices、Maintainability五个维度。每条发现按CRITICAL安全或数据丢失阻断项、HIGHbug/重大坏味道、MEDIUM重要改进、LOW风格/建议定级。architect输出架构状态CLEAR无问题、WATCH不阻断但有顾虑、BLOCK合并阻断项。每条发现必须包含file:line、问题描述、风险与具体修复方案并区分事实与建议。这套定级语言与 prompts/code-reviewer.md 的输出契约一一对应CRITICAL: X (must fix)/HIGH: Y (should fix)/MEDIUM: Z (consider fixing)/LOW: W (optional)保证多 lane 评审结果可以机械合并。状态 / HUD 阶段契约评审在哪运行code-review对运行时状态有明确归属约束避免与其它工作流互相污染独立运行$code-review依赖 hook 持有的skill-active-state.jsonskill:code-review、phase:planning不要自建code-review-state.json——这与 AGENTS.md 的hook 拥有正常 skill 激活与工作流状态持久化skills 不得复制或改写 hook 持有的状态一致。Autopilot 内运行保持mode:autopilot激活current_phase:code-review/ skill-activephase:code-review不要激活对等的兄弟工作流。评审通过在进入ultraqa前将产物持久化到 Autopilot 的handoff_artifacts.code_review评审未通过持久化发现结果并按需走rework或ralplan。Autopilot 阶段机把code-review与ultraqa列为合法的子阶段src/autopilot/fsm.ts且完成门控测试明确要求从 implementation 到 code-review 的转换以及进入 ultraqa 前的 code-review 证据src/autopilot/tests/completion-gate-advisory.test.ts。在附加 tmux 的 OMX CLI 运行时可用以下命令写入状态omx state write --input {mode:autopilot,active:true,current_phase:code-review} --jsonomx state命令支持read|write|clear|list-active|get-status子命令完整用法见 src/cli/state.ts。最终综合与门禁确定性的合并裁决架构状态契约Architectural Status Contract最终裁决必须同时合并两个独立 lane 的证据任一 lane 缺失或委托失败都属于阻断性不可用状态而不是批准的降级回退。合并规则是确定性的若架构状态为BLOCK→ 最终建议REQUEST CHANGES。否则若code-reviewer建议为REQUEST CHANGES→ 最终建议REQUEST CHANGES。否则若架构状态为WATCH→ 最终建议COMMENT。否则最终建议跟随code-reviewerlane。批准条件非常严格APPROVE 仅在code-reviewer返回 APPROVE、架构状态为 CLEAR、且两个独立 lane 都返回了证据时才能给出REQUEST CHANGES适用于出现阻断项、未解决的高/严重发现或 lane 不可用COMMENT用于记录非阻断性发现。这套映射在 src/hooks/tests/code-review-skill-contract.test.ts 中被逐条断言包括BLOCK → REQUEST CHANGESWATCH → COMMENT以及APPROVE 的双 lane 证据前提。不可用即不可批无自我评审回退禁止自我评审回退如果code-reviewer或architect路径缺失、不可用、被跳过或失败必须阻止批准直到存在独立 lane 证据。Ralph 例外在显式 Ralph 路径上发现结果可以触发自动修复跟进而无需再次征求权限但普通code-review本身是只读的不承诺自动修复。最终报告必须让架构阻断项不可能被漏看。证据 / 输出契约可被下游消费的评审报告评审结束必须返回一份紧凑的报告SKILL 提供了可直接套用的模板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模板中的计数与裁决为示例值需替换为真实观察结果报告还应包含 scope、lane 证据/产物引用、未解决风险与验证缺口。示例中的Total Issues: 0与分级计数之和相等这一自洽性同样被契约测试校验src/hooks/tests/code-review-skill-contract.test.ts。退出条件何时可以停当 scoped diff 拥有了两个独立 lane 结果与确定性的最终建议时评审结束只有在满足批准条件时才报告APPROVE否则留下有界的REQUEST CHANGES、COMMENT或评审不可用结果没有所需证据绝不宣称合并就绪。与周边工作流的衔接Autopilotcode-review是deep-interview → ralplan → ultragoal主链之外被显式挂载的评审阶段通过omx state write与handoff_artifacts.code_review与ultraqa交接见上文状态 / HUD 阶段契约。Ralph显式 Ralph 路径下评审发现可触发自动修复跟进普通code-review保持只读不会悄悄改动代码。团队模式AGENTS.md 将代码评审列为适合显式团队编排的多 lane 工作之一templates/AGENTS.md但在code-review卡内双 lane 委托必须走原生task(agent_type...)不携带model/reasoning_effort覆盖。小结把评审变成可验证的门禁oh-my-codex 的code-reviewSkill 用一个简单而强约束的模型解决了 AI 评审最大的隐患——自我背书两条独立 lane 必须都给出证据缺失即不可批裁决由确定性规则合成不依赖主观判断状态归属明确hook 持有不与兄弟工作流互踩报告模板结构化可被ultraqa、rework、ralplan等下游机械消费。对任何把合并前独立评审当作硬要求的团队这套契约都值得直接借鉴。参考路径速查skills/code-review/SKILL.md — 评审任务卡本体本文主体prompts/code-reviewer.md — code-reviewer lane 的完整角色指令prompts/architect.md — architect lane 的角色指令与输出契约src/agents/definitions.ts — architect 角色定义xhigh 推理、只读src/agents/definitions.ts — code-reviewer 角色定义high 推理、只读src/hooks/tests/code-review-skill-contract.test.ts — 评审契约的自动化守卫测试src/autopilot/fsm.ts — Autopilot 子阶段机中的code-review/ultraqasrc/cli/state.ts —omx state命令用法templates/AGENTS.md — 状态与 hook 归属的 SSOT 规则【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
