代码审查纪律
大多数 AI 代码审查员的失败不在于「审得不够细」，而在于越权：Agent 把只要求审查的代码顺手改掉、把陈年 bug 算到你的新变更头上、编造臆想风险来显得很认真、或者悄悄修一个跨模块的问题——而那个问题本该由人来决策。 Myrm 的 code-review 技能让审查员像一个自律的资深工程师：- 只审查，不修改。 应用修复是独立的步骤，由你或专门的修复管道完成。
- 每个问题都有归因。 每条 finding 都标注
Introduced-in-change（本次变更引入）/Pre-existing（之前就存在）/Unknown（无法判定），以git diff/git blame为依据，绝不猜测。 - 臆想风险被拒绝。 Finding 必须落在真实 diff 上；不现实的边缘场景和假设性失败会被剔除，而不是凑数。
- 跨范围阻塞项升级给你。 真正跨越模块边界或所有权线的风险会被上报并标记为 Needs user decision（需要用户决策），而不是被悄悄并入本次变更。
四层纪律
多智能体流水线闭环
当审查以 code-review-pipeline 形式运行（分析员 → 安全审查员 → 逻辑审查员 → 验证员）时，闭环在最后一公里显式落地：- 验证员角色确认修复并运行回归测试，但不会自动修复标记为
Needs user decision的项——这些项交还给你。 - 流水线的成功标准要求 out-of-scope blockers escalated to user decision（跨范围阻塞项必须升级为用户决策），让真正的风险不会消失在 Agent 的修复清单里。
需求追溯
除了发现问题，技能还把任务/PR 描述里的每个需求映射为验证结果：
如果没有明确需求，它会陈述推断出的目的并确认代码是否达成——这样审查回答的是「这次变更兑现承诺了吗」，而不只是「代码干不干净」。
如何使用
零配置。 该技能以预置技能形式出现在 设置 → 技能 中。- 直接审查变更： 启用
code-review技能，让 Agent 审查 PR、文件或模块。 - 运行完整审查流水线： 使用
code-review-pipeline技能（看板 → 流水线 → 代码审查），并行展开安全 + 逻辑审查，最后进行修复验证与回归测试。
验证与契约测试
技能的契约由契约测试守护（断言每条纪律条款都在、frontmatter 版本合法），并由集成测试覆盖完整流水线（实例化 → 任务 DAG → 验证员任务描述），关键路径无 mock。审查流水线解析与Needs user decision 闭环均端到端覆盖。