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

Migrate internal callers to a new API and delete the legacy API in one refactor wave.

6.6k|542|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/cursor/plugins --skill principle-migrate-callers-then-delete-legacy-apis
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/cursor/plugins/tree/main/pstack/skills/principle-migrate-callers-then-delete-legacy-apis
Command: npx skills add https://github.com/cursor/plugins --skill principle-migrate-callers-then-delete-legacy-apis

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Teams often keep old and new APIs alive side by side, creating dual-path complexity, append-only codebases, and cleanup that never happens. This Skill enforces a refactoring discipline where callers are migrated and the legacy API is deleted in the same wave.

Core Features & Use Cases

  • Caller Inventory and Migration: Directs you to find all internal callers of the old API and move them to the new contract before removal.
  • Legacy API Deletion: Removes the old API immediately after migration instead of preserving compatibility layers.
  • Test Contract Updates: Updates tests to assert the new API contract and deletes tests that only protect pre-refactor implementation details.
  • Use Case: When introducing a simplified internal service interface, apply this principle to migrate every caller, delete the old endpoints, and avoid leaving time-boxed adapters as permanent architecture.

Quick Start

Apply this principle to refactor the legacy user service API by migrating all internal callers to the new interface and deleting the old code paths in the same change.

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 to the new contract, and delete the legacy API in the same refactor wave. Update tests to assert the new behavior rather than preserving old implementation details.

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

Delete it 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 API tests after a refactor?

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 this migrate-then-delete approach not appropriate?

Avoid it when external consumers rely on the old API or when the system cannot absorb coordinated breaking changes. In those cases, versioned APIs or gradual deprecation with published timelines are safer.

What problems come from keeping both old and new APIs alive?

Dual API paths create maintenance overhead, make the codebase feel append-only, and delay cleanup indefinitely. Each additional path multiplies testing surface and confuses future contributors about the canonical approach.