# Principle Migrate Callers Then Delete Legacy Apis

Apply when introducing a new internal API while old callers still exist.

- Repository: https://github.com/nightly-labs/openbot (4509 stars)
- Category: Engineering
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add nightly-labs/openbot --skill principle-migrate-callers-then-delete-legacy-apis -g -a claude-code -y`
Codex: `npx skills add nightly-labs/openbot --skill principle-migrate-callers-then-delete-legacy-apis -g -a codex -y`
Cursor: `npx skills add nightly-labs/openbot --skill principle-migrate-callers-then-delete-legacy-apis -g -a cursor -y`
Gemini CLI: `npx skills add nightly-labs/openbot --skill principle-migrate-callers-then-delete-legacy-apis -g -a gemini-cli -y`

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

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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