agentleFS
kkgogogo17kkgogogo17/pi-pstack/skills/principle-migrate-callers-then-delete-legacy-apis/SKILL.md

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

Skill9 starsChanged 3 months agoMITView on GitHub

Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.

We split this skill into the rules it gives an agent

5 rules. 5 are common, 0 are distinctive, and 0 are very specific to this project.

  • 5

    Common

    Most of the 36 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    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 …

    line 9
  2. Common:

    Do not keep legacy API paths alive only because internal callers still exist

    line 12
  3. Common:

    Treat temporary adapters as exceptional and time-boxed, not default architecture

    line 14
  4. Common:

    Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details

    line 15
  5. Common:

    No external users depend on backward compatibility

    line 18

“Common” is measured: kept by at least 6 in 10 of the 36 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.