principle-migrate-callers-then-delete-legacy-apis
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.
Install
npx skills add https://github.com/michael-denyer/pstack-claude/tree/main/plugins/pstack/skills/principle-migrate-callers-then-delete-legacy-apis
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install michael-denyer-pstack-claude@llmmart
git clone https://github.com/michael-denyer/pstack-claude.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole michael-denyer/pstack-claude collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
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.
Files (pstack-claude)
-
SKILL.md 1.1 KB
--- name: principle-migrate-callers-then-delete-legacy-apis description: "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." user-invocable: false --- # 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 (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.