deslop

Deslop

清除分支修改的代码中的 AI 垃圾，同时保持行为不变。每次提交前都使用它；当收到 /deslop、“清理一下垃圾代码”、“清理差异”或“剔除垃圾代码”指令时也使用。它只清理代码。unslop 技能负责处理文案，no-comments 技能负责审查注释。

范围

使用调用者提供的文件或差异。否则，将当前内容与此分支的基准分支进行比较，其中包括工作树和未跟踪文件（git status --short）：如果有打开的拉取请求，则使用其基准分支（gh pr view <branch> -R <host>/<owner>/<repo> --json baseRefName，其中 <host>/<owner>/<repo> 来自 origin 的 fetch URL）；否则使用创建此分支的分支（git branch -vv 或 git reflog show <branch>）；再否则使用 main。对于堆叠分支，与 main 比较会把父分支的提交也包含在差异中。只在此分支新增或修改的代码块内编辑。阅读判断所需的内容：调用方、类型、现有辅助函数以及文件的其余部分。注意到其他位置的垃圾代码时，将其记入报告，但不要改动。

每次提交前

每次提交或 amend 前都必须完成此检查，包括仅测试、失败测试、修复轮次和 WIP 提交。

1. 在将要提交的 Agent 中加载此技能。每轮检查前都要完整阅读 SKILL.md，包括所有规则和 Report 部分。可以一次阅读，也可以分段阅读，但必须覆盖整个文件。如果返回内容被截断，继续获取缺失内容后再继续。目录条目、成功执行的读取命令、部分读取或其他 Agent 的摘要，都不能证明已完整阅读。
2. 确定拟提交内容、其父提交和涉及的路径。检查每个代码块，包括暂存内容和新文件。对于 amend，既要检查现有提交的代码块，也要检查暂存更改。对该范围应用下方的 Process。对分支末端进行检查不能覆盖之前的提交。没有新增注释，并不意味着代码可免于遵守其他规则。
3. 提交前保留证据。记录完整读取所用工具的引用、父提交，以及能够标识已审查内容的暂存树 ID 或留存的补丁。按规则 ID 和文件名列出删改项。如无改动，说明适用规则为何要求不作删改，并给出具体路径及相关调用方、类型或边界约束。若范围仅涉及文案，可记录 no code 及已检查的路径。仅仅加载技能或声称“已清理”并不足够。
4. 记录清理后的验证命令及其实际结果，包括已撤销的不安全删改和未解决的问题。保留故意提交失败测试时预期的失败情况，并展示清理后该失败仍然存在。如果钩子或后续编辑改动了拟提交内容，必须审查变更后的内容，并在重试前更新证据。压缩上下文后，重新加载完整技能，并在提交前重新确认已审查的范围。
5. 只有检查及其证据齐备后才能提交。提交成功后，将该提交的父提交和树与已审查快照进行比较，然后记录其 SHA。如果两者不一致，报告遗漏的提交前检查并暂停验收。审查变更内容，并通过新一轮检查执行任何获准的修正。保留此不一致记录。之后的审查无法证明之前做过提交前检查。向调用方为每个提交提供一条证据引用。如果所需的读取、审查或验证仍未完成，暂停提交并报告缺口。

流程

1. 逐块阅读 diff，并说明每块的任务。没有用途的块属于规则 17。
2. 按顺序应用以下规则。尽量少改。先删除，再重写。
3. 遇到需要新结构的改动时就停下，例如新增类型、辅助函数或状态模型。将其标记给重构手册。Deslop 绝不会为了消除冗余而新增抽象。
4. 在真实产物上证明行为未变。运行 diff 涉及的测试和类型检查。若必须修改测试才能通过，则说明行为已变。撤销该改动。
5. 将剩余内容交给协作者处理。规则 1 至 3 无法定论的注释，在报告前需要进行注释审查。对这些注释使用 no-comments 技能。如果审查导致代码变更，则重新执行第 4 步。然后对名称、消息和保留的注释使用 unslop 技能。
6. 按照以下格式报告。

规则

规则编号是稳定 ID，其他技能会引用。删除规则后，编号会留空。每条规则都会说明目标、识别特征和修正方法。

注释

1. 叙述性注释。 注释复述其下方的代码行，或指出某个阶段（// increment count、// Phase 1: add cards）。删除。
2. 注释掉的代码和删除标记。 由注释符号屏蔽的代码，或 // removed 注释。删除。
3. 保留清单。 许可证头。由无法重塑的外部依赖、平台、供应商或协议强制要求的非显而易见行为。prettier-ignore。定义公共 API 契约的文档注释。用于解释代码无法表达的约束的问题或 RFC 链接。保留的注释仍属于文本，因此第 5 步会将其交给 unslop 技能处理。

守卫

4. 针对不可能状态的守卫。 类型或边界条件不会使值为空的空值检查、对已收窄类型的 instanceof 检查、对元组的长度检查、对每个调用方都会传入参数的默认值。删除。信任类型。
5. 对可信路径的防御性包装。 对内部调用进行 try/catch 或提供回退处理，而该调用不可能以处理程序预期的方式失败；或吞掉错误的处理程序。移除包装，或让错误抛出。掩盖不明确不变量的静默回退属于规则 4，报告中应指出该不变量。
6. 重复验证。 边界已解析的数据再次解析或验证。删除内部的重复检查。

系统边界上的守卫（用户输入、网络、文件、环境、外部 API）应保留。测试要求保留的守卫也应保留，测试就是证明。

死路径

7. 兼容性垫片。 与新路径并存的旧路径、没有调用方却为“调用方”保留的别名或重新导出，以及本分支已替换代码的弃用通知。没有调用方的垫片应删除。如果所有调用方都在本分支的 diff 块中，则在同一改动中迁移调用方并删除垫片。若有调用方位于这些 diff 块之外，则保留垫片，并在报告中说明，因为迁移该调用方会改动 Scope 之外的内容。
8. 未使用的参数、导出和标志。 没有任何调用方传入的参数、没有任何位置导入的导出、只有一个值的选项、只有一个可达分支的标志、标记为临时的分支。删除。
9. 调试残留。 调试日志和打印语句，无论是否带标签；一次性原型；变体切换器。删除。

即使在仓库中没有调用方，软件包公共接口上的符号（入口点导出、文档化 API）也应保留，因为调用方位于仓库之外。只有当任务将其从公共 API 中移除时才删除。否则，在“未改动”项下列出。

类型

10. 检查器消音手段。 仅为通过类型检查而使用的 any 或 unknown 类型转换、as 断言或抑制注释。修正类型或删除类型转换。

结构

11. 只有一个调用者的包装器。 只有一个调用者、仅传递参数的函数、辅助函数或适配器。将其内联。
12. 推测性通用化。 在任务中只有一种实现、没有第二处用途的抽象、参数、钩子或扩展点。将其内联回去，直到出现实际需求。
13. 重复实现辅助函数。 代码实现了代码库中已有辅助函数的功能。调用现有函数。
14. 嵌套早返回可以扁平化。 如果守卫子句的主体就是函数剩余部分，就提前返回并减少缩进。
15. 略有差异的复制粘贴代码。 差异中有两处形状相同、仅有细微区别的代码。只有当代码库已有名称来表示这种共享形状时才提取。否则，三行相似代码就保持原样。
16. 差异无法修复的结构。 在无关流程中硬加新的条件分支、一次性布尔值或可空模式、针对同一种形状重复编写条件判断。将其标记给 Refactoring playbook 的 principle-model-the-domain。不要在此处修复。

范围

17. 无关编辑。 任务无需触及的代码中发生的格式变动、重命名、导入顺序调整或语法现代化。撤销 git 可以还原的代码块：包括在分支上提交的代码块，以及你在本次会话中编写的代码块。未提交且非你编写的代码块应保留，并在报告中列出，因为撤销它会破坏没有任何提交保存的工作。git diff <base>...HEAD 会显示已提交的代码块，git diff HEAD 会显示未提交的代码块。逐个代码块撤销，绝不要通过还原整个文件来撤销，这样同一文件中的未提交代码块才能保留。撤销已提交的代码块时，手动将相关行改回原样，或仅反向应用从 git diff <base>...HEAD -- <file> 中取出的那个代码块。反向应用整个差异也会撤销该文件中的任务代码，而 git diff <base> -- <file> 也会包含该文件中未提交的代码块。
18. 清理过程中的行为变更。 在标记为清理的代码块中改变代码行为。将其拆分出来，并在报告中列出。
19. 风格与文件不一致。 使用周边文件中没有采用的模式。与文件保持一致。

报告

用一到三句话，然后列出：

• 按规则编号统计的数量，以及涉及的文件。
• 根据规则 17 撤销的代码块，以及保留的未提交无关代码块。
• 移交给 Refactoring playbook 的标记（步骤 3，规则 16）。
• 步骤 5 中评论交给 no-comments 技能的内容，以及该技能对每条评论的处理方式。
• “未触及”清单：范围之外的杂项。
• 测试和类型检查命令及其结果。

CREDITS.md 列出了此技能参考的来源，以及沿用的句子。