deprecation-and-migration

Name: deprecation-and-migration
Author: pimenov

20stars2forks

How to install deprecation-and-migration?

pimenov/codex-first-skills-pack/deprecation-and-migration

$npx -y skills add pimenov/codex-first-skills-pack --skill deprecation-and-migration

Installs into the current project.

Summary

Plans safe deprecation, migration, sunset, replacement, and removal of old systems, APIs, features, schemas, flags, cron jobs, integrations, configs, libraries, UI flows, and operational processes. Use when retiring legacy code, replacing an implementation, removing a public/inte

Files · 1

View on GitHub

SKILL.md

1	# Deprecation and Migration
2
3	## Overview
4
5	Deprecation is not deletion. It is the managed transfer of consumers from old behavior to a safer replacement, followed by evidence-backed removal.
6
7	Use this skill to avoid two common failures: keeping legacy systems forever because nobody owns the migration, or deleting "unused" behavior that still has hidden consumers.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when the source of truth, owner, live state, or relevant docs are unclear.
12	- Use `source-driven-development` when migration depends on current vendor docs, SDK changes, platform deprecations, version support, or external API behavior.
13	- Use `api-and-interface-design` when the deprecated surface is an API, schema, event, CLI, config format, or module boundary.
14	- Use `spec-driven-development` when the desired replacement behavior or success criteria are unclear.
15	- Use `planning-and-task-breakdown` to turn the migration into waves, issues, owners, gates, and Definition of Done.
16	- Use `incremental-implementation` to migrate one consumer or slice at a time.
17	- Use `test-driven-development` for compatibility tests, migration fixtures, adapter checks, and regression guards.
18	- Use `doubt-driven-review` before irreversible removal, public deprecation deadlines, production cleanup, data migrations, auth changes, or claims that rollback is safe.
19	- Use `code-review-and-quality` before accepting removal diffs.
20
21	## Do Not Use
22
23	- Do not use to justify cleanup without consumer evidence.
24	- Do not remove production, data, secrets, auth, DNS, billing, cron, routing, webhooks, integrations, or public interfaces without explicit approval.
25	- Do not assume code is unused because local search found no references.
26	- Do not create a migration plan if there is no replacement, owner, or rollback path. Return a no-go instead.
27	- Do not turn every tiny private refactor into a formal migration plan.
28
29	## Core Loop
30
31	Work in this order:
32
33	1. INVENTORY
34	2. DECISION
35	3. REPLACEMENT
36	4. MIGRATION PLAN
37	5. ROLLOUT
38	6. REMOVAL READINESS
39	7. HANDOFF
40
41	## 1. Inventory
42
43	Identify what is being deprecated and who depends on it.
44
45	Capture:
46
47	- Artifact: code path, route, API, schema, feature flag, workflow, cron, integration, library, config, UI, document, or operational process.
48	- Owner: team, person, repo, service, project, or "unknown".
49	- Current state: active, deprecated, zombie, duplicate, broken, experimental, replaced, or unknown.
50	- Consumers: direct callers, imports, database references, events, dashboards, docs, automations, tests, operators, external customers, partners, agents.
51	- Evidence sources: `rg`, dependency graph, logs, metrics, tracing, analytics, GitHub search, Linear/Notion docs, production config, support history, runbooks, live smoke.
52	- Risk surfaces: data loss, auth/permission changes, billing, public API, partner integration, SEO, notifications, scheduled jobs, backups, audit trail.
53
54	If the owner or consumers are unknown, start read-only discovery and do not propose removal yet.
55
56	## 2. Decision
57
58	Choose the correct posture.
59
60	Use these outcomes:
61
62	- Maintain: the old system still has unique value or migration cost exceeds maintenance risk.
63	- Freeze: stop adding new features while measuring usage and preparing replacement.
64	- Advisory deprecation: migration is recommended, no hard removal date yet.
65	- Compulsory deprecation: removal has a deadline because risk or cost is high enough.
66	- Emergency disablement: immediate safety issue; use incident handling and explicit approval.
67	- Remove now: only when zero usage and rollback/evidence are clear.
68
69	For each decision, state:
70
71	- why now;
72	- who owns the migration;
73	- what happens if nothing changes;
74	- what evidence would change the decision;
75	- what must not be touched.
76
77	## 3. Replacement
78
79	Never deprecate critical behavior without a usable target.
80
81	Check replacement readiness:
82
83	- covers critical old use cases;
84	- preserves required compatibility or explicitly changes behavior;
85	- has docs or examples for consumers;
86	- has tests or smoke checks;
87	- has operational ownership;
88	- has observability for migration progress;
89	- has rollback or compatibility shim;
90	- has known gaps documented.
91
92	If the replacement is not ready, output "No-go: replacement not ready" and list the smallest safe next step.
93
94	## 4. Migration Plan
95
96	Plan migration around consumers, not around files.
97
98	Define:
99
100	- consumer

People who liked this also viewed

6 picks

Type

deprecation-and-migration

20stars2forks

View on GitHub

How to install deprecation-and-migration?

pimenov/codex-first-skills-pack/deprecation-and-migration

$npx -y skills add pimenov/codex-first-skills-pack --skill deprecation-and-migration

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Deprecation and Migration
2
3	## Overview
4
5	Deprecation is not deletion. It is the managed transfer of consumers from old behavior to a safer replacement, followed by evidence-backed removal.
6
7	Use this skill to avoid two common failures: keeping legacy systems forever because nobody owns the migration, or deleting "unused" behavior that still has hidden consumers.
8
9	## Relationship To Other Skills
10
11	- Use `context-engineering` first when the source of truth, owner, live state, or relevant docs are unclear.
12	- Use `source-driven-development` when migration depends on current vendor docs, SDK changes, platform deprecations, version support, or external API behavior.
13	- Use `api-and-interface-design` when the deprecated surface is an API, schema, event, CLI, config format, or module boundary.
14	- Use `spec-driven-development` when the desired replacement behavior or success criteria are unclear.
15	- Use `planning-and-task-breakdown` to turn the migration into waves, issues, owners, gates, and Definition of Done.
16	- Use `incremental-implementation` to migrate one consumer or slice at a time.
17	- Use `test-driven-development` for compatibility tests, migration fixtures, adapter checks, and regression guards.
18	- Use `doubt-driven-review` before irreversible removal, public deprecation deadlines, production cleanup, data migrations, auth changes, or claims that rollback is safe.
19	- Use `code-review-and-quality` before accepting removal diffs.
20
21	## Do Not Use
22
23	- Do not use to justify cleanup without consumer evidence.
24	- Do not remove production, data, secrets, auth, DNS, billing, cron, routing, webhooks, integrations, or public interfaces without explicit approval.
25	- Do not assume code is unused because local search found no references.
26	- Do not create a migration plan if there is no replacement, owner, or rollback path. Return a no-go instead.
27	- Do not turn every tiny private refactor into a formal migration plan.
28
29	## Core Loop
30
31	Work in this order:
32
33	1. INVENTORY
34	2. DECISION
35	3. REPLACEMENT
36	4. MIGRATION PLAN
37	5. ROLLOUT
38	6. REMOVAL READINESS
39	7. HANDOFF
40
41	## 1. Inventory
42
43	Identify what is being deprecated and who depends on it.
44
45	Capture:
46
47	- Artifact: code path, route, API, schema, feature flag, workflow, cron, integration, library, config, UI, document, or operational process.
48	- Owner: team, person, repo, service, project, or "unknown".
49	- Current state: active, deprecated, zombie, duplicate, broken, experimental, replaced, or unknown.
50	- Consumers: direct callers, imports, database references, events, dashboards, docs, automations, tests, operators, external customers, partners, agents.
51	- Evidence sources: `rg`, dependency graph, logs, metrics, tracing, analytics, GitHub search, Linear/Notion docs, production config, support history, runbooks, live smoke.
52	- Risk surfaces: data loss, auth/permission changes, billing, public API, partner integration, SEO, notifications, scheduled jobs, backups, audit trail.
53
54	If the owner or consumers are unknown, start read-only discovery and do not propose removal yet.
55
56	## 2. Decision
57
58	Choose the correct posture.
59
60	Use these outcomes:
61
62	- Maintain: the old system still has unique value or migration cost exceeds maintenance risk.
63	- Freeze: stop adding new features while measuring usage and preparing replacement.
64	- Advisory deprecation: migration is recommended, no hard removal date yet.
65	- Compulsory deprecation: removal has a deadline because risk or cost is high enough.
66	- Emergency disablement: immediate safety issue; use incident handling and explicit approval.
67	- Remove now: only when zero usage and rollback/evidence are clear.
68
69	For each decision, state:
70
71	- why now;
72	- who owns the migration;
73	- what happens if nothing changes;
74	- what evidence would change the decision;
75	- what must not be touched.
76
77	## 3. Replacement
78
79	Never deprecate critical behavior without a usable target.
80
81	Check replacement readiness:
82
83	- covers critical old use cases;
84	- preserves required compatibility or explicitly changes behavior;
85	- has docs or examples for consumers;
86	- has tests or smoke checks;
87	- has operational ownership;
88	- has observability for migration progress;
89	- has rollback or compatibility shim;
90	- has known gaps documented.
91
92	If the replacement is not ready, output "No-go: replacement not ready" and list the smallest safe next step.
93
94	## 4. Migration Plan
95
96	Plan migration around consumers, not around files.
97
98	Define:
99
100	- consumer

People who liked this also viewed

6 picks

Type