ce-code-review

使用分层角色代理、置信门控结果和合并/重复数据删除管道进行结构化代码审查。

ce-code-review 是深度代码审查技能。它分析差异（PR、分支或当前更改），为实际涉及的内容选择正确的审阅者角色，并行分派它们，然后将其发现合并并删除重复项到单个报告中。每个发现都带有严重性 (P0-P3)、表示后续形状的自动修复类（gated_auto、manual、advisory）以及所有者。在交互模式下，审查会应用安全的、经过验证的修复程序，并在工作树干净时提交它们（它从不推送）；在 mode:agent 中，它报告并调用者应用。

复合工程构思链是/ce-ideate → /ce-brainstorm → /ce-plan → /ce-work。 ce-code-review 是 /ce-work 的 第 2 层升级 目标 - 针对敏感表面、大差异或显式深度审查请求自动调用，但也可以在您想要对当前分支或特定 PR 进行结构化审查时直接调用。

TL;DR

＃＃ 问题

通才代码审查会以可预见的方式提示崩溃：

• 表面层面的发现 - “考虑添加测试”，但没有指定要测试的内容
• 差异的错误发现 - 有关仅文档更改的安全反馈、有关拼写错误修复的性能反馈
• 无严重性校准 — 每个发现都被视为关键，淹没了实际的 P0
• 无置信度校准 — 推测性“可能是错误”与已验证的缺陷相同
• 一次通过一个模型的推理 - 单个审阅者对最后一次训练最严重的内容有偏见
• 没有结构化的后续行动 - 结果最终出现在聊天中；无记录、无修复队列、无残留处理
• 在错误结帐时改变操作 — 在另一个代理并行运行测试时对共享结帐运行审查会产生未定义的结果

解决方案

ce-code-review 将审查作为具有显式门的结构化管道来运行：

• 差异感知角色选择 — 4 个始终在线的审阅者 + 2 个 CE 始终在线的代理，以及针对差异实际涉及的内容选择的横切和特定于堆栈的角色
• 平行人物调度 - 每个评论者都专注于其镜头；结果并行返回
• 置信门控合成 — 结果合并、重复数据删除、促进跨角色协议以及按自动修复类别进行路由
• 严重程度 (P0-P3) + 自动修复类别 — 将紧急性与操作所有权分开
• 两种模式 - 交互（默认；应用安全验证修复本身）和 mode:agent（JSON 机器切换；仅报告，调用者应用）
• 调用者拥有的应用 + 剩余工作门 — 在 mode:agent 中，调用者（例如 /ce-work）应用修复并运行剩余工作门（接受/归档票据/继续/停止）；在交互模式下，审查将其应用的修复提交到干净的树上，并且它从不推送
• 快速审查短路 — 遵循线束原生 /review 进行光通行证；多代理仅在有保证时运行

是什么让它如此新颖

1. 差异感知角色选择

一个小的配置更改会触发 6 个审阅者（4 个始终在线 + 2 个 CE 始终在线）。带有迁移的 Rails 身份验证功能可能会触发 10。该技能决定哪些角色适合差异：

• 始终开启（每次审核） — ce-correctness-reviewer、ce-testing-reviewer、ce-maintainability-reviewer、ce-project-standards-reviewer、ce-agent-native-reviewer、ce-learnings-researcher
• 横切条件 - 安全性、性能、API 合约、数据迁移、可靠性、对抗性、先前评论 - 仅当差异涉及其关注点时才选择每个条件
• 特定于堆栈的条件 — Julik 前端竞赛、Swift/iOS — 仅当匹配的运行时域被触及时。结构质量（复杂性删除、千行回归、意大利面条）存在于始终在线的可维护性角色中。
• CE 条件（迁移） — ce-deployment-verification-agent 用于有风险的迁移差异；架构漂移和迁移安全由 data-migration 角色处理

角色选择是代理判断，而不是关键字匹配。指令散文文件（Markdown 技能、JSON 模式）是产品代码，但会跳过以运行时为中心的审阅者（对抗性、竞赛）——它们不适用。

2. 严重性 (P0-P3) 和自动修复类别是正交的

严重性答案紧急（P0=严重损坏，P3=用户自行决定）。自动修复类是关于后续形状的信号（不申请权限）：

• gated_auto → 存在具体的 suggested_fix — 一个明确的申请候选者
• manual → 需要设计输入或移交的可操作工作
• advisory → 仅报告输出（经验教训、推出说明、残余风险）

综合拥有最终路线。 Persona 提供的路由元数据是输入，而不是最后的决定 - 分歧默认为更保守的路由。某个发现是否真正得到应用是一个判断调用（交互式审查的第 5c 阶段，或 mode:agent 中的调用者），而不是类的函数。

3. 两种模式——人视模式和机器切换模式

该技能永远不会切换分支：PR/分支参数选择审查范围（无需签出即可进行差异），而不是允许变异。交互式应用就地编辑当前结帐；要根据另一个参考检查当前结帐，请传递 base:<ref>。

4. 快速回顾短路

当用户请求“快速”、“快速”或“轻量”审查时，技能将遵循线束本机代码审查（例如，克劳德代码中的 /review ），而不是调度多代理管道。这尊重意图——有时正确的工具是较轻的工具。编程调用者 (mode:agent) 绕过短路并始终运行完整的管道。

5. 综合管道 — 合并、重复数据删除、升级、路由

所有派出的角色返回后，合成：

• Validates each finding against the schema
• Anchors to the actual diff (drops findings about lines that don't exist or aren't in scope)
• Deduplicates across personas (same issue surfaced by multiple reviewers)
• Promotes confidence on cross-persona agreement (two reviewers spotting the same issue raises priority)
• Resolves contradictions (different personas disagree about what to do)
• Routes by tier — applied fixes, gated/manual, FYI

输出是一份具有经过校准的严重性、证据引用和明确所有权的报告，而不是每个审阅者的原始输出的简单列表。

综合还构建了主题分类组（grouping:auto，默认值）：当发现的问题涉及不同的问题时，相关的问题会被分组在一个简短的主题下——共享的根本原因、重叠的修复路径、解决多个发现的一个设计决策——因此包含 20 个发现的审查看起来像是少数几个主题，而不是 20 个独立的项目。组是一个分类镜头，而不是重组：结果保持其稳定的 # 和严重性表，组引用它们 (#2, #3)，并且 mode:agent JSON 在 triage_groups 字段中携带相同的组 - 每个发现的镜头，而不是应用队列，因此调用者仅在将每个组过滤到可操作的子集。通过 grouping:off 获得平面报告，或通过 grouping:always 对小评论进行分组。

6. 计划发现需求验证

当 diff 有关联计划 (docs/plans/*.md) 时，技能会发现它（通过 plan: 参数、PR 正文链接或从分支名称自动发现）并读取其需求部分 + 实现单元。然后综合验证差异是否确实满足这些要求——捕获代码看起来不错但与计划所说的它应该做的不匹配的情况。

7. 剩余工作门

When autofix mode runs and the in-skill fixer can't resolve everything, the residual work doesn't just disappear into chat. The Residual Actionable Work summary lists each unresolved finding with stable numbering, severity, file:line, title, and autofix class. Callers (e.g., /ce-work Phase 3.4) read this summary and present user options: apply now, file tickets, accept with durable sink, or stop.

8. 受保护的文物

复合工程管道工件（docs/brainstorms/*、docs/plans/*.md、docs/solutions/*.md）受到保护——审阅者删除或忽略它们的发现在综合过程中被丢弃。这些是管道所依赖的决策工件；审阅者不应该对它们进行垃圾收集。

简单示例

您可以通过包含数据库迁移的 Rails 身份验证更改在功能分支上调用 /ce-code-review。

该技能检测到您位于功能分支（尚未有 PR），从 origin/HEAD（或存在开放 PR 时的 PR 元数据）解析基础，并计算差异。第 2 阶段读取提交消息并写入 2-3 行意图摘要。第 2b 阶段从分支名称中自动发现 docs/plans/ 中的计划并读取其要求（R1-R8、U1-U6）。

第 3 阶段选择审核者：6 个始终在线的审核者，以及安全性（涉及身份验证）、可靠性（令牌清理的后台作业）、数据迁移（存在迁移文件）以及迁移有风险时的部署验证代理。一共七八个审稿人，并行派遣。

全部返回后，综合将 23 个原始发现合并为 14 个不同的发现。其中三个是干净、可逆的修复（拼写错误、重命名、死代码删除），审查适用并验证自身（阶段 5c → 应用部分）。六个是用于身份验证表面的 gated_auto — 审查适用的具体候选人，将它们显着标记为绿色但无法验证（身份验证）以供您审查。其中两个是 manual（部署进行/不进行清单项目）。其中三个是advisory（仅供参考）。每项发现都有固定的证据和稳定的数字。

您浏览 6 个封闭的调查结果，应用 4 个，推迟 1 个通过跟踪器进行后续跟踪，并拒绝 1 个并指出伤害。最终验证运行；报告已保存。

何时去实现它

在以下情况下使用 ce-code-review：

• 您即将为敏感或大型工作（身份验证、付款、迁移、公共 API）打开 PR
• 您的安全带缺少内置 /review，但您仍然需要进行真正的审查
• 您需要结构化处理剩余工作，而不仅仅是聊天中倾倒的结果
• 您明确想要更深入的、多角色的通行证（例如，“彻底审查此内容”）
• 另一项技能正在升级（/ce-work 阶段 3.3 第 2 层，/ce-optimize 阶段 4.3）

在以下情况下跳过 ce-code-review：

• 您想要快速简单地检查一下 - 您的安全带的内置 /review 是正确的；短路处理这个
• 更改是微不足道的（拼写错误、格式设置、依赖项冲突） - 第 1 级审核就足够了
• 您想要修复发现的错误，而不是审查代码 → 使用 /ce-debug

用作工作流程的一部分

ce-code-review 从多个技能中调用作为深度审查路径：

• /ce-work 阶段 3.3 — 对于敏感表面、≥400 行 + 漫反射、≥1,000 行或明确的彻底审查请求，升级至 ce-code-review mode:agent； ce-work 然后应用研究结果
• /ce-work 阶段 3.4 剩余工作门 — 读取返回的剩余可操作工作摘要 ce-code-review 并呈现用户选项
• /ce-optimize Phase 4.3 — 在合并之前针对累积优化分支差异运行
• /ce-doc-review — 文档（需求、计划）而非代码的同级技能

第 1 层（harness-native /review）处理大多数情况； ce-code-review 是第 2 层升级。

使用独立版

该技能可以直接在任何起始状态下发挥作用：

• 当前分支 — /ce-code-review
• 特定 PR — /ce-code-review 1234 或 /ce-code-review <PR URL>
• 特定分支 — /ce-code-review feat/notification-mute
• 使用基本参考 — /ce-code-review base:abc1234 或 base:origin/main （跳过范围检测；针对该参考进行审查）
• 有计划 — /ce-code-review plan:docs/plans/.../plan.md 用于明确的需求验证

并发使用注意事项： mode:agent 仅用于报告并且永远不会发生变化，因此在同一结帐时与浏览器测试一起使用是安全的。交互模式可能会对工作树应用修复，因此请避免针对其他代理正在积极使用的签出运行它。

＃＃ 参考

冲突的模式标志（或冲突的分组标志）会因错误而停止执行。将 base: 与 PR/分支目标组合也会出错 — 通过其中之一。

＃＃ 常问问题

为什么不直接使用线束的内置 /review？ 当它是正确的工具时就使用它——快速审查短路明确地遵循它。 ce-code-review 适用于您需要差异感知角色选择、具有校准严重性的结构化结果、自动修复路由和剩余工作处理的情况。这是较重的工具；当工作需要时就去做。

它如何决定派遣哪些角色？ 代理对实际差异的判断——而不是关键字匹配。每次审核都会运行 4 个始终在线 + 2 个 CE 始终在线角色。当涉及到他们的关注点时，就会添加横切和特定于堆栈的角色（例如，如果身份验证文件发生更改，则安全；存在迁移或架构转储文件时，添加 ce-data-migration-reviewer ）。指令散文文件会跳过以运行时为中心的审阅者（对抗性的、竞赛的）。

交互式（默认）和 mode:agent 之间有什么区别？ 交互式是面向人的模式：一个降价报告，审查应用安全的、经过验证的修复本身（应用部分），并在你的树干净时提交它们（如果树脏了，则将它们留给你的提交）；它从不推动。 mode:agent 是机器切换：一个 JSON 对象，仅报告 — 审查不会改变任何内容，并且调用者（例如 /ce-work）根据自己的条件应用结果。 mode:headless 是 mode:agent 的已弃用别名。

什么是剩余工作门？ 调用者拥有的步骤（不是审核技能的一部分）：在 mode:agent 中，调用者（通常是 /ce-work）应用它可以应用的内容，然后呈现它不应用的结果并询问用户：立即应用、提交票证、使用持久接收器接受或停止。 “接受”需要真正持久的记录（PR 描述中的已知残留，或 docs/residual-review-findings/<sha>.md）——调查结果不能消失在聊天中。

为什么它从不切换结帐？ 该技能永远不会运行 git checkout/switch — 通过 PR/分支选择审查范围，而不是允许改变树（它在不检查的情况下比较远程/本地引用）。交互模式可以“应用”当前结帐的修复（可逆编辑），但它永远不会切换分支。要根据不同的引用查看当前结帐，请传递 base:<ref>。

它可以与浏览器测试同时运行吗？ mode:agent 仅用于报告并且永远不会改变，因此它与并发测试一起是安全的。交互模式可能会对工作树应用修复，因此请避免针对其他代理正在积极使用的签出运行它。

它支持非软件工作吗？ 不——该技能与 git、代码审查人员和 PR 环境紧密结合。对于文档（要求、计划），请使用 /ce-doc-review 代替。

另请参阅

• ce-work — 主要上游调用者；在第 3.3 阶段升级到 ce-code-review
• ce-doc-review — 文档（需求、计划）而非代码的同级技能
• ce-debug — 当根本原因调查很重要时，用于修复审查期间发现的错误
• ce-resolve-pr-feedback — 在 PR 开放后处理传入的审阅者评论
• ce-simplify-code — 在审核之前由 ce-work 调用；补充，而不是替代