用途：对代码 diff 做双轴审查。Standards 轴先对照仓库自身规范，再以 desplega:engineering-standards 为基线，判断代码是否构建良好；Spec 轴对照最强的意图声明，判断是否真正做对了事。两轴由独立并行子代理审查，分别列在各自标题下，绝不合并或重排，因此“符合所有规范但实现错误”会显示为 Standards 通过 / Spec 失败。
主要能力与用法：审查发现从不在主会话生成，两轴始终以全新子代理上下文运行，即使 diff 很小或会话“已知”代码。编排者只负责事后汇合：去重、对照代码核实、剔除误报、给出结论。
步骤：1）固定 diff，如 git diff <commit-before-phase>...HEAD、git diff <base>...HEAD（三点取合并基）或 git diff + git diff --staged，并在报告头写明范围。2）按优先级找 spec 来源：计划文件（含 Success Criteria）、来源 issue/ticket/PR 描述、本对话中的用户请求；若均无则用 AskUserQuestion 询问。若被触及系统存在设计文档（thoughts/*/design-docs/<system-slug>.md），它叠加在主要来源之上，其 Invariants 属于 spec 而非风格。3）并行后台派发两个子代理，各自只拿到固定 diff 范围和自己的轴。Standards 代理需含仓库规范（CLAUDE.md/AGENTS.md、lint/style 文档，仓库覆盖基线）与基线测试和坏味道表，并要求按名称和 file:line 引用失败项。Spec 代理需含 spec 原文或路径，检查三类失败：需求缺失或部分实现、无人要求的行为（范围蔓延）、看似实现但实际错误（边界、条件反转、未验证声明），并核实计划的自动检查是否覆盖需求且通过。4）分别汇总，严重度分 Critical/Important/Minor，编排者核实后给出最终结论。5）处理：实现流程中 Critical 阻止阶段关闭，Important 修复或获用户明确延期，Minor 记录；独立审查展示两节并提供修复；Autopilot 中自动修复 Critical 与 Important，记录 Minor，绝不静默丢弃 Critical。
限制：无斜杠命令，需按名称 desplega:code-reviewing 调用或由实现类技能自动触发；子代理结论仅供参考，最终判定不外包。本技能审查代码，desplega:reviewing 审查文档，desplega:verifying 审计计划完整性，三者用途不同。