Find Slop

find-slop

Find places in the codebase that read like they were written without context — duplication, premature abstractions, defensive cruft, reinvented wheels, dead code, performance antipatterns. The smell test is: would a senior engineer who knows this codebase have written it this way? If the answer is "no," that's slop worth surfacing.

This skill DISCOVERS and REPORTS. It does NOT apply fixes. The output is a terse curated report. A separate skill (or a follow-up Claude session) is expected to act on it.

Invocation

• /find-slop — default: auto-discover ~5 candidate areas across the whole repo.
• /find-slop <hint> — focus discovery on a path, package, or feature name. Examples: /find-slop investments, /find-slop packages/frontend, /find-slop src/auth.
• /find-slop --candidates N — adjust the candidate count (default 5). Combinable with a hint: /find-slop investments --candidates 3.

Parse args yourself from the user's invocation. If unclear, ask the user once and proceed.

Honesty rule (override everything else)

Do NOT pad to hit a count. At any stage:

• If discovery finds 2 areas worth investigating, propose 2. Not 5.
• If discovery finds nothing meaningful, say so and end the skill. Don't fabricate areas.
• If an investigator returns "no significant findings," report that as-is.
• If all investigators return clean, the final report can simply be "no significant findings in <areas>" — that is a successful run.

A clean report from a clean codebase is a win. Filling reports with weak findings trains the user to ignore them.

Workflow

Phase 1 — Read project conventions

Before discovery, read whichever of these exist (use Glob to confirm, then Read):

• CLAUDE.md at the repo root, and any nested ones obviously relevant
• package.json (or pyproject.toml / go.mod / Cargo.toml) — what deps are available
• README.md (high-level domain)
• AGENTS.md / CONTRIBUTING.md if present

You're capturing the project's idioms so you can pass them to investigators and prevent false positives. Do not deep-read everything — top-level only.

Phase 2 — Discover candidate areas

Spawn one Explore subagent (model: sonnet) with a prompt like:

Map the repo to identify ~N candidate areas likely to contain "AI slop" — duplication, over-engineering, defensive cruft, dead code, perf antipatterns. Signals to weight:

• Parallel folders / near-identical filenames (duplication risk)
• High file count or large files (over-engineering risk)
• Many try/catch blocks, broad catch clauses, repeated ?? '' patterns (defensive risk)
• Util/helper folders with many small one-off functions (reinvented-wheels risk)
• Areas with sparse imports from elsewhere (potential dead code)
• Recently churned areas per git log (potential rush job)

If the user passed a hint, scope to that. Skip node_modules/, dist/, build/, .next/, generated, vendor.

Return at most N candidate areas with for each: a name, path(s), a one-line hypothesis of likely slop type, and a one-line why-it-stands-out. Return fewer than N if signals don't justify N. Compact output only.

Once Explore returns, synthesize the candidate list. Apply the hint filter if not already applied. Drop candidates whose hypothesis you don't buy.

If you end up with zero candidates, tell the user honestly and end the skill.

Checkpoint 1 — User picks areas

Use AskUserQuestion with multiSelect: true to present candidates.

• Each option's label = candidate name. description = the one-line hypothesis + path.
• If candidate count is ≥4, you can only show 4 in a single AskUserQuestion (max 4 options). When there are more candidates than 4, list them all in a brief markdown summary first, then ask via AskUserQuestion for the top 4 plus an "Other" / "Specify subset" implicit option (the user can answer with a custom list).

If user selects nothing, end the skill politely.

Phase 3 — Parallel investigation

For each selected area, spawn the slop-investigator subagent.

Spawn all investigators in a single message with multiple Agent tool calls so they run in parallel.

Each Agent call:

• subagent_type: "slop-investigator"
• model: omit (let the agent definition's opus apply)
• description: short, e.g. "Investigate slop in <area>"
• prompt: a self-contained brief with:
  • Area name and exact path(s) / glob(s)
  • Hypothesis from discovery
  • Paths to conventions files you found in Phase 1
  • Slop categories in scope (default: all)
  • A reminder to output strictly in the format defined in the investigator's own instructions

Wait for all investigators to return.

Phase 4 — Aggregate and present

Combine the investigator reports into a single Markdown document, grouped by area. Preserve the investigators' format verbatim — do not paraphrase or expand findings.

Renumber findings globally across the whole report so every finding has a unique reference. Walk the aggregated document top-to-bottom and rewrite each **Finding #N** label so the sequence runs #1, #2, #3, … across areas (not restarting per area). Individual investigators numbered locally; you renumber globally. Example: if Area A returned #1, #2 and Area B returned #1, #2, #3, the final report shows Area A #1, #2 and Area B #3, #4, #5.

Show the consolidated, globally-numbered report to the user in chat.

Checkpoint 2 — User curates findings

After showing the consolidated report, ask the user which findings they want to keep in the final report. This is the "would actually act on" filter — not the "is this true" filter.

Tell the user they can reference findings by number, e.g.:

• keep #1 #4 #5 — final report contains only those.
• drop #2 #6 — final report contains everything except those.
• all — keep all findings.
• none — drop everything, end with an empty report.

Parse the user's reply and filter accordingly. After filtering, renumber again so the surviving findings are #1, #2, #3, … with no gaps.

If there are no findings to curate (everything came back clean), skip this step.

If the user wants all findings kept, skip filtering (numbers already sequential).