用途
SIFT Codebase Audit 用于对整个代码库执行结构性简化审计。SIFT 指 Structural Inspection for Technical Simplification。它关注六类目标：数据结构与模式；状态表示与非法状态预防；控制流与重复分支；算法、扫描、转换与查找策略；生命周期、并发与异步状态；模块边界、权责与归属。
该技能是只审计、不实施的练习。执行者担任协调者角色：建立完整覆盖、在可行时委派有界审查、独立验证每个候选、对审计再做审计，并返回按优先级排序的报告。
不适用场景
单个文件、模块或 diff 的审查不需要 SIFT，应使用普通聚焦式代码评审。SIFT 只提出建议、从不实施；如果用户还希望应用修复，应先完成并交付审计，再把实施视为本技能之外的独立后续工作。
不可协商的操作契约
保持仓库不变：不编辑、创建、删除、重命名或重新格式化仓库文件；不实施建议；不提交、推送、暂存、储藏、检出、重置或改动分支；不在仓库内写草稿文件，使用内部笔记或仓库外的临时路径，完成后删除临时文件。唯一例外是“最终输出”中定义的报告工件，且只在捕获最终完整性对比之后写入。
不执行会变更或可能变更的工作流：不运行测试、构建、格式化、自动修复型 linter、代码生成器、迁移、包管理器、依赖安装器或开发服务器；避免可能在仓库中产生缓存、锁文件、生成输出或元数据的命令。允许只读检查命令：文件列表、搜索、cat、sed、head、tail、git status、git diff、git log、git show、git ls-files 及等价读取操作。
以仓库证据为权威：检查实现、公共接口、主要调用点、现有测试、模式和相关文档；不要主要依据通用最佳实践或外部来源来论证发现；为每个被接受的发现引用确切文件路径与行范围。
偏好实质性简化而非抽象翻新：不强行引入抽象，当本地代码已足够清晰时优先保留朴素本地代码；不要仅因风格一致性、假设性可扩展性、微小的行数减少、命名偏好，或把现有分支移入新类型而建议改动；不要只是转移复杂度。
限定发现范围：每个子系统最多返回两个有实质价值的简化机会；如果没有明确通过实质性门槛，记录显式跳过。
没有覆盖就不得声称完成：持续到每个可识别子系统都已审查且最终审计已验证；若执行限制导致无法完成，标注审计为 INCOMPLETE，并列出每个未审查或验证不充分的行，绝不暗示完整覆盖。
初始化审计
在审查代码之前：确定仓库根与用户请求范围，当未说明更窄范围时默认当前仓库与整个应用；记录基线，包括仓库根、可用时的当前修订与分支、Git 仓库下完整的 git status --porcelain=v1 --untracked-files=all，若无版本控制则记录没有基线指纹并把完整性检查报告为不可验证；阅读本地操作指南如 CLAUDE.md、AGENTS.md、CONTRIBUTING、架构说明与顶层 README；记录用户显式排除项与显然的非源码类别，如 vendored 依赖、二进制资产、生成工件、快照与构建输出，不静默排除，而是给出显式跳过决定或指明应改为审计的权威来源；维护唯一规范覆盖账本与唯一规范发现集合，不允许并行工作者各自保留独立权威清单。
阶段一：建立覆盖契约
检查仓库并盘点每个可识别子系统，盘点即覆盖契约。为每个子系统给出：稳定 ID 与描述性名称；精确且不重叠的归属边界；关键实现文件或目录；相关公共接口、主要调用点、模式与测试；对审查有意义的依赖或相邻子系统边界；状态（queued、in-review、recommend 或 skip）；适用时给出显式跳过原因。
在有实质相关性时纳入：前端界面与客户端状态；后端服务与领域逻辑；共享库与基础设施；持久化模型、模式、迁移与生成契约归属；平台桥接、适配器、队列、worker 与外部集成边界；生命周期与并发基础设施；测试框架、fixture、构建工具与开发者工具。
盘点规则：不要用宽泛的兜底行作为覆盖证据；当不同权威、模式、生命周期或调用图需要独立审查时拆分该行；边界要足够精确，使两名工作者不可能把同一实现作为各自主要范围来审计；对生成代码，识别并审计生成器、模式或事实来源所有者，除非包含手工维护行为，否则将生成输出记为跳过；对 vendored 代码，除非仓库拥有需要审查的修改或行为集成，否则记为跳过。
阶段二：运行有界子系统审查
当环境提供代理生成或任务分派工具时，使用全新只读子代理；否则顺序执行同样审查。
审查标准：references/worker-brief.md 是每个子系统审查的唯一权威，包含所需检查目标、简化清单、实质性门槛与返回格式。开始阶段二前先阅读，并以相同方式应用于委派或自行顺序审查。不要在其他地方重述其规则；需要调整时直接修改该简报。
委派协议：工作者不共享你的上下文，因此向每个工作者提供 references/worker-brief.md 全文以及子系统专属任务，而不是摘要或文件路径。环境提供时优先使用只读子代理类型；简报中的约束是指令而非强制。为每个工作者分配恰好一个子系统 ID，给出精确归属边界与显式排除。绝不让两个活跃工作者拥有重叠的主要归属。并发限制在你能主动协调的通道数量内。分批打开审查工作，每批使用一次合并等待或收集步骤。不要仅因工作者较慢而打断有产出的工作者。收集结果后关闭已完成的工作者。
阶段三：验证与综合
协调者必须在接受每个候选前，针对当前仓库独立验证。对每个候选：重新打开被引用的实现与行范围；追踪代表性生产者、消费者与调用点；检查测试或其他预期语义证据；确认所提表示是消除复杂度而非转移复杂度；确认实施范围可信且有界；检查是否与每个已接受或待定发现重叠；将发现归属到一个权威子系统；当证据不支持原始主张时拒绝、收窄、合并或降低置信度。把跳过记录为已完成覆盖。保留一份简洁审计日志，记录被拒绝、合并、取代与降级的发现，使最终综合可解释。使用 references/finding-schema.md 中的确切发现字段。
阶段四：对审计再做审计
完成前，运行全新的独立检查，覆盖：覆盖度（遗漏子系统、隐藏归属边界、未审查模式或宽泛兜底行）；重复与权威（重叠发现、重复抽象与归错子系统的建议）；实质性（薄弱发现、风格清理、推测性抽象或复杂度转移）；模式完整性（缺失证据、范围、风险、迁移、验证或置信度字段）；依赖感知排序（影响、置信度、工作量、影响半径、前置条件与顺序）。环境允许时使用全新子代理或干净审查上下文。若覆盖检查发现真实遗漏，添加显式子系统行并审计，不得通过放宽先前完成的行来掩盖遗漏。
完成标准
仅当以下条件满足时审计完成：每个可识别子系统都已审查；每个子系统都有已接受建议或显式跳过；每个已接受发现都有完整证据、范围、风险、迁移、验证与置信度字段；重复、薄弱发现与抽象翻新已移除；优先级与依赖内部一致；最终仓库状态与记录基线一致，或明确报告完整性检查不可验证（因为没有基线）。最后，捕获与基线相同的仓库状态命令并比较结果。若状态改变，不得声称仓库保持不变；指出差异并将完整性检查标注为失败。没有基线指纹时，报告完整性检查为不可验证。
最终输出
阅读 references/report-template.md 并按该结构生成唯一规范报告。将完整报告写入文件，并在对话回复中总结执行摘要、排序表与工件路径。该文件是审计唯一的仓库写入，且只在最终仓库完整性对比捕获之后发生：当用户指定报告路径时，精确写入该路径；当用户拒绝文件时，直接在对话中交付完整报告且不写任何文件；当环境无法写文件时，直接在对话中交付完整报告；否则写入仓库根下的 docs/sift-audit-<YYYY-MM-DD>.md，docs/ 不存在时创建。在报告完整性部分记录工件路径，作为审计后唯一写入。
报告必须：显著标注 COMPLETE 或 INCOMPLETE；总结最高价值的结构性主题；展示完整子系统覆盖账本，包含显式跳过；每个子系统提供不超过两条已接受发现；为每个发现包含确切证据；按具体影响、置信度、实施工作量、影响半径与前置条件对建议排序；识别最小可信的首个实施切片；在能实质性解释结果时包含被拒绝、合并或取代的候选；包含最终仓库完整性对比。