Dead code removal
Skill Amey-Thakur/AI-SKILLS/skills/code-quality/dead-code-removal
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill dead-code-removalAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Find code that can never run and delete it without breaking a caller you missed. Use when pruning unused functions, branches, feature flags, or files.
SKILL.md
2.7 KB, as published. Nobody here has run it
Dead code removal
Unused code is not free: it is read during every search, dragged along in every refactor, and trusted during every audit, all for logic that never executes. The risk is deleting something that only looks dead, so removal is a verification job before it is a deletion job.
Method
- Confirm no reference before touching a symbol. Grep the whole tree, not
just the current package:
grep -rn "functionName" .. Include tests, config, string-based lookups, and reflection or dependency-injection names that a symbol search misses. Zero hits across all of these is the bar. - Read a coverage report to find never-run lines. Run the suite under
coverage (
coverage.py,c8,go test -cover) and look for functions and branches sitting at 0 percent. Coverage flags candidates; it does not prove death, since untested is not the same as unreachable. Pair it with grep. - Check exported and dynamic surfaces harder. A public export, a route handler, a serialized class name, or a plugin entry can be called by code you do not own. For these, search callers outside the repo, or deprecate for one release and watch the logs before deleting.
- Clear feature-flag residue once a flag is settled. When a flag has been
fully on or off for good, delete the dead branch, inline the live one, then
remove the flag definition and its config keys. Leaving
if (flags.newFlow)after the rollout finished breeds paths no one tests. - Delete, do not comment out. Version control holds the history; a
commented-out block just becomes code that searches still match and no test
covers. Remove it cleanly and let
git logbe the archive. - Delete in small, reversible commits and let CI referee. One symbol or one
flag per commit, with the full test and build run each time. If something
only looked dead, a red build or a
git bisectpoints straight at the change that removed it.
Signals
- Does
grep -rnacross the entire repo, tests and config included, return zero uses of the symbol? - Is the line at 0 percent coverage because it cannot run, or only because no test exercises it yet?
- After removing a flag, does any config file, dashboard, or deploy script still name it?
Boundaries
Public library APIs are not dead just because this repo does not call them: consumers you cannot see may, so follow a deprecation cycle instead of deleting outright. Reflection-heavy or plugin-based code, where usage is invisible to static search, defers to a human who knows the runtime wiring.