用途
文档与代码之间的关联一旦无人强制维护，就会立刻产生偏差。Drift Auditor 正是为弥合这一缺口而设计：它读取项目所承诺的内容（PRD.md、ADR），以及代码实际做的事情（真实代码库），并报告两者不一致的每一处。其目的不是追责，而是让团队逐项决定：是代码需要修改，还是文档需要更新。
该技能从不编辑代码或文档，只负责报告，由人来决定。
主要能力
Drift Auditor 将每个对比点分类为以下类型：
- OK：匹配。不单独报告，仅在摘要中计数。
- 幽灵功能（Feature fantasma）：PRD 的“范围”中承诺但未实现，或实现方式与描述有实质差异。
- 遗漏规则（Regla omitida）：PRD 中声明的业务规则、边界情况或约束，代码中没有对应处理。
- 被违反的架构决策（Decisión de arquitectura violada）：代码与 ADR 的决策相矛盾（例如 ADR 规定所有写入都经过队列，而某代码路径直接写入）。
- 未文档化的功能（Feature no documentada）：代码中存在且可用，但 PRD 或任何 ADR 都未覆盖。这也是偏差，只是方向相反——代码变了，文档没跟上。
- 与承诺相关的技术债（Deuda técnica ligada a una promesa）：承诺的功能或 ADR 支持的决策通过显式变通、TODO/FIXME 或可能破坏保证的 hack 实现。与上述类别分开报告；它还不是被打破的承诺，而是脆弱的承诺。
每项发现都需要具体证据——PRD/ADR 的引用加上文件:行号（或明确的缺失）。没有具体检查的“代码可能没有覆盖这一点”不构成发现。
使用方式
必需输入
- PRD.md——必需。没有它就没有“承诺”一侧可供对比。
- adrs/*.md（或等效的 ADR 集合）——如果项目记录了架构决策则必需。如果项目确实没有，需明确说明并跳过架构偏差检查，而不是凭空捏造决策来检查。
- TECH-DESIGN.md（如存在）——对组件边界和数据模型有用，非必需。
- 项目的实际源代码——必需，这是对比的另一半。
如果缺少 PRD.md，应停止并先索取，再继续——对着空无审计偏差只会产生一份关于代码本身的报告，那是另一个技能。
工作流程
-
构建承诺模型：完整阅读 PRD.md 和每个 ADR。提取具体、可检查的声明：范围（必须存在）和不范围（不得作为已发布功能存在）中的每一项；PRD 正文中每条明确的业务规则、边界情况或约束；每个 ADR 的决策及其后果中隐含的持续约束。不要推断文档并未实际做出的承诺。
-
构建实际模型：探索真实代码库以确定其实际行为。优先使用环境已有的代码智能工具进行结构化探索，再回退到广泛的 grep/glob。对第 1 步提取的每一项，找到确认或反驳它的具体证据（文件+行号，或明确的缺失）。
-
分类每个对比点：按上述六类对每个承诺与现实的对比进行分类。
-
分诊——不要自行解决偏差：对每项偏差发现，诚实陈述两个选项，让人选择：
- CORREGIR CÓDIGO：文档中的承诺/决策仍是意图；代码应与之对齐。
- ACTUALIZAR PRD/ADR：代码当前行为是实际且合理的意图（有意的转向、已改变的约束）；文档才是过时的。 该技能无权决定哪个正确——那是产品/架构的决策。绝不要编辑 PRD.md 或任何 ADR 来“修复”发现的偏差。
-
撰写报告：在项目根目录写入 DRIFT.md，遵循 assets/drift-report-template.md 中的结构。
输出
DRIFT.md——项目中其他内容不变。这是一次仅报告的操作。
质量门
返回前静默检查：每项发现都引用了具体的 PRD/ADR 声明和具体代码（或其明确缺失）；主动查找了“未文档化的功能”发现，而不仅是承诺→代码方向；每项发现都陈述了两个分诊选项；审计期间未修改任何 PRD 或 ADR 文件；如果 PRD.md 没有可对照的 ADR，报告应明确说明，而不是静默跳过架构部分。
适用场景
适用于需要验证文档与代码一致性的项目，尤其是已有 PRD 和 ADR 记录、希望发现文档漂移、幽灵功能、遗漏规则或未文档化功能的团队。
限制
该技能只生成报告，不修改代码或文档。缺少 PRD.md 时无法进行对比。如果项目没有 ADR，架构偏差检查会被跳过。分诊决策需由人工完成，技能本身不做判断。