dead-code-eliminator
Skill2 starsChanged 38 days agoMITView on GitHub
Proves code is unreachable with converging evidence, then removes it and its tests, fixtures, and flags in reversible slices without breaking dynamic callers. Use when deleting suspected dead code, cleaning up after a migration or feature retirement, trimming a bloated module, or before estimating work on unfamiliar code. Do NOT use when you want to survey and rank an area's debt without committing to deletion - use find-tech-debt instead.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- santosomar/general-secure-coding-agent-skillstheir own version, first seen Mar 10, 2026
- rainoftime/pl-skillstheir own version, first seen Feb 19, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- rainoftime/pl-skills★ 17same name
- santosomar/general-secure-coding-agent-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Delete code only after converging evidence proves it dead, then remove it in reversible slices that include its tests, fixtures, config, …
- Very specific: line 14
Gather static evidence: Run the language's dead-code detector (ts-prune or knip for TS/JS, vulture for Python, deadcode for Go) and a …
- Distinctive: line 27
Every deletion cites at least two independent converging signals (static + runtime).
- Distinctive: line 34
Treat "I can't find a caller" as proof of death - absence of a static caller is not absence of a dynamic one.
- Distinctive: line 35
Delete code you only suspect is dead, public API without consumer proof, or code added in the last few weeks (it may be ahead of its …
- Distinctive: line 40
When evidence is ambiguous, mark the symbol deprecated and instrument it rather than guessing.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Dead Code Eliminator
Delete code only after converging evidence proves it dead, then remove it in reversible slices that include its tests, fixtures, config, and flags.
Workflow
- Scope one cluster. Pick a single symbol, file, or feature to prove dead. Do not batch unrelated removals - a regression must point to one change.
- Gather static evidence. Run the language's dead-code detector (ts-prune or knip for TS/JS, vulture for Python,
deadcodefor Go) and a dependency grapher (madge) or IDE "find usages". Record what each reports unreachable. - Gather runtime evidence. Check production coverage or profiling data over a representative window - at least 30 days for user-facing paths, 90+ days for code tied to monthly or quarterly jobs - and telemetry: was this endpoint, job, or branch hit this quarter? A symbol is a deletion candidate only when static analysis AND runtime evidence agree. One signal alone produces false positives that take down prod.
- Hunt the dynamic callers static tools miss. Grep the symbol name as a string (reflection, string-keyed dispatch, serialization). Check DI containers, registries, ORM hooks, cron/queue workers, and feature-flag config. Search infra repos and other services. Public API surface and library exports are reachable by definition unless you control every consumer.
- Classify the kind of dead, because each is removed differently. Unreachable (no path calls it) → delete. Unused (callable, never called) → delete. Redundant (duplicates a live path) → repoint callers first. Dormant-behind-a-flag (flag off for a cycle) → retire the flag first, then delete its branch.
- Soft-delete risky removals first. Replace the suspect path with log-and-throw, or gate it behind a kill flag while keeping the code, for one full business cycle - 30 days minimum, 90 for anything touching monthly or quarterly processes. If nothing fires the log, proceed. For low-risk leaf code, skip to step 7.
- Delete in a focused PR. Remove the code AND its tests, fixtures, config, flags, and now-orphaned imports. Keep the diff under roughly 400 changed lines so it is reviewable in one sitting; a bigger cluster gets split into multiple PRs. Let CI and the type-checker catch references the search missed. No formatting or refactors in the same diff.
Deliverable
Produce a deletion PR (one per cluster) containing the removed code plus its entire footprint - tests, fixtures, config, flags, orphaned imports - and a PR description that cites the two converging evidence signals, names which of the four kinds of dead the code is, and, for soft-deleted paths, records the observation window with zero hits.
Quality bar
- Every deletion cites at least two independent converging signals (static + runtime).
- The PR removes the dead symbol's entire footprint, leaving no orphaned test, fixture, or flag.
- The removal names which of the four kinds of dead it is.
- Reverting the PR cleanly restores the prior behavior.
Do NOT
- Treat "I can't find a caller" as proof of death - absence of a static caller is not absence of a dynamic one.
- Delete code you only suspect is dead, public API without consumer proof, or code added in the last few weeks (it may be ahead of its caller).
- Skip the string-grep and DI/flag/registry check for anything invoked indirectly.
- Fold formatting or refactors into a deletion PR.
- Batch many clusters into one PR.
When evidence is ambiguous, mark the symbol deprecated and instrument it rather than guessing.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

