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

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

github.com/hachejDevelopment160 installsUpdated 1d ago
Repository

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

A coding skill for refactors where a new API replaces an internal legacy API. It guides teams to migrate callers, remove the old path, and update tests together when external compatibility is not required.

Key features

  1. 01Inventory and migrate callers
  2. 02Delete legacy API paths
  3. 03Limit temporary adapters
  4. 04Test the new contract

Use cases

  1. 01Refactoring an internal API without external compatibility needs
  2. 02Removing duplicate old and new API paths
  3. 03Updating tests during a coordinated breaking change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hachej/boring-stack --skill principle-migrate-callers-then-delete-legacy-apis

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

Bundled filesLICENSE

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 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