deleting-code

Guides safe removal of dead code, feature flags, and deprecated interfaces with verification steps.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/m-de-graaff/skills --skill deleting-code-m-de-graaff
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: deleting-code
Source: https://github.com/m-de-graaff/skills/tree/main/skills/deleting-code
Command: npx skills add https://github.com/m-de-graaff/skills --skill deleting-code-m-de-graaff

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Removing code is risky in two directions: deleting something still in use, or "deleting" it by commenting it out and leaving the maintenance cost behind. This Skill provides a disciplined process for proving code is dead before removal and deleting it completely. ## Core Features & Use Cases - Dead code verification: Goes beyond grep to check dynamic dispatch, registries, config, templates, external callers, and other repos, using telemetry instrumentation when source search cannot prove absence of use. - Deprecation sequencing: Provides a four-step ladder (announce, instrument, migrate callers, wait and remove) for public interfaces with callers you do not control. - Feature flag and commit hygiene: Ensures flags are removed in two changes, deletion commits contain no refactors, and tests, docs, config, and dependencies are removed alongside the code. - Use Case: You find a legacy export endpoint nobody seems to call. The Skill walks you through instrumenting it with a warning log, waiting a full billing cycle, then deleting the endpoint, its tests, and its config in one revertible commit. ## Quick Start Ask the AI to help you safely delete a suspected dead feature, flag, or endpoint and verify nothing still references it.

Frequently Asked Questions about deleting-code

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely delete unused code from a codebase?▼

Prove the code is dead first by searching beyond grep: check registries, config files, templates, and other repos. For code with external callers, instrument it with a warning log and wait a full usage cycle before deleting it, its tests, and its config in one commit.

How to deprecate a public API before removing it?▼

Follow a four-step sequence: announce the deprecation with a replacement and removal date, instrument to track remaining callers, migrate callers you control yourself, then wait the announced period before removing. Internal-only code can skip this ceremony entirely.

Why is grep not enough to find dead code?▼

Grep misses dynamic dispatch, reflection, framework auto-discovery, config values, feature flags, templates, SQL strings, and callers in other repositories. A symbol with zero textual references can still be reachable through any of these paths.

Should I comment out code instead of deleting it?▼

No. Version control is the archive, so commented code adds cost with no benefit: it is never read, never runs, and confuses every future search. The same applies to renaming it _old or moving it to an archive directory.

When should a feature flag be removed?▼

Treat a flag at 100% for a month as a bug. Removal is two changes: delete the losing branch and its tests, then delete the flag and its configuration. Create the removal ticket when the flag is created.

What are the limits of deleting code in one commit?▼

A deletion commit should only delete, never refactor or fix, so the revert stays a single safe operation. Database column drops are the exception: they require expand-contract migrations across deploys and are not revertible in one step.