Data sharing and publishing contracts
Skill vaquarkhan/data-engineering-agent-skills/skills/data-sharing-and-publishing-contracts
Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-sharing-and-publishing-contractsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guides agents through publishing data products for internal or external consumers. Use when sharing tables, files, extracts, APIs, or reverse-ETL-ready outputs that require stable contracts, ownership, and communication.
SKILL.md
2.2 KB, as published. Nobody here has run it
Data Sharing And Publishing Contracts
Overview
Use this skill when data leaves the producing team and becomes a product for other teams, systems, or partners. It helps agents define stable publish contracts with ownership, compatibility, and operational expectations.
When to Use
- publishing curated tables or marts
- sharing extracts or files with other teams or partners
- exposing governed data through APIs or reverse ETL
- modifying an existing consumer-facing dataset
Do not publish widely-used data with implicit contracts.
Workflow
-
Define the published contract. Include:
- owner
- audience
- schema
- grain
- delivery method
- freshness and retention expectations
-
Identify compatibility and versioning needs.
-
Define access and usage boundaries. Capture:
- allowed consumers
- privacy constraints
- SLA expectations
- communication path for changes
-
Validate publish readiness before release.
-
Document change policy. Consumers should know what can change, how they will be notified, and how long deprecated behavior lasts.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "It is just one extract for another team." | One-off exports often become critical dependencies. |
| "Consumers can ask if something changes." | Many consumers only discover changes after failure. |
| "The schema tells them everything they need." | Delivery timing, freshness, retention, and ownership matter too. |
Red Flags
- published outputs have no owner
- delivery or freshness expectations are missing
- breaking changes are shipped without versioning or notice
- access boundaries are unclear for shared datasets
Verification
- The publish contract covers audience, schema, delivery, and freshness
- Ownership and communication path are defined
- Compatibility and access expectations are explicit
- Release readiness is validated before consumers depend on it