deprecation-and-migration
Skill1 starsChanged 11 days agoMITView on GitHub
Manage deprecation and migration of old systems, APIs, and features. Covers sunset strategies, backward compatibility, timelines. Do NOT use for new feature development.
We split this skill into the rules it gives an agent
3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 54 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 80
Every deprecation needs a written notice sent before the change.
- Distinctive: line 85
No migration path — removing the old system without telling users what replaces it.
- Distinctive: line 87
No rollback plan — the new system has issues and the old system is already gone.
“Common” is measured: kept by at least 6 in 10 of the 54 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deprecation and Migration
Remove old systems safely. Migrate users without breaking trust.
The only skill that covers the full lifecycle of retiring functionality: deciding what to sunset, planning migration paths, maintaining backward compatibility during transition, and communicating changes to users.
Sources: OpenAPI Specification (openapis.org) — deprecation marking, backward compatibility rules, versioning scheme. Semantic Versioning 2.0 (semver.org) — breaking change rules. Strangler Fig pattern (Martin Fowler) — incremental migration. Google SRE Workbook (sre.google/workbook) — sunset procedures.
When to Use
- Removing or replacing an existing API endpoint
- Migrating users from one implementation to another
- Deciding whether to maintain or sunset existing code
- Planning backward-compatible transitions
- A third-party API or dependency your system relies on announces deprecation
Output Contract
Deprecation + migration plan — documented timeline (Announce → Deprecate → Support → Sunset) with source code changes in existing source tree, migration strategy chosen with risk level (parallel/strangler/big-bang/phased), backward compatibility rules followed (breaking = MAJOR), deprecated endpoints marked with deprecated flag + Sunset HTTP header, deprecation notice published before support window, migration guide with before/after examples, rollback plan in place, old system officially sunset after window expires.
When NOT to Use
- Building new features (use feature implementation skills)
- Deployment (use shipping-and-launch)
Deprecation Lifecycle
Announce → Deprecate → Support Window → Sunset| Phase | Duration | What Happens |
| Announce | Before deprecation release | Publish changelog, migration guide, deprecation timeline |
| Deprecate | From release | Mark feature as deprecated, warn users on access |
| Support window | 6-12 months | Old version still works, users migrate on their schedule |
| Sunset | After window | Remove feature, return 410 Gone or redirect to replacement |
The support window must be long enough for all known users to migrate. One year is standard for public APIs. Internal systems can use shorter windows (3-6 months).
Migration Strategies
| Strategy | How It Works | Risk | Best For |
| Parallel run | Old and new systems run simultaneously | Low | Critical systems, gradual cutover |
| Strangler Fig | Route traffic incrementally from old to new | Medium | Large monoliths, gradual replacement |
| Big Bang | Switch all traffic at once | High | Simple replacements, feature flags |
| Phased rollout | Migrate users in groups | Medium | Multi-tenant systems |
See guides/MIGRATION-STRATEGIES.md for decision trees and detailed implementation patterns.
Backward Compatibility
Additive changes are always backward compatible. Removing or changing behavior requires a deprecation window.
| Change Type | Compatible? | Version Bump |
| Adding an optional field | Yes | MINOR |
| Adding a new endpoint | Yes | MINOR |
| Removing a field | No — breaking | MAJOR |
| Changing a field type | No — breaking | MAJOR |
| Adding a required field | No — breaking | MAJOR |
| Changing endpoint URL | No — breaking | MAJOR |
Communication
Every deprecation needs a written notice sent before the change. See guides/DEPRECATION-COMMUNICATION.md for templates covering deprecation notices, migration guides, and sunset announcements.
Anti-Patterns
- Silent removal — deleting a feature without warning. Users discover it's gone.
- No migration path — removing the old system without telling users what replaces it.
- Too short a window — deprecating on Friday and removing on Monday.
- No rollback plan — the new system has issues and the old system is already gone.
- Deprecation without replacement — removing a feature with no alternative.
- Forcing migration — breaking existing users instead of giving them time.
Verification
- Deprecation lifecycle defined with timeline
- Migration strategy chosen and documented
- Backward compatibility rules followed (breaking = MAJOR version)
- Deprecation notice published before support window starts
- Migration guide provided with clear before/after examples
- Rollback plan in place if migration fails
- Old system officially sunset after window expires
Other versions60 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 60
- addyosmani/agent-skills★ 112ksame name
- rizqinrr/viserys-agent★ 556same name
- shashankswe2020-ux/whoop-mcp★ 174same name
- drvoss/everything-copilot-cli★ 49same name
- vinvcn/addyosmani-agent-skills-zh★ 46same name
- jmxt3/gitscape.ai★ 33same name
- sampleXbro/agentsmesh★ 24same name
- jaskirat1616/grok-skills★ 22same name
- HK-hub/AgentSkills★ 6same name
- lza6/claw-code-tingfeng★ 5same name
50 more not listed
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.
Used alongsideProjects with it also use constraint-driven-development, verification-before-completion and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MrCipherSmithSkillconstraint-driven-development
Use when a project needs a persistent, measurable quality bar — starting a project without documented standards, 'set up constraints', or when coverage/perf/a11y thresholds get re-debated per-PR. Produces CONSTRAINTS.md with enforceable numbers, ratchets, and a guard against silent weakening. NOT for throwaway prototypes or a one-off CI setup.
Also in 12 projects that use this
OpenAISkillverification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Also in 4 projects that use this
OpenAISkillfinishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
Also in 3 projects that use this
MicrosoftSkillcaveman
Ultra-compressed response style that reduces output token count while preserving technical accuracy, with intensity levels and auto-clarity safety rules
Also in 3 projects that use this
GoogleSkillimprove-codebase-architecture
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
Also in 3 projects that use this
- +5 more from openai
In this repository59 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/CLAUDE.mdCLAUDE.md
- adapt-skillSkill
- api-and-interface-designSkill
- architecture-analysisSkill
- audit-skillSkill
- backend-api-masterySkill
- browser-testing-with-devtoolsSkill
- ci-cd-and-automationSkill
- clarify-skillSkill
- cli-toolsSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- context-engineeringSkill
- critique-skillSkill
- customize-opencodeSkill
- debugging-and-error-recoverySkill
- debugging-three-strikesSkill
- delight-skillSkill
- dev-environment-auditSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- engineering-fundamentalsSkill
- frontend-desktopSkill
- frontend-mobileSkill
- frontend-pwaSkill
- frontend-ui-engineeringSkill
- frontend-webSkill
- fullstack-shippingSkill
- gateSkill
- git-init-and-versioningSkill
- git-workflow-and-versioningSkill
- hard-skillSkill
- idea-refineSkill
- incremental-implementationSkill
- industrial-brutalist-uiSkill
- interview-meSkill
- minimalist-uiSkill
- multi-agent-orchestrationSkill
- observability-and-instrumentationSkill
- optimize-skillSkill
- output-skillSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- polish-skillSkill
- project-health-checkSkill
- project-metricsSkill
- redesign-skillSkill
- security-and-hardeningSkill
- self-improvementSkill
- shipping-and-launchSkill
- skill-creatorSkill
- skill-improverSkill
- soft-premium-uiSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- test-driven-developmentSkill
- typeset-skillSkill
- user-onboardingSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

