用途
该技能是一套审查流程，用于在文稿或代码已经写成后，检查其中是否出现 output_discipline（位于 ai-prompts/CLAUDE.md）所禁止的 AI 输出痕迹。据资料，那个文件规定要避免什么，本技能说明如何在已经写成的散文或代码中找到具体实例；使用前应先阅读该规范。判断词语要看上下文，下列模式只是候选识别，不是禁用词清单。
散文痕迹检查
先做词法扫描，再逐条结合上下文判断后再报告。扫描应针对目标文件而不是 diff，因为逐步引入的痕迹不会出现在任何单个 diff 中。零命中并不能证明文本有内容：即使删掉所有列出的词，文本仍可能什么也没说，所以判断环节照常进行。
资料列出的模式包括：公告式或结尾复述（如 in this (section|article|document)、^overall,、in summary、it is worth noting）；空洞强调或自我夸赞（robust、comprehensive、seamless、successfully、significantly）；无信息模糊限定（essentially、basically、arguably）；公式化排比（not only .* but also、it('s| is) not just .*, it('s| is)）；谄媚开场（^(you('re| are) absolutely right、great question、excellent point）；英文散文中的 em dash（U+2014，附 perl 命令）；装饰性表情符号（附 grep -P 命令，U+2605 被有意排除，因为该语料将星号用作决策注释块标记，钩子脚本也把叉号和勾号用作功能性 stderr 状态标记）。
其中两类需要额外判断：排比模式无法区分公式化对偶与真正对比两件事的句子；强调类词大多命中并非缺陷。资料给出三个桶，只有最后一桶才算发现：一是规则引用自身主题；二是术语专门用法，如统计学中的 robust standard errors 或报告退出状态旁的 exited successfully，都不代替证据；三是用词断言质量却无支撑，如 Successfully implemented a robust solution 或 provides a comprehensive methodology。区分标准是删除该词是否丢失信息：第二桶会丢失，第三桶不会。
还有两类痕迹难以用模式捕捉：判断“任何不包含读者原本不知道的事实的句子”需要人工判断，逐句问删掉后读者失去什么，什么也没失去就删；这正是 cold-read 的新审阅者对耐久散文回答的问题，应派发而非自己目测。日文散文有独立的词表（technical-writing 中的 LLM-tell avoidance），应按该技能的列表用该语言检索，本文不重新推导或复述。
误报陷阱
定义禁用词规则的语料必须引用该词才能陈述规则，因此词法扫描会把规则自身的定义标出来。要区分被禁措辞的示例与交付物中的散文或代码：引号和代码围栏本身并不豁免其内容。阅读周围段落，判断句子是在用该词断言主张，还是把该词作为示例点名；只有前者是发现。资料举例：technical-writing/SKILL.md 引用 em dash（U+2014）及两个相关日文破折号变体作为禁止其在日文散文中出现的规则的字面主题，对该文件原样 grep 该字符会返回非零计数，但并不指明任何缺陷。
代码产物痕迹
output_discipline 点名的形状包括：
- 防护不可达条件的防御分支：如调用方已确立不变式后的空值检查、类型守卫或 catch-and-rethrow。可达性是调用点属性而非分支文本，一般无法词法检测，但有两种形状可查：重复紧邻外层作用域已做检查的守卫，以及 catch ($E) { throw $E; }（或语言等价物）这种不如让异常传播的做法。可用 ast-grep CLI 结构化匹配 catch-and-rethrow，因为间距和变量名因调用点而异。
- 为不存在的第二用例引入的抽象：只有一个实现的接口、策略或插件点，或在每个调用点都取相同值的配置参数。检测靠引用搜索而非 grep：用可用的符号工具找实现和调用方。只有一个实现是审查候选，不是缺陷证明；提出内联前应先检查是否存在现成契约、依赖边界或测试缝，不要虚构第二个实现来证明。
- 复述签名的文档注释：完全可从函数名、参数名和签名类型恢复、且不添加签名无法展示的 WHY（约束、不变式、面向调用方的坑）的文档注释。把文档注释与签名并排阅读，指出它增加的信息；仅重复标识符本身不构成冗余。可用 ast-grep CLI 定位某类节点的所有文档注释做批量审查，复述还是解释的判断仍需人工。
- 以脚手架代替实际工作：函数体是桩、硬编码返回值伪装成计算结果，或遗留“未实现”异常而调用方已不再期待它。先用 aitools search 搜直接标记：TODO|FIXME|XXX|not implemented|NotImplementedError|unimplemented!|panic!("todo"。标记会漏计，因为桩可返回看似合理的常量而无标记；对函数体明显短于其名称和调用点所暗示应做之事的函数应交叉检查。
- 仪式化占位步骤：一连串步骤或日志语句叙述工作却不做任何事（如“Step 1: Analyze the problem”后无分析，或“Starting process...”日志后紧跟下一步而无中间工作）。这是阅读启发式而非 grep：对每一步指出其可观察结果，包括决定、批准或报告；报告既不增加结果也不是必要前置条件的步骤。
- 洗白类型的类型转换：逃逸型转换（any、interface{}、Object、裸指针）或先宽后窄的配对断言未被任何检查确立的事。用 ast-grep CLI 列出改动代码中的转换节点，指出使每个转换成立的不变式；无法指出时，用检查或正确类型的来源替换。
- 无契约的兼容路径：垫片、别名、重试或回退分支需要有已发布的依赖它的消费者和移除计划。搜索消费者；空搜索结果就是证据，应随发现一起报告。
- 无视所在文件的风格：命名、导入顺序、错误处理习惯或控制流与同一文件相邻函数不同，而不是与通用风格指南不同。
单次使用的辅助函数和直通中间层属于上面的抽象条目，其删除证明见 Removing dead code。
审查前清理 diff
与整文件散文扫描不同，代码清理可能只覆盖当前改动：作者拥有该改动，全仓库清扫会把无关编辑混入审查。对 diff 每个 hunk 对照合并基检查上述形状；只修复不会改变行为的部分，其余报告给作者。此项应在代码审查之前运行，绝不能代替代码审查。
报告发现
每条发现都是 file:line 加一行具体改动，绝不是“clean this up”或“make this more concise”这类未指明缺陷、让作者无从下手的指示。要说明当前文本或代码做什么、缺失或错误的事实或行为是什么，以及具体替换。
相关技能
- cold-read：当痕迹是“不包含读者原本不知道的事实”需要读者判断而非模式匹配时，或审计后需要重读整份文档时派发。
- technical-writing：本文不复述的日文 LLM-tell 词表和散文质量规则。
- ast-grep（CLI）：对上述文本模式会漏配或过配的代码产物形状做结构化匹配。
限制
资料未提供安装方式、收费、平台支持范围等信息，暂未提供。资料中的命令和模式应原样使用，不做改写。