Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Unslop

ASecurity

Audit a codebase for dead code and AI slop, clear each suspect against the legitimate reason it exists, and remove only what the evidence carries.

3 stars
0 votes
0 copies
0 views
Added 9/24/2026
ai-agentsrustc#railsdockerkubernetesterraformgitapi

Works with

cliapi

Security Analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned 9/29/2026

$npx -y skills add Firzus/agent-skills --skill unslop --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Unslop?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Unslop
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/firzus-unslop/badge)](https://www.skillsdirectory.com/skills/firzus-unslop)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: unslop
description: >-
  Audit a codebase for dead code and AI slop, clear each suspect against the
  legitimate reason it exists, and remove only what the evidence carries.
disable-model-invocation: true
---

# Unslop

Find code that should not exist, **dead code** that no longer runs and
**slop** that runs and earns nothing, then prove each candidate before
touching it. A run proposes a ranked list of candidates in the conversation,
with the evidence attached; removal follows the user's approval, one deletion
per commit.

## Two problems, two epistemics

Keep them apart at every stage. Auditing them in one pass is the error that
produces confident wrong deletions.

| | Dead code | Slop |
| --- | --- | --- |
| Question | Is this **reachable**? | Should this **exist in this form**? |
| Decided by | Reference graphs, call graphs, runtime evidence | Reading the code |
| Core | Decidable, with documented blind spots | No decidable core |
| Terminates in | A removal backed by evidence | A ranked proposal for a human |

**No tool decides deadness.** Each one decides a *decidable approximation* of
it, and the identity of that approximation, never the tool's confidence score,
determines whether removal is safe. Perfect detection reduces to the halting
problem, so every tool is either unsound for deletion or incomplete.

**Authorship is not the defect.** No detector of LLM-written source exists, and
every pattern in this skill is abundantly present in human-written code. Report
the defect and the rule it violates; leave authorship out of the finding.

## Vocabulary

- A **suspect** is a raw tool hit or a read observation. It is not yet a
  finding.
- To **exonerate** a suspect is to find the legitimate mechanism that keeps it
  alive or earns its shape. Every signal has an exoneration list, and clearing
  that list is the whole work of the audit.
- A **candidate** is a suspect whose exonerations were checked and none applied.
  Only candidates reach the proposal.
- The **root set** is the declared entry points reachability is measured from.
  "Unreachable" is a function of the root set, so it is a configuration
  artifact, not a property of the code.
- **Blast radius** is what breaks if the candidate was alive after all, and
  whether that break is **loud** (a failing build) or **silent** (a runtime
  failure on a rare path, months later).

## 1. Scope

Three decisions, made before any tool runs, because each one changes what the
output means.

**Closed world or open world.** In a closed world (application, service, game)
every entry point lives in the repo or its deploy config, and an unreferenced
symbol is a candidate. In an open world (library, SDK, plugin, published
package) the exported surface *is* the product: zero in-repo callers is the
expected state of the entire public API, and a reachability tool measures
nothing but the density of its own examples. A monorepo is open-world per
published package boundary. Establish this first; it changes the answer more
than any tool setting.

**The root set, written down.** Enumerate every entry point before scanning:
`package.json` `bin` and `scripts`, `[project.scripts]`, `[[bin]]`,
Dockerfile `CMD`/`ENTRYPOINT`, CI workflows, Terraform and Kubernetes manifests,
serverless handlers, crontabs, route and task decorators, test discovery roots.
A missing entry does not produce one false positive: it cascades, and every
file it reaches, every export in those files, and every dependency only they
used all report as dead.

**Exclusions and reach.** Generated output and its input schemas, vendored and
third-party trees, and test trees leave the reachability query. Then choose the
reach: a diff-scoped audit has an owner for every finding, while a repo-wide
audit produces hundreds of ownerless ones. Prefer the diff, and weight the rest
toward code that keeps changing.

**Done when** a scope note names the world, lists the root set, and lists the
excluded trees.

## 2. Detect

Read [`signals.md`](signals.md) and collect suspects against it. It carries
the signal table (detection procedure, what a hit proves, the exoneration
list, and the evidence grade) plus what each detector is structurally unable
to see.

Run whatever the repository already has before installing anything: its linter,
its compiler warnings, its analyzers, its coverage. Record the exact command
and configuration next to every hit, because a finding is only ever "unused
within the set I analyzed."

Alongside the tools, read for the shapes no tool encodes: a wrapper that only
forwards, a second implementation of an existing repository utility, a path
left wired after a mid-task change of approach, a test whose assertions touch
only mocks. These are where slop concentrates, and compilers report none of
them.

**Done when** every suspect carries its signal, its detection command, and its
evidence grade.

## 3. Exonerate

The heart of the audit. Read [`false-positives.md`](false-positives.md) and
work each suspect against it: twelve mechanisms that keep statically
unreferenced code alive, each with the grep recipe that finds it and the check
that clears it. Unity and C# have their own section there, because engine
wiring defeats .NET static reachability in ways no analyzer reports.

Two moves carry most of the weight, and both are free:

- Search the symbol as a **bare string literal** across the whole repository,
  including untracked and ignored files, data, config, templates, and
  serialized assets: `git grep --untracked --no-exclude-standard 'Symbol'`.
- Search the **mechanism**, not the symbol: `getattr(`, `importlib`,
  `Class.forName`, `Type.GetType`, `Activator.CreateInstance`, `obj[name]`,
  `.send(`, DI registrations, assembly scans. A name assembled at runtime from a
  prefix and a variable is unresolvable statically, and that ends the enquiry.

Grade what survives. **A** and **B** signals may carry a removal proposal.
**C** signals produce a question for the author. **D** signals, anything
resting on tone or style, are mentioned at most, never acted on.

**Done when** every suspect is either dismissed with the exoneration that
cleared it, or promoted to a candidate carrying: files, signal, what the signal
proves, the exonerations checked, evidence grade, and blast radius with its
loud/silent classification. A candidate that does not name the exonerations it
cleared is not a finding.

## 4. Present

Present the candidates directly in the conversation as a numbered list, in the
user's language and the project's domain vocabulary. Order them by evidence
grade, then by blast radius ascending, so the cheapest and safest work reads
first. Give each candidate a short title and:

- **Files**: the exact locations.
- **Signal**: what fired, with the command that produced it.
- **Proves**: the bounded claim the signal supports.
- **Cleared**: the exonerations checked and why none applied.
- **Blast radius**: what breaks if this was alive, loud or silent.
- **Verdict**: `Remove`, `Consolidate`, `Migrate`, or `Ask`.

Duplication is a `Consolidate` verdict, never a `Remove`: extract the shared
behaviour, redirect every call site, and the originals then become ordinary
unreferenced symbols with established provenance. A superseded implementation
still serving traffic is `Migrate`: an incomplete migration, not a deletion.

End with a **Top recommendation**, then ask the user which numbered candidates
to apply. Work starts only on the candidates the user accepts.

## 5. Remove

For each accepted candidate, read [`deletion.md`](deletion.md) and climb its
verification ladder until the evidence matches the blast radius. Rungs 1 to 4 are
free and offline; run all four every time. Public surface switches the work to
a deprecation cycle, which the audit proposes rather than performs.

When commits are authorized, land each logical deletion as its **own commit**,
with a message recording which searches ran and what they returned. Without
commit authorization, preserve the local changes and verification evidence;
report Git delivery as pending rather than committing or discarding the work.
Delete outright rather than commenting out; preserve a recoverable copy of any
uncommitted content before removal.

Independent candidates with disjoint files may run as parallel sub-agents, each
given the candidate's evidence, the ladder rungs required, and the instruction that
everything outside its files is out of bounds. Overlapping scopes run in
sequence.

Verify from the main thread before reporting a candidate done: re-read the diff,
re-run the build and tests, and confirm the scope held. A sub-agent's claim is
not the evidence. Failed checks, scope drift, or pending required delivery leave
the candidate open with its reason; re-dispatch within scope or surface the decision.

**Done when** every approved candidate meets its verification and agreed delivery
conditions, and the closing message gives a one-line outcome per numbered
candidate. Otherwise report partial completion and the unresolved blockers;
recording a blocker does not complete the candidate.

## Standing guardrails

- **Trust boundaries are protected.** Validation, authorization, error handling
  that prevents data loss, and accessibility affordances stay, however
  redundant they look. The same null check is noise in a private helper and
  mandatory at a process, network, file, plugin, or FFI edge.
- **Deprecation, compatibility, migration, rollback, and disaster-recovery
  paths stay** until a dated statement says the window closed. They are the
  highest-cost false positives: silent at build time, silent in tests, and
  catastrophic on the one day they were written for.
- **Generated output and vendored trees stay.** Reduce them at the schema or
  the dependency, or leave them alone.
- **Baseline against the repository.** Churn, comment density, duplication, and
  function length are interpretable only as percentiles of the surrounding
  code.

Attribution

FirzusFirzus
View sourceSee grades on GitHubMore from Firzus →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698621 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →