--- name: Kill Slop slug: kill-slop category: Quality description: Force AI coding agents to produce minimal, merge-ready diffs by preventing over-abstraction, extra files, unnecessary dependencies, and out-of-workspace exploration. Use when writing or editing code to keep changes clean and focused. github: "https://github.com/iCodeCraft/anti-slop/tree/main/skills/kill-slop" language: Shell stars: 25 forks: 2 install: "npx degit https://github.com/iCodeCraft/anti-slop/tree/main/skills/kill-slop ~/.claude/skills/kill-slop" installs_to: ~/.claude/skills/kill-slop source_path: skills/kill-slop/SKILL.md collection_size: 3 category_size: 1354 collection_url: "https://dirskills.com/collections/iCodeCraft/anti-slop" added: 2026-08-11T07:22:00.661Z last_synced: 2026-08-11T07:22:00.661Z canonical_url: "https://dirskills.com/skills/kill-slop" --- # Kill Slop Force AI coding agents to produce minimal, merge-ready diffs by preventing over-abstraction, extra files, unnecessary dependencies, and out-of-workspace exploration. Use when writing or editing code to keep changes clean and focused. **Install:** ```bash npx degit https://github.com/iCodeCraft/anti-slop/tree/main/skills/kill-slop ~/.claude/skills/kill-slop ``` ## README # 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 ## 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. ## 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:** 1. **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 2. **One unit** — you’re extracting a single cohesive piece (one component, one route handler, one pure helper) with a clear name 3. **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. ## Diff budget Before writing code, decide: 1. **Goal** — one sentence: what changes for the user 2. **Touch list** — the fewest files that can achieve it 3. **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. ### Measure before finishing From the **project being edited** (cwd = that repo), run the bundled read-only checker (never modifies the tree): ```bash bash /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. ## 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 ## 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.