data-contract
GitHub用于定义数据集或API的生产者与消费者之间的数据契约，明确模式、语义及质量SLA。防止因模式变更导致下游管道静默断裂，确保双方拥有统一事实来源并规范版本管理与变更流程。
触发场景
安装
npx skills add mohitagw15856/pm-claude-skills --skill data-contract -g -y
SKILL.md
Frontmatter
{
"name": "data-contract",
"description": "Define a data contract between a producer and consumers of a dataset\/event\/API. Use when asked to write a data contract, define a schema agreement, set data SLAs, or stop a producer from silently breaking downstream consumers. Produces a contract — schema with types & constraints, semantics, quality SLAs (freshness\/completeness\/validity), ownership, versioning & breaking-change policy, and a change process."
}
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. non-breaking (adding optional fields); deprecation window before a breaking change ships.
6. Change process — how a change is proposed, who must sign off (affected consumers), and the notice period.
Quality Checks
- Every field has a type, required-flag, and clear semantics (esp. timezone/units/null meaning)
- Quality SLAs are measurable (a number/time), not "should be fresh"
- Breaking vs. non-breaking changes are explicitly defined
- There's a deprecation window and a sign-off process for breaking changes
- An owner and an issue/escalation path are named
Anti-Patterns
- Do not leave semantics implicit — undocumented timezone/units/null handling is the #1 silent data bug
- Do not write vague SLAs — "fresh and accurate" is unenforceable; give times and thresholds
- Do not allow breaking changes without notice — a deprecation window + consumer sign-off is the whole point
- Do not skip ownership — an unowned dataset has no one to hold to the contract
- Do not version informally — schema changes need semver so consumers know what broke
Based On
Data-contract practice — schema + semantics + measurable quality SLAs, semantic versioning, and producer/consumer change governance.
版本历史
- a38bc30 当前 2026-07-05 11:15
