# Kill Slop

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-icodecraft-anti-slop-kill-slop`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [iCodeCraft](https://agentstack.voostack.com/s/icodecraft)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [iCodeCraft](https://github.com/iCodeCraft)
- **Source:** https://github.com/iCodeCraft/anti-slop/tree/main/skills/kill-slop

## Install

```sh
agentstack add skill-icodecraft-anti-slop-kill-slop
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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](https://github.com/iCodeCraft)
- **Source:** [iCodeCraft/anti-slop](https://github.com/iCodeCraft/anti-slop)
- **License:** MIT

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-icodecraft-anti-slop-kill-slop
- Seller: https://agentstack.voostack.com/s/icodecraft
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.