Data Contract Skill

Most data outages are a producer changing a column without telling anyone downstream. A data contract fixes that: it's an explicit, versioned agreement on the schema, semantics, and quality guarantees of a dataset/event/stream, with an owner and a breaking-change policy. This skill writes one, so producers and consumers share a single source of truth and changes can't silently break pipelines.

Required Inputs

Ask for these only if they aren't already provided:

• The data asset — the table, event, topic, or API, and what it represents.
• Producer & consumers — who owns it, who depends on it.
• Schema — fields, types, and which are required; the semantics of the tricky ones.
• Quality expectations — freshness (how current), completeness, valid ranges, uniqueness.

Output Format

Data Contract: [asset] v[x.y]

Producer (owner): [team] · Consumers: [teams/systems] · Status: active

1. Schema — every field: name · type · required? · description/semantics · constraints (enum, range, format).

field	type	required	constraint	meaning

2. Semantics — the non-obvious meanings: timezone of timestamps, currency/units, what null means, how late-arriving data is handled, the grain/uniqueness.

3. Quality SLAs — the guarantees, measurable: freshness (e.g. updated by 06:00 UTC daily), completeness (no missing required fields), validity (values in range), uniqueness (PK unique). These are what consumers can rely on.

4. Ownership & support — who owns it, where to raise issues, on-call/response expectations.

5. Versioning & breaking changes — semver for the schema; what counts as breaking (removing/renaming a field, tightening a type, changing semantics) vs. (adding optional fields); deprecation window before a breaking change ships.