用途：当自己的工作（分支、修复系列或文档集）完成、即将合并或交接，或用户要求“self-audit”时，执行一次刻意的事后自审。其核心假设是成果中存在缺陷，目标是找出错误，而不是确认正确或总结工作。作者盲点具有系统性，因此在固定位置反复排查能发现写作阶段乃至测试套件遗漏的真实问题。审计干净是有效结果，但在数千行规模的分支上很少见，且必须附带证据：走过的范围、实际执行的检查、仍不确定之处；不得为回避干净结论而编造发现。
范围界定：审计一个明确的工作体，而非“整个仓库”。对分支代码，用 git merge-base <base> HEAD 对比合并基、列出提交并统计行数，在报告中说明范围（如“整个分支，8 个提交 / 约 6.5k 行”），覆盖分支触及的源码、测试、文档、配置与 CI。scripts/audit_scope.py scope --base main 可生成提交、按类型文件与行数统计及范围声明（路径相对本技能目录，仓库根目录下为 skills/self-audit/scripts/audit_scope.py）。非代码工作则枚举产出的文档、配置、图表、计划等并进行审计。动手前先重读规范（RFC、任务描述、工单），第一轴是交付物与规范的一致性，不能凭记忆核对。
扫描：references/passes.md 提供十道依次执行的检查，顺序重要，廉价的结构检查先缩小昂贵验证检查的范围。其中两道最关键：验证诚实性——报告中每条主张都要可追溯到实际运行过的东西，靠阅读得出的结论只是假设；以及先破坏再覆盖——干净的破坏扫描衡量的是想象力而非测试，且会带来已完成错觉。
修复与报告：同一分支上边发现边修复，明显缺陷立即修复并重审；仅保留真正需要用户决策的事项。报告发现而非活动，每条包含位置、问题、为何重要及状态（已修复或未解决），按严重度排序。说明范围与残留：审计了什么、未审什么、仍不信任什么；无发现的审计也以同样方式报告，以便读者区分干净与肤浅。若工作执行了某规范，发现应记录在对应任务日志 logs/<task-id>.md 的带日期发现区（flag-dont-flip）。可归纳的发现提炼为一行规则，存入项目笔记或记忆。相关技能：reading-isnt-proof、fewer-tests-more-proof、flag-dont-flip、less-code-same-behavior。限制：具体安装命令与支持平台暂未提供。