| name | deprecation-lifecycle-enforcer |
| description | Apply deprecation lifecycle rules while preserving compatibility and documenting replacement owners/paths. Use when requests deprecate packages/APIs or retire legacy runtimes. |
Skill: deprecation-lifecycle-enforcer
Trigger Signals
Use this skill when requests include:
- "deprecate package"
- "compatibility mode"
- "retire old runtime"
- "mark as deprecated"
Do Not Use When
- Request is introducing brand new package behavior.
- Replacement path is not identified at all.
Required Inputs
- Target package/API.
- Replacement owner/surface.
- Rules:
docs/ai/framework/rules/deprecation-lifecycle.md
Preflight
- Confirm current runtime owner vs deprecated owner.
- List public exports for target package.
- Identify app/framework docs that mention the package.
Deterministic Procedure
- Add deprecation markers:
- JSDoc
@deprecated
- runtime warning (if applicable and already pattern-matched)
- Keep compatibility path stable for existing callers.
- Block new work from landing in deprecated owner.
- Update docs:
- package doc
- API surfaces
- constraints/architecture references
- If requested, add migration checklist entry.
Validation Matrix
- Deprecated status visible at API surface.
- Replacement path documented and callable.
- No new runtime ownership added to deprecated package.
Required Output Format
Deprecated Surface
Compatibility Guarantees
Replacement Path
Validation
Guardrails
- Do not hard-remove compatibility path unless explicitly requested.
- Do not silently change behavior under same API.
- Local commits may close completed, validated steps/stages; never push unless
the user explicitly requests the remote operation. Follow
docs/ai/workflows/git-commit-push-policy.md.
Failure Policy
If replacement is incomplete:
- mark deprecated but keep behavior
- output explicit blockers and migration prerequisites