Migrate Callers Then Delete Legacy APIs
SkillDev toolsApply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Migrate Callers Then Delete Legacy APIs skill
What this skill tells your AI
The instructions your AI receives, as published by sma1lboy/rove in .agents/skills/pstack/skills/principle-migrate-callers-then-delete-legacy-apis/SKILL.md and read by ahel’s review.
When we decide a new API is the right design, migrate callers and remove the old API in the same refactor wave instead of preserving compatibility layers.
Rule:
- Do not keep legacy API paths alive only because internal callers still exist
- Inventory callers, migrate them, and delete the old API immediately
- Treat temporary adapters as exceptional and time-boxed, not default architecture
- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details
When this applies:
- No external users depend on backward compatibility
- The project can absorb coordinated breaking changes
- The new API is part of a simplification or refactor initiative
Keeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.
Signals
- GitHub stars
- 122
- Forks
- 8
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
principle-migrate-callers-then-delete-legacy-apis-sma1lboy- Source
- github.com/sma1lboy/rove