schema-evolution-and-contract-migrations

Name: schema-evolution-and-contract-migrations
Author: vaquarkhan

19stars4forks

How to install schema-evolution-and-contract-migrations?

vaquarkhan/data-engineering-agent-skills/schema-evolution-and-contract-migrations

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill schema-evolution-and-contract-migrations

Installs into the current project.

Summary

Guides agents through schema changes and contract migrations. Use when adding, renaming, removing, or changing columns, data types, nullability, keys, or downstream-facing data contracts.

Files · 1

View on GitHub

SKILL.md

1	# Schema Evolution And Contract Migrations
2
3	## Overview
4
5	Use this skill when a schema change can ripple through pipelines, models, dashboards, or external consumers. It helps agents make schema evolution deliberate, compatible, and recoverable.
6
7	## When to Use
8
9	- changing input or output schemas
10	- renaming or dropping columns
11	- changing data types or nullability
12	- adding keys or changing grain
13	- migrating consumers from an old contract to a new one
14
15	Do not treat schema changes as isolated SQL edits. They are compatibility events.
16
17	## Workflow
18
19	1. Classify the change.
20	Decide whether it is:
21	- additive
22	- backward compatible
23	- breaking
24	- temporary dual-schema support
25
26	2. Map consumers and blast radius.
27	Include:
28	- upstream producers
29	- downstream models
30	- dashboards
31	- APIs or extracts
32	- external consumers
33
34	3. Create the migration path.
35	Options may include:
36	- dual writes
37	- compatibility views
38	- phased deprecation
39	- explicit consumer cutover windows
40
41	4. Validate old and new contracts during the transition.
42
43	5. Remove deprecated paths only after confirmation that consumers moved.
44
45	## Common Rationalizations
46
47	\| Rationalization \| Reality \|
48	\| --- \| --- \|
49	\| "It is just a column rename." \| Renames break dashboards, notebooks, and joins that depend on the old name. \|
50	\| "Consumers will update quickly." \| Some consumers are undocumented or owned by other teams. \|
51	\| "Additive changes are always safe." \| New columns can still change file contracts, schemas, and downstream assumptions. \|
52
53	## Red Flags
54
55	- no consumer inventory exists
56	- breaking changes ship without transition support
57	- type changes are made without data validation
58	- deprecation timing is based on hope instead of confirmation
59
60	## Verification
61
62	- [ ] The change type and compatibility level are classified
63	- [ ] Consumers and blast radius are identified
64	- [ ] A migration and rollback path exists
65	- [ ] Old and new contract behavior are validated during transition

People who liked this also viewed

6 picks

Type

schema-evolution-and-contract-migrations

19stars4forks

View on GitHub

How to install schema-evolution-and-contract-migrations?

vaquarkhan/data-engineering-agent-skills/schema-evolution-and-contract-migrations

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill schema-evolution-and-contract-migrations

Installs into the current project.

Summary

Guides agents through schema changes and contract migrations. Use when adding, renaming, removing, or changing columns, data types, nullability, keys, or downstream-facing data contracts.

Files · 1

View on GitHub

SKILL.md

1	# Schema Evolution And Contract Migrations
2
3	## Overview
4
5	Use this skill when a schema change can ripple through pipelines, models, dashboards, or external consumers. It helps agents make schema evolution deliberate, compatible, and recoverable.
6
7	## When to Use
8
9	- changing input or output schemas
10	- renaming or dropping columns
11	- changing data types or nullability
12	- adding keys or changing grain
13	- migrating consumers from an old contract to a new one
14
15	Do not treat schema changes as isolated SQL edits. They are compatibility events.
16
17	## Workflow
18
19	1. Classify the change.
20	Decide whether it is:
21	- additive
22	- backward compatible
23	- breaking
24	- temporary dual-schema support
25
26	2. Map consumers and blast radius.
27	Include:
28	- upstream producers
29	- downstream models
30	- dashboards
31	- APIs or extracts
32	- external consumers
33
34	3. Create the migration path.
35	Options may include:
36	- dual writes
37	- compatibility views
38	- phased deprecation
39	- explicit consumer cutover windows
40
41	4. Validate old and new contracts during the transition.
42
43	5. Remove deprecated paths only after confirmation that consumers moved.
44
45	## Common Rationalizations
46
47	\| Rationalization \| Reality \|
48	\| --- \| --- \|
49	\| "It is just a column rename." \| Renames break dashboards, notebooks, and joins that depend on the old name. \|
50	\| "Consumers will update quickly." \| Some consumers are undocumented or owned by other teams. \|
51	\| "Additive changes are always safe." \| New columns can still change file contracts, schemas, and downstream assumptions. \|
52
53	## Red Flags
54
55	- no consumer inventory exists
56	- breaking changes ship without transition support
57	- type changes are made without data validation
58	- deprecation timing is based on hope instead of confirmation
59
60	## Verification
61
62	- [ ] The change type and compatibility level are classified
63	- [ ] Consumers and blast radius are identified
64	- [ ] A migration and rollback path exists
65	- [ ] Old and new contract behavior are validated during transition

People who liked this also viewed

6 picks

Type