四维审计清单

要解决的问题

一次改动真正需要检查的点，往往散落在四处：改了什么、逻辑是否正确、测试覆盖是否到位、手动怎么验。只看 diff 的总结报告，很容易漏掉其中一维；人工 review 时，注意力也常被大段改动带走。这个技能把 AI 当作质量保障工程师：输入 Git diff 或快照，输出一份可逐项勾选的四维 Markdown 清单，而不是只有结论的报告。

核心能力与工作流

• 读取快照 §三 的结构化结论（L2=I10、L3=audit-checklist），校验通过才执行；越界则回退 tri-intent 重路由。
• 版本检查是第零步硬门：先校验版本，非最新自动 skillhub upgrade，失败则标注降级状态继续。
• 识别三种 Git 输入模式：暂存区（git diff --cached）、工作区（git diff + git status）、commit id（git diff <base>..HEAD），模式选错命令即失真，禁止混用。
• 门①：向用户复述审计范围（输入模式、diff 统计、受影响文件、四维计划），确认后才开始分析。
• 四维审计逐维展开：改动点、审查点、测试点、测试步骤；每项带复选框和 BLOCKER/MAJOR/MINOR 严重程度标签，与 tri-review 对齐。
• 清单由脚本组装，落盘为 audit-checklist_<timestamp>.md 到用户工作区；门②呈现路径、四维统计与总项数，确认后才算交付。

适用边界与注意点

• 只生成清单，不执行审查。逐项判定 PASS/FAIL 由 tri-review 负责，清单是开发者自检或 tri-review 的输入。
• 独立使用时先检测上游 tri-intent：无快照则提示先走意图识别，绝不按空上下文静默执行；用户拒绝安装则进入降级模式，自构造输入并声明精度下降。
• 四维缺一不可：任一维度缺失即为半成品，不落盘交付；每维至少 5 个检查项。
• 版本门有四态（A/B/C/D）：离线、通道异常或自动升级失败时放行但会标注，仅 BLOCK 才禁止执行。
• diff 解析结果写入 diff.json，.gitignore 命中的敏感路径会脱敏；脚本只用 Python 标准库，无第三方依赖。