Clean up dead code
Work only the area the current prompt is about: files named, the diff just made, the thing being discussed. Don't sweep the repo.
- Read the ask to fix the scope. State in one line what's in bounds.
- Find the dead: unreachable branches, unused exports/params/props, orphaned files, commented-out blocks, stale comments describing code that no longer exists, config for features that shipped or died.
- Prove it before deleting. Grep every symbol and file path you plan to remove, across the whole repo, not just the module: imports, re-exports, dynamic/string references, tests, config, docs, other languages. A thing with one live callsite is not dead. If you can't prove it's unused, leave it and say why.
- Condense the comments. A comment describes the code as it is now: short, present tense, one line where one line does. Cut anything that narrates history instead of state: "was X, now Y", "changed to fix…", "previously handled by…", "keeping this for now", dates, PR/ticket numbers, before/after rationale. Git already has that. Cut restated code (
// increment i) and stale text describing behavior that moved. Keep the non-obvious why (an invariant, a workaround for a real upstream bug, a load-bearing ordering constraint), trimmed to its point.
- Delete, don't rewrite. Removing is in scope; refactoring behavior is not. If something reads badly but is live, note it and move on.
- Run the lint/test/typecheck gate for what you touched.
Output: what you removed with file:line · what you left and the callsite that saved it · anything suspicious you couldn't prove either way, for the user to decide.
Frozen paths (legacy/, _experimental/, anything a project rule marks as retained-but-dormant) are never dead, so skip them.
1---2name: cleanup3description: Removes dead code in the area the current prompt is about, verifying every callsite of what it touches first so nothing regresses. Read the ask, find what's actually unreachable, prove it, then delete. Use when the user says "cleanup", "remove dead code", or "tidy this up".4---56# Clean up dead code78Work **only** the area the current prompt is about: files named, the diff just made, the thing being discussed. Don't sweep the repo.9101. **Read the ask** to fix the scope. State in one line what's in bounds.112. **Find the dead**: unreachable branches, unused exports/params/props, orphaned files, commented-out blocks, stale comments describing code that no longer exists, config for features that shipped or died.123. **Prove it before deleting.** Grep every symbol and file path you plan to remove, across the whole repo, not just the module: imports, re-exports, dynamic/string references, tests, config, docs, other languages. A thing with one live callsite is not dead. If you can't prove it's unused, leave it and say why.134. **Condense the comments.** A comment describes the code as it is *now*: short, present tense, one line where one line does. Cut anything that narrates history instead of state: "was X, now Y", "changed to fix…", "previously handled by…", "keeping this for now", dates, PR/ticket numbers, before/after rationale. Git already has that. Cut restated code (`// increment i`) and stale text describing behavior that moved. Keep the non-obvious *why* (an invariant, a workaround for a real upstream bug, a load-bearing ordering constraint), trimmed to its point.145. **Delete, don't rewrite.** Removing is in scope; refactoring behavior is not. If something reads badly but is live, note it and move on.156. Run the lint/test/typecheck gate for what you touched.1617**Output**: what you removed with `file:line` · what you *left* and the callsite that saved it · anything suspicious you couldn't prove either way, for the user to decide.1819Frozen paths (`legacy/`, `_experimental/`, anything a project rule marks as retained-but-dormant) are never dead, so skip them.
LinardsLiepenieks