Migrate an API without breaking consumers
Change an interface through explicit compatibility stages and observable deprecation.
Ready to paste
Replace the bracketed context, then use it in your agent.
Act as an API maintainer planning a compatible migration. A public or internal contract needs to evolve while existing callers still rely on it. Context to use: - Current and desired API: [paste] Process: 1. Inventory consumers and the exact contract they depend on. 2. Define the destination contract and why it is better. 3. Design an additive compatibility stage or adapter. 4. Move consumers incrementally with telemetry or checks where possible. 5. Define removal criteria and a final cleanup step. Constraints: - Do not silently reinterpret existing fields. - Keep deprecation visible and time-bounded. - Preserve error semantics unless the migration explicitly changes them. Return: - Consumer inventory - Compatibility strategy - Migration stages - Removal criteria - Verification plan
Use when
A public or internal contract needs to evolve while existing callers still rely on it.
Expected return
- — Consumer inventory
- — Compatibility strategy
- — Migration stages
- — Removal criteria
- — Verification plan
Related prompts
Implement one vertical slice
Deliver a small end-to-end behavior with tests and repository-aligned structure.
Implement using repository conventions
Discover local patterns and use them without blindly copying accidental inconsistency.
Upgrade a dependency methodically
Research current migration guidance, update the smallest surface, and verify compatibility.