{"id":21507,"plugin_id":"plugins_6aaeb2c568208191bd71d62167ba2ba3","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:58.360Z","digest":"0a58cc59397cbe705dd2fb58c86cd577791428baf7f1e6e21d7ddae0e0848f2e","against":null,"payload":{"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.","included_files":[],"name":"principle-migrate-callers-then-delete-legacy-apis","skill_md_contents":"---\r\nname: principle-migrate-callers-then-delete-legacy-apis\r\ndescription: \"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.\"\r\nuser-invocable: false\r\ndisable-model-invocation: true\r\n---\r\n\r\n# Migrate Callers Then Delete Legacy APIs\r\n\r\nWhen 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.\r\n\r\n**Rule:**\r\n- Do not keep legacy API paths alive only because internal callers still exist\r\n- Inventory callers, migrate them, and delete the old API immediately\r\n- Treat temporary adapters as exceptional and time-boxed, not default architecture\r\n- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details\r\n\r\n**When this applies:**\r\n- No external users depend on backward compatibility\r\n- The project can absorb coordinated breaking changes\r\n- The new API is part of a simplification or refactor initiative\r\n\r\nKeeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.\r\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}