Kill Slop

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

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.

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?"

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: iCodeCraft
• Source: iCodeCraft/anti-slop
• License: MIT

Install and usage instructions live in the source repository linked above.