deprecation
Skill1 starsChanged 36 days agoMITView on GitHub
Retire code, endpoints, fields, flags and dependencies safely, and migrate data without downtime using expand/contract. Use when removing or renaming a field, column, endpoint, event, feature flag or module, when code is suspected dead, when migrating consumers from an old interface to a new one, or when the user says "deprecate", "remove", "sunset", "clean up dead code". Execution core of the /develop deprecation branch.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Mehul72/skillstheir own version, first seen Nov 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Mehul72/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 repository19 other files it gives its agents.
- api-designSkill
- create-prSkill
- developSkill
- diagnoseSkill
- disk-cleanupSkill
- domain-modelingSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- observabilitySkill
- prototypeSkill
- receiving-code-reviewSkill
- security-hardeningSkill
- setupSkill
- tddSkill
- to-specSkill
- to-ticketsSkill
- write-a-skillSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 41
Remove zombie code: only with step 1's evidence at zero consumers.
≈ “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
Deprecation and migration
Code is a liability: every line has a maintenance cost and an attack surface. Removing it is an achievement — but only once you've proven nothing depends on it.
When NOT to use
- Behavior-preserving restructuring with the same public surface — that is a refactor.
- Language or type-system migrations with no change in behavior — mechanical migration.
- Dependency vulnerability bumps.
Process
- Find every consumer. Grep across the whole repository for every spelling of the name
(camelCase, snake_case, string literals, dynamic keys) and every source extension in play;
check other repositories, configs, scheduled jobs, analytics/data pipelines and external
clients. Record the evidence (
file:lineor "0 hits for<pattern>"). - Decide the kind of deprecation.
- Advisory (default): mark deprecated, document the replacement, stop new usage, let consumers migrate.
- Compulsory: a removal date the consumers must meet. Requires an owner and a plan for each known consumer. Churn rule: whoever owns the thing being removed migrates its consumers (or funds it) — don't push the cost onto them.
- Pick the migration pattern.
- Strangler — route traffic gradually from old to new behind one entry point.
- Adapter — keep the old interface as a thin shim over the new implementation.
- Feature flag — switch per tenant/percentage, with an owner and an expiry date.
- Persisted data: expand/contract, each step its own deployable change:
- Expand — add the new field/column/collection; old code ignores it.
- Dual-write — write both old and new; read old.
- Backfill — migrate existing records (idempotent, resumable, batched); verify counts.
- Switch reads — read new; keep writing both for a rollback window.
- Contract — stop writing old, then drop it, after the window and once consumers are at 0. Notify downstream data consumers at step 1 and step 5.
- Remove zombie code only with step 1's evidence at zero consumers. Delete the code, its tests, config, flags and docs together; mention the evidence in the PR.
Common Rationalizations
| Rationalization | Reality |
| "Nobody calls it, I checked the obvious file" | One grep in one extension is not evidence. Callers hide in other file types, strings and other repos. |
| "Rename the column in one migration, it's quicker" | Every running instance with the old code breaks mid-deploy. Expand/contract. |
| "We'll backfill later" | Reads switch, old records come back empty. Backfill before switching reads. |
| "Leave the flag, it doesn't hurt" | Every stale flag doubles the paths to test and reason about. Flags get an expiry. |
| "It might be useful someday" | That's what version control is for. |
Red Flags
- A field/column dropped in the same change that stops writing it.
- A backfill that is not idempotent or can't resume after a crash.
- "Dead code" removed without a recorded consumer search.
- Shared or externally consumed artefacts (translations, public events, API fields) deleted by a code change instead of their owning process.
- A feature flag with no owner or expiry.
Verification
- Consumer search recorded with patterns and results
- Each expand/contract step is its own deployable change, in order
- Backfill verified (counts before/after) and re-runnable
- Downstream data consumers notified (expand and contract)
- Removed code's tests, config, flags and docs removed with it
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.