Use data-contract

Draft a data contract for a dataset, table, or event stream consumed by others

Draft a data contract for a dataset, table, or event stream consumed by others — schema with per-field semantics and units, measurable quality SLAs (freshness, completeness, validity, distribution), a schema-evolution policy that says what breaks consumers, a named owner, and PII classification.

Reach for it when the user is publishing a dataset/table/topic other teams depend on, needs a data contract, or wants to stop downstream pipelines breaking on silent schema or quality changes.

Install it

npx skilldrop-cli install data-contract                 # Claude Code, your user folder
npx skilldrop-cli install data-contract --project       # Claude Code, this repo
npx skilldrop-cli install data-contract --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Solution architect pack: --pack solution-architect installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Write a data contract for this table"
• "We have downstream consumers of this dataset — define the contract and its SLAs"
• "Define the schema and quality guarantees for this event stream"
• "What should our producers promise consumers about this data?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Draft the OpenAPI spec for our REST API"
• "Design the database schema and indexes from our access patterns"
• "Write the product requirements document"

If another skill answers instead, ask for this one by name: "use data-contract".

Check what you get

A good result:

• Every field has a meaning and a unit/allowed-values, not just a type. The cents-vs-dollars class of bug is designed out at contract time.
• Every quality SLA has a threshold, a check, and a breach action. "High quality" is not an SLA; "freshness < 6h, checked hourly, breach pages the owner" is.
• The evolution policy names the silent killer — meaning-change-under-stable-name — as breaking. Most contracts miss it and most data incidents are it.
• Consumers are enumerated, so "breaking" is defined and notifications have an address. Unknown consumers are flagged, not assumed away.
• The asset has a named owner and per-field classification. No owner, no contract.
• Existing-asset contracts mark aspirational vs met. Claiming a freshness SLA the pipeline doesn't hit is how the contract loses its authority on day one.

Use something else when

• A synchronous REST/RPC API or webhook — that's api-contract-draft
• The physical schema migration (expand/backfill/contract) — that's migration-plan
• System-wide NFRs for a service — that's nfr-spec; this is one data asset's guarantee
• A private dataset with exactly one consumer inside the same team — a comment in the code may suffice

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: api-contract-draft, migration-plan, nfr-spec

Edit this page on GitHub · View source