kill-slop

Kill Slop

强制产出最小、可合并的 diff。优先选择能完整解决所述任务的最小改动。

硬性规则

• 除非任务明确需要，或适用下文的可导航性拆分，否则绝不创建文件
• 除非用户要求，或现有代码已经需要，否则绝不添加依赖
• 绝不“顺手”重构无关代码
• 绝不添加只是复述代码已表达内容的注释
• 绝不为单次使用引入抽象（包装器、辅助函数、工厂、“utils”）
• 绝不让范围超出用户的请求
• 绝不凭空编造 TODO、桩代码或“以后再用”的脚手架
• 除非用户明确要求，否则绝不在工作区根目录之外搜索、列出或读取
• 绝不浏览同级项目、home、Desktop 或过往聊天来寻找“模式”或灵感
• 绝不凭空编造 Clean Architecture / SOLID 目录树（domain/、application/、infrastructure/、usecases/……），除非仓库已经使用该布局
• 必须先匹配现有项目模式，再发明新模式
• 必须优先编辑现有文件，而非新增文件
• 必须删除自己引入的死代码；不要留下未使用的 import / 变量

用户意图优先

默认最小化。如果用户明确要求更多结构，遵从该请求。

明确要求的示例（照他们说的做）：

• “使用 Clean Architecture / 六边形 / 按功能分文件夹”
• “搭建完整的项目布局”
• “添加依赖 X” / “配置 Prisma / NextAuth / …”
• “抽取一个共享抽象” / “添加一个 utils 模块”
• “编写测试” / “添加注释解释这里”

不要以 kill-slop 之名推翻明确的要求。极简主义适用于他们没有要求更重形态的时候。如果要求含糊，优先极简，并说明你跳过了什么。

文件形态（可导航性）

目标：便于人类和 Agent 浏览——但没有架构表演。

默认： 就近放置。编辑已经负责该关注点的文件 / 文件夹。

仅当以下条件全部成立时才拆分：

1. 当下有痛点——该文件已经难以浏览（大致参考：≳300–400 行，或明显混杂了无关关注点），且你的改动会让它更糟
2. 单一单元——你在抽取一个内聚的片段（一个组件、一个路由处理器、一个纯辅助函数），且有清晰的命名
3. 贴合本地——新文件遵循附近已有的模式（同一文件夹 / 命名）。如果没有模式，仍要就近放在调用方旁边——不要发明新层

如果只有 (2) 成立（“我可以抽出来”），不要拆分。

拆分时：

• 必须把新文件放在相关代码旁边（同一目录）
• 必须修正 import；不要留下“图方便”的死 re-export
• 必须把 diff 限制在本任务内——不要做全仓库重组
• 绝不为 SOLID、整洁性或“未来功能”而拆分
• 绝不为单个函数创建 utils/ / helpers/ / common/ / lib/，除非该文件夹已是仓库惯例
• 如果不确定：不要拆分——在总结中说明

全新项目：优先在一个根目录下保持扁平（src/ 就够了），直到出现真正的可导航性痛点。

Diff 预算

写代码之前，先决定：

1. 目标——一句话：对用户而言有什么变化
2. 改动清单——能实现目标的最少文件
3. 非目标——你不会做什么

如果一个小任务的改动清单超过约 5 个文件，停下来缩小计划。

如果工作区为空或没有既有模式，就在仓库内实现最小的合理方案。不要离开工作区去寻找示例。

完成前先测量

从正在编辑的项目（cwd = 该仓库）运行捆绑的只读检查器（绝不修改工作树）：

bash <path-to-this-skill>/scripts/check-diff.sh

可选：--max-files 5（默认）、--base HEAD。

• STATUS: OK — 在软性文件预算内；仍需应用下面的自检
• STATUS: OVER_BUDGET — 结束前先缩减（编辑现有文件，去掉顺手牵羊的改动）
• STATUS: SKIP — 无 git / 无 base；用同样的约 5 个文件规则手动统计文件数

如果用户明确要求大型脚手架或多个文件，遵从该要求（见用户意图优先）；不要因为 OVER_BUDGET 而忽视它们。

风格

• 优先选择平淡、可读的代码，而非炫技
• 处理任务所需的真实错误路径；跳过臆测性的路径
• 名称应说明意图；如果你需要注释，那就重命名
• 测试：仅当仓库已测试该领域，或用户要求时才添加

自检（完成前）

回答以下问题。若有任何一项不通过，在结束前修复：

• 每一处改动的行都服务于既定目标
• 没有本可内联到现有文件中的新文件
• 任何新文件的存在仅为了可导航性（或明确需要）——而非架构cosplay
• 新文件位于相关代码旁边，并符合仓库布局
• 没有新增依赖
• 没有顺手牵羊的重命名/移动/重构
• 没有显而易见的注释（// import x、// return result）
• 没有工作区外的读取或“灵感”钓鱼
• Diff 是资深工程师会不假思索地合并的内容，而不会问“这东西为什么在这？”
• 用户对架构 / 依赖 / 测试 / 布局的明确要求得到了遵从（而非被“消灭”掉）
• 运行了 scripts/check-diff.sh（或手动统计文件数），并且如果用户没有要求大型脚手架，处理了 OVER_BUDGET

输出

总结时，说明你改了什么，以及你刻意没有改什么。如果你拆分了一个文件，用一句话说明为什么（可导航性）。如果用户要求了更重的形态，说明你遵从了该要求。