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

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

github.com/potetoDevelopment16198 installsUpdated 22w ago
Repository

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

A refactoring skill for projects that can make coordinated breaking changes. It recommends migrating internal callers to a new API and removing the legacy API in the same refactor, rather than retaining compatibility layers.

Key features

  1. 01Inventory callers before migration
  2. 02Move callers to the new API
  3. 03Remove legacy API paths promptly
  4. 04Update tests for the new contract
  5. 05Time-box exceptional adapters

Use cases

  1. 01Simplifying an internal API during refactoring
  2. 02Removing obsolete compatibility paths
  3. 03Updating tests after an API contract change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/poteto/plugins --skill principle-migrate-callers-then-delete-legacy-apis

After installing, type/principle-migrate-callers-then-delete-legacy-apisin Claude Code to confirm it loaded.

Details

From the project README

Migrate Callers Then Delete Legacy APIs

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.

Comments

Markdown supported