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

Migrate internal callers to new APIs and delete legacy paths in one refactor wave.

136|8|Updated May 9, 2026
One-click install
npx skills add https://github.com/Sma1lboy/rove --skill principle-migrate-callers-then-delete-legacy-apis-sma1lboy
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/Sma1lboy/rove/tree/main/.agents/skills/pstack/skills/principle-migrate-callers-then-delete-legacy-apis
Command: npx skills add https://github.com/Sma1lboy/rove --skill principle-migrate-callers-then-delete-legacy-apis-sma1lboy

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. ## Core Features & Use Cases - Caller Inventory and Migration: Guides you to inventory all internal callers, migrate them to the new API, and remove the old API immediately. - Compatibility Layer Discipline: 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 refactor that replaces an internal data-access API, apply this principle to migrate every caller, delete the legacy interface, and update the test suite in a single coordinated change. ## Quick Start Apply this principle to refactor the current module by migrating all callers to the new API and deleting the legacy code path.

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 path immediately. Coordinated breaking changes are safe when no external users depend on backward compatibility.

When should I keep a compatibility layer during an API refactor?▼

Treat temporary adapters as exceptional and time-boxed, not default architecture. Compatibility layers are only justified when external consumers depend on the old contract; internal-only APIs should be migrated and deleted directly.

Should I delete old tests after refactoring an internal API?▼

Update tests to assert the new contract and delete tests that only protect pre-refactor implementation details. Keeping obsolete tests preserves dual-path complexity and slows future cleanup.

When does this migrate-and-delete approach not apply?▼

It does not apply when external users depend on backward compatibility or when the project cannot absorb coordinated breaking changes. In those cases, versioned APIs or deprecation cycles are more appropriate.

Why is keeping both old and new APIs harmful?▼

Maintaining dual API paths creates ongoing complexity, slows cleanup efforts, and makes the codebase feel append-only. Deleting the legacy API in the same wave keeps the architecture coherent.