用途
该技能用于对代码进行审查，目标是产出少量、可操作、经过反驳检验的缺陷发现，而不是一份未经排序、无法行动的可疑点清单。它的核心判断是：审查者最容易漏掉的缺陷，很少能在单个文件内看到，而是两个参与者之间的“约定”出现分歧——调用方与被调方、生产者与消费者、写入方与后续读取方、两个本应建立相同状态的分支。逐文件套用检查清单看不到这些，因为两半从不同时出现在视野中。因此，审查的单元是“约定”，而不是文件。
主要能力
技能包含一个共享引擎和三个锚点维度：
- 正确性（核心，默认）：锚定跨边界参与者之间的约定。
- 性能：锚定“工作负载 → 资源需求 → 增长或争用 → 后果”。
- 安全：锚定“来源 → 信任边界 → 汇聚点”，并假设攻击者控制来源。
三个子案例可独立激活，并非互斥。同一根因可能同时带来正确性与安全影响，此时只报告一次并标注两种影响。
共享引擎的流程为：绘制一条流 → 识别一项义务 → 检查每个参与者 → 构造一个违反执行 → 追踪后果 → 尝试反驳 → 报告。
技能特别强调两类需要显式探测的缺陷：
- 权威对账：追踪一个提议值经过验证、规范化、协商或提交后，下游状态是否仍派生自该提议值，而权威方可能返回不同结果。请求值不等于已应用值。
- 身份与关联：追踪操作结果如何找到其来源实体，并确认该键在重叠、重排、移除和复用下是否唯一、稳定且存活足够久。
使用方式
通过指令参数调用，例如：
/pm-ai-shipping:code-review
/pm-ai-shipping:code-review dimensions=correctness scope=changes
/pm-ai-shipping:code-review dimensions=performance,security
/pm-ai-shipping:code-review dimensions=all
这些是指令参数，不是 shell 标志。默认维度为正确性；裸的“review this”或“find bugs”仅指正确性。显式列表精确选择对应子案例；all 选择三个。未知或空选择不会被静默重新解释，而是询问。范围优先使用被明确要求的内容，否则审查工作区变更（若存在），再否则审查整个仓库。调查前需说明所选维度、范围和比较基线。审查变更意味着要跟随依赖超出变更行，并区分变更引入的缺陷与变更仅仅暴露的缺陷。审查与报告分离，仅在明确要求时才应用修复。
适用场景
适用于需要对代码变更或仓库进行结构化审查、希望得到可操作缺陷而非泛泛清单的场景。尤其适合跨边界缺陷（调用方/被调方、生产者/消费者、写入方/读取方）的发现。支持并行：按完整流或相连的约定组扇出，绝不按文件扇出，也绝不每个分类一个代理。协调者构建初始映射并识别共享状态；每个工作者获得一个有界流、其参与者、所选子案例和开放问题；工作者检查约定的两侧，可跟随其列表之外的依赖；返回候选、引用证据、已完成的反驳和未解决的关系。强候选在报告前会经过单独的验证轮。
限制
- 静态审查产出的是代码审查发现，不是已确认的漏洞利用或实测的性能回归。
- 缺失文档是限制，不自动构成发现。
- 通过的测试、不熟悉的代码、可疑的命名、缺失的测试和同类差异都是需要调查的证据，但都不是证明，也都不是反驳。
- 吸收不等于预防：下游恰好掩盖缺陷的机制（通常命中的缓存、通常成功的重试、通常正确的默认值）不是保证，不能据此丢弃发现。
- 没有发现配额；零个受支持的发现是有效结果。
- 报告需说明覆盖范围是已执行的工作，而非勾选框；零发现不等于“未覆盖”，也不应声称代码无缺陷。
- 并行时应在每个工作者上显式指定协调者自己的模型，不使用“inherit”；除非被明确要求，不引入不同模型进行审查或交叉检查。
- 工作者只读、搜索和导航，不得修改代码树；需在提示中说明，并在运行结束时确认代码树未变。
- 性能与安全子案例背后有成熟命令：/security-audit-static 和 /performance-audit-static；当子案例是全部工作时运行命令，当它只是更广泛审查的一个维度时使用参考文件。
- 文档与代码轴应使用 intended-vs-implemented 技能。
报告结构
报告以受支持的发现开头，按影响排序，严重性与证据强度分开。每条发现包含：期望、触发、缺陷、证据（每个参与者的源位置）、影响、反驳、补救、验证。跨边界缺陷需引用两个参与者，不能仅按文件分组。覆盖范围需对每个所选子案例报告：已检查且有受支持发现 · 已检查无受支持发现 · 不适用及原因 · 未检查及原因。还需明确说明哪些部分构建良好。