principle-migrate-callers-then-delete-legacy-apis

Migrates internal callers to a new API and deletes legacy API paths in the same refactor wave.

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/jnyross/pstack-muse --skill principle-migrate-callers-then-delete-legacy-apis-jnyross
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-migrate-callers-then-delete-legacy-apis
Source: https://github.com/jnyross/pstack-muse/tree/main/skills/principle-migrate-callers-then-delete-legacy-apis
Command: npx skills add https://github.com/jnyross/pstack-muse --skill principle-migrate-callers-then-delete-legacy-apis-jnyross

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When introducing a new internal API, teams often keep the old API alive alongside compatibility layers, creating dual-path complexity and an append-only codebase. This Skill enforces a refactoring principle: migrate all callers and delete the legacy API in the same wave instead of preserving compatibility shims. ## Core Features & Use Cases - Caller Inventory and Migration: Directs you to inventory all internal callers, migrate them to the new API, and remove the old API immediately. - Time-Boxed Adapters: Treats temporary adapters as exceptional and time-boxed rather than default architecture. - Test Cleanup: Updates tests to assert the new contract and deletes tests that only protect pre-refactor implementation details. - Use Case: During a service refactor, you introduce a cleaner data-access interface. Apply this principle to migrate every internal caller, delete the legacy interface, and update the test suite in one coordinated change. ## Quick Start Ask the AI to apply the migrate-callers-then-delete-legacy-apis principle while refactoring an internal module to a new API.

Frequently Asked Questions about principle-migrate-callers-then-delete-legacy-apis

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

FAQPage Schema
How do I migrate callers to a new API without breaking the codebase?

Inventory every internal caller of the old API, migrate them all to the new API in the same refactor wave, then delete the legacy API immediately. Update tests to assert the new contract rather than preserving old behavior.

When should I delete a legacy API instead of keeping a compatibility layer?

Delete the legacy API when no external users depend on backward compatibility and the project can absorb coordinated breaking changes. Compatibility layers should be exceptional and time-boxed, not default architecture.

Should I keep old tests after refactoring to a new API?

Keep only tests that assert the new contract. Delete tests that merely protect pre-refactor implementation details, since they lock in obsolete behavior and slow future changes.

When is a temporary adapter between old and new APIs acceptable?

A temporary adapter is acceptable only as an exceptional, time-boxed measure during migration. It should never become permanent architecture, since keeping both paths creates dual-path complexity.

When should I not apply this migrate-then-delete principle?

Avoid it when external consumers depend on the old API or the project cannot absorb coordinated breaking changes. In those cases, a deprecation and versioning strategy is more appropriate.