Delete First Pass
Looks for what can come out before anything new goes in.
When to reach for it
Before adding to a file or module that already feels heavy, and any time a request lands on code you suspect nothing is using any more.
What changes
- The agent hunts for removable code first — unused exports, unreachable branches, superseded helpers, config nobody reads — and reports each one.
- Every candidate comes with the search that proves it has no callers, so deleting is a fact rather than a hunch.
- Deletions land as their own change, separate from the feature, so a mistake is a one-line revert instead of an investigation.
- The thing you actually wanted turns out smaller, because part of it already existed in something that was about to be deleted.
- Code kept alive only by its own tests gets identified as dead, tests included, rather than protected by them.
Pairs with
- Comment AuditStrips the comments that repeat the code and keeps the ones carrying facts the code cannot state.
- Accessibility PassCatches the accessibility failures generated interfaces produce almost every time.
- Read Your Own DiffMakes the agent review the change as a stranger would, before it tells you the work is done.
Delete First Pass
Before adding anything here, spend a few minutes finding what can leave.
1. Look for the usual removable things
In the files you are about to touch and their immediate neighbours:
- Exports nothing imports.
- Branches that cannot be reached, including flags that only ever have one value now.
- Two functions doing the same job, one of them newer.
- Parameters every caller passes the same value for.
- Compatibility code for a version, browser or endpoint that is gone.
- Commented-out code of any age.
- Config keys never read, and tests that assert nothing.
2. Prove each one
Search the whole repository for the name — including string literals, dynamic access, config files, generated code and documentation. Then check whether the only references are its own tests. Code kept alive purely by its tests is dead code with a support system.
Write the evidence beside the candidate: "no matches outside its own test file".
3. Sort what you found
- Delete now — proven unused, nothing outside this repository depends on it.
- Ask — looks unused but is exported from a public interface, or is reached by a name assembled at runtime that you cannot search for.
- Keep — used, or too risky to settle quickly. Say which of the two.
4. Delete in its own change
The deletions go first, alone, and the tests run afterward. A separate deletion is a clean revert when something turns out to have needed it.
5. Now write the addition
Re-read the request. It is usually smaller once the clutter is gone, and some of it may already exist in something you nearly removed.
Rules
- Do not delete on a hunch. No search, no deletion.
- Do not delete and add in one commit. When it breaks, nobody can tell which half did it.
- Do not comment code out instead of deleting it. Version control already remembers; a commented block only creates doubt.
- Do not delete something you do not understand just because nothing calls it. Unclear plus unused means ask, not remove.