kill-slop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Kill Slop

杜绝杂乱代码

Force a minimal, merge-ready diff. Prefer the smallest change that fully solves the stated task.

强制生成最小化、可直接合并的代码差异。优先采用能完全解决指定任务的最小改动。

Hard rules

硬性规则

NEVER create a file unless the task clearly needs it or a navigability split below applies
NEVER add a dependency unless the user asked or existing code already requires it
NEVER refactor unrelated code "while you're here"
NEVER add comments that restate what the code already says
NEVER introduce abstractions (wrappers, helpers, factories, "utils") for a single use
NEVER expand scope beyond the user's request
NEVER invent TODOs, stubs, or "for later" scaffolding
NEVER search, list, or read outside the workspace root unless the user explicitly asks
NEVER browse sibling projects, home, Desktop, or prior chats for “patterns” or inspiration
NEVER invent Clean Architecture / SOLID folder trees (
```
domain/
```
,
```
application/
```
,
```
infrastructure/
```
,
```
usecases/
```
, …) unless the repo already uses that layout
MUST match existing project patterns before inventing new ones
MUST prefer editing an existing file over adding a new one
MUST delete dead code you introduce; do not leave unused imports/vars

除非任务明确需要，或是符合下文提到的可导航性拆分规则，否则绝对不要创建新文件
除非用户要求，或是现有代码已依赖该库，否则绝对不要添加新依赖
绝对不要“顺手重构”无关代码
绝对不要添加重复代码含义的冗余注释
绝对不要为单一使用场景引入抽象（包装器、助手、工厂、“工具类”）
绝对不要超出用户请求的范围
绝对不要凭空创建TODO、存根或“后续优化”的脚手架
除非用户明确要求，否则绝对不要搜索、列出或读取工作区根目录以外的内容
绝对不要浏览兄弟项目、主目录、桌面或历史聊天记录来寻找“模式”或灵感
除非仓库已采用该布局，否则绝对不要凭空创建Clean Architecture / SOLID风格的目录结构（
```
domain/
```
、
```
application/
```
、
```
infrastructure/
```
、
```
usecases/
```
等）
必须遵循现有项目模式，再考虑创建新模式
优先编辑现有文件，而非添加新文件
必须删除自己引入的无用代码；不要留下未使用的导入/变量

User intent wins

用户意图优先

Default to minimal. If the user explicitly asks for more structure, obey that request.

Examples of explicit asks (do what they asked):

"use Clean Architecture / hexagonal / feature folders"
"scaffold the full project layout"
"add dependency X" / "set up Prisma / NextAuth / …"
"extract a shared abstraction" / "add a utils module"
"write tests" / "add comments explaining this"

Do not override an explicit ask in the name of kill-slop. Minimalism applies when they did not request the heavier shape. If the ask is ambiguous, prefer minimal and say what you skipped.

默认采用最小化改动。如果用户明确要求更结构化的方案，请遵循该请求。

明确请求示例（按要求执行）：

“使用Clean Architecture / 六边形架构 / 功能文件夹”
“搭建完整项目布局”
“添加依赖X” / “配置Prisma / NextAuth / …”
“提取共享抽象” / “添加工具模块”
“编写测试” / “添加注释解释这段代码”

不要以“杜绝杂乱代码”为由违背明确请求。仅当用户未要求复杂结构时，才采用最小化原则。若请求模糊，优先采用最小化改动，并说明跳过的内容。

File shape (navigability)

文件结构（可导航性）

Goal: easy to walk for humans and agents — without architecture theater.

Default: colocate. Edit the file/folder that already owns this concern.

Split only when ALL of these hold:

Pain now — the file is already hard to navigate (rough guide: ≳300–400 lines, or clearly mixed unrelated concerns), and your change would make it worse
One unit — you’re extracting a single cohesive piece (one component, one route handler, one pure helper) with a clear name
Local fit — the new file follows an existing nearby pattern (same folder / naming). If there is no pattern, still colocate beside the caller — do not invent a new layer

If only (2) is true (“I could extract this”), do not split.

When you split:

MUST put the new file next to related code (same directory)
MUST fix imports; no dead re-exports “for convenience”
MUST keep the diff on this task — no repo-wide re-org
NEVER split for SOLID, cleanliness, or “future features”
NEVER create
```
utils/
```
/
```
helpers/
```
/
```
common/
```
/
```
lib/
```
for a single function unless that folder is already the repo convention
If unsure: don’t split — say so in the summary

Greenfield: prefer flat under one root (

src/

is enough) until real navigability pain appears.

目标：便于人类和Agent浏览——无需架构形式主义。

默认规则： 就近放置。编辑已有相关职责的文件/文件夹。

仅当以下所有条件满足时才拆分文件：

当前存在痛点——文件已难以导航（大致标准：约300-400行，或明显混合无关职责），且你的改动会让情况更糟
单一内聚单元——你要提取的是一个单一内聚的模块（一个组件、一个路由处理器、一个纯工具函数），且有明确命名
符合本地模式——新文件遵循附近已有的模式（相同目录/命名规则）。若没有现有模式，仍需放在调用方旁边——不要新建层级

仅满足条件2（“我可以提取这个”）时，不要拆分。

拆分文件时：

必须将新文件放在相关代码旁边（同一目录）
必须修复导入；不要为了“方便”留下无用的重新导出
必须聚焦当前任务的差异——不要进行仓库范围的重组
绝对不要为了SOLID原则、“整洁性”或“未来功能”拆分文件
除非仓库已有此惯例，否则绝对不要为单一函数创建
```
utils/
```
/
```
helpers/
```
/
```
common/
```
/
```
lib/
```
目录
若不确定：不要拆分——在总结中说明原因

新项目：优先采用单根目录的扁平化结构（

src/

足够），直到真正出现导航痛点。

Diff budget

差异预算

Before writing code, decide:

Goal — one sentence: what changes for the user
Touch list — the fewest files that can achieve it
Non-goals — what you will not do

If the touch list grows past ~5 files for a small task, stop and shrink the plan.

If the workspace is empty or has no prior pattern, implement the smallest reasonable solution in-repo. Do not leave the workspace to find examples.

编写代码前，先确定：

目标——一句话说明：为用户带来什么改变
修改列表——实现目标所需的最少文件
非目标——你不会做的事情

若小任务的修改列表超过约5个文件，请停止并缩小计划。

若工作区为空或无现有模式，请在仓库内实现最小合理方案。不要离开工作区寻找示例。

Measure before finishing

完成前检查

From the project being edited (cwd = that repo), run the bundled read-only checker (never modifies the tree):

bash

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

Optional:

--max-files 5

(default),

--base HEAD

```
STATUS: OK
```
— within soft file budget; still apply the self-check below
```
STATUS: OVER_BUDGET
```
— shrink before ending (edit existing files, drop drive-bys)
```
STATUS: SKIP
```
— no git / no base; count files manually with the same ~5-file rule

If the user explicitly asked for a large scaffold or many files, obey that ask (see User intent wins); do not treat OVER_BUDGET as a reason to ignore them.

从正在编辑的项目（当前工作目录=该仓库）运行内置的只读检查器（不会修改目录）：

bash

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

可选参数：

--max-files 5

（默认值）、

--base HEAD

。

```
STATUS: OK
```
——在软文件预算内；仍需执行下方的自我检查
```
STATUS: OVER_BUDGET
```
——完成前缩小改动范围（编辑现有文件，移除顺手的冗余改动）
```
STATUS: SKIP
```
——无git/无基准；手动按约5个文件的规则计数

若用户明确要求大型脚手架或多文件改动，请遵循该请求（见“用户意图优先”）；不要以OVER_BUDGET为由忽略用户请求。

Style

风格

Prefer boring, readable code over cleverness
Handle real error paths the task needs; skip speculative ones
Names should explain intent; if you need a comment, rename instead
Tests: only when the repo already tests this area, or the user asks

优先采用乏味、易读的代码，而非巧妙的写法
处理任务所需的真实错误路径；跳过推测性的错误处理
命名应体现意图；若需要注释，优先重命名
测试：仅当仓库已对该区域编写测试，或用户要求时才添加

Self-check (before finishing)

自我检查（完成前）

Answer these. If any fails, fix before ending:

Every changed line serves the stated goal
No new files that could be inlined into an existing one
Any new file exists only for navigability (or explicit need) — not architecture cosplay
New files sit beside related code and match repo layout
No new deps
No drive-by renames/moves/refactors
No obvious comments (
```
// import x
```
,
```
// return result
```
)
No out-of-workspace reads or “inspiration” fishing
Diff is something a senior would merge without asking "why is this here?"
Explicit user asks for architecture / deps / tests / layout were honored (not “killed” away)
Ran
```
scripts/check-diff.sh
```
(or manual file count) and addressed OVER_BUDGET if the user did not ask for a large scaffold

回答以下问题。若有任何一项不满足，请在完成前修复：

每一处改动都服务于指定目标
没有可以内联到现有文件中的新文件
所有新文件仅因导航性（或明确需求）而创建——而非架构形式主义
新文件放在相关代码旁边，且符合仓库布局
无新增依赖
无顺手的重命名/移动/重构
无冗余注释（如
```
// import x
```
、
```
// return result
```
）
无工作区外的读取或“灵感”搜索
代码差异是资深开发者无需询问“为什么要改这个”就会合并的内容
用户对架构/依赖/测试/布局的明确请求已被遵循（未被“杜绝”）
已运行
```
scripts/check-diff.sh
```
（或手动计数文件），且在用户未要求大型脚手架的情况下处理了OVER_BUDGET问题

Output

输出

When summarizing, say what you changed and what you deliberately did not change. If you split a file, say why (navigability), in one sentence. If the user asked for a heavier shape, say that you followed that ask.

总结时，说明你修改的内容，以及故意未修改的内容。若拆分了文件，请用一句话说明原因（导航性需求）。若用户要求复杂结构，请说明你已遵循该请求。