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

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

1|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/edivad1999/stuc-stack --skill principle-migrate-callers-then-delete-legacy-apis-edivad1999
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/edivad1999/stuc-stack/tree/main/skills/principle-migrate-callers-then-delete-legacy-apis
Command: npx skills add https://github.com/edivad1999/stuc-stack --skill principle-migrate-callers-then-delete-legacy-apis-edivad1999

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often keep old API paths alive alongside new ones because internal callers still exist, creating dual-path complexity and append-only codebases. This Skill enforces a refactoring principle: migrate all callers and delete the legacy API in the same wave instead of preserving compatibility layers. ## Core Features & Use Cases - Caller Inventory and Migration: Directs the agent 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: When introducing a new internal Kotlin API while old callers still exist, apply this principle so the refactor completes in one coordinated breaking change instead of leaving parallel code paths. ## Quick Start Apply the migrate-callers-then-delete-legacy-apis principle to refactor this internal API and remove the old 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 remove a legacy API without breaking internal callers?▼

Inventory every internal caller first, migrate them all to the new API, then delete the old API in the same refactor wave. This avoids leaving dual code paths that slow cleanup and create append-only complexity.

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

Keep compatibility layers only when external users depend on backward compatibility or the project cannot absorb coordinated breaking changes. For internal-only APIs, treat temporary adapters as exceptional and time-boxed, not default architecture.

Should I delete old tests after migrating to a new API?▼

Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details. Tests tied to the old implementation add maintenance cost without validating current behavior.

What are the risks of keeping both old and new APIs?▼

Keeping both creates dual-path complexity, slows future cleanup, and makes the codebase feel append-only. Each additional path increases the surface area for bugs and confuses future contributors about which API to use.

When does this migration principle not apply?▼

It does not apply when external consumers depend on the old API, when the project cannot absorb coordinated breaking changes, or when the new API is not part of a simplification or refactor initiative.