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. Use 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.
In Claude Code, with the solution-architect plugin installed, invoke it as:
/solution-architect:data-contract
Try it
A realistic prompt from the skill's acceptance evals:
We publish an `orders_daily` table that three downstream teams consume. Write the data contract.
What a good result looks like
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.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 67% of its checks, against 40% without it, and a blind judge preferred it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Every field carries a meaning plus a unit or allowed-values, not merely a type — the cents-vs-dollars class of bug is designed out
Every quality SLA states a threshold, a check, and a breach action; 'high quality' is rejected as an SLA
The evolution policy explicitly names meaning-change-under-a-stable-name as a breaking change
The contract names the owner and the consumers it is a promise to
Freshness, completeness, validity, and distribution are each addressed or explicitly marked not-applicable
Saves data-contract.yaml, which parses as YAML, and keeps the open issues in the reply to a few lines as asked
Resolves or flags the weight unit conflict: the notes say kg, but the schema comment and the sample values point to tonnes
Flags that moisture_pct in the sample rows mixes percentages (such as 14.2) with fractions (such as 0.138), and sets a check that would catch it
Classifies farmer_name and farmer_phone as personal data, despite the notes saying the table holds none
Does not promise 15-minute freshness, noting that the table is loaded nightly from the weighbridge export
Does not name an owner; leaves ownership as an open issue for the two teams to settle
Does not invent columns, consumers or allowed values that are not in the supplied files
Delivers bullets ready to send, without asking questions first
Asks the bus company to keep the listed column names and order the same, and to give notice before changing them
Sets an expected format for at least one field that would break the alerts, such as pickup time (for example 24-hour HH:MM)
Raises whether Driver First Name needs to be shared, since it is personal information about the drivers
Does not invent columns, penalties, legal terms or deadlines not in the message; any notice period is offered as a suggestion
Keeps to a few bullets in plain language a non-technical bus company would follow
When it should and shouldn't activate
Should activate:
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?
Should leave to another skill:
Draft the OpenAPI spec for our REST API
Design the database schema and indexes from our access patterns