data-sharing-and-publishing-contracts

Name: data-sharing-and-publishing-contracts
Author: vaquarkhan

19stars4forks

How to install data-sharing-and-publishing-contracts?

vaquarkhan/data-engineering-agent-skills/data-sharing-and-publishing-contracts

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-sharing-and-publishing-contracts

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Data Sharing And Publishing Contracts
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- publishing curated tables or marts
10	- sharing extracts or files with other teams or partners
11	- exposing governed data through APIs or reverse ETL
12	- modifying an existing consumer-facing dataset
13
14	Do not publish widely-used data with implicit contracts.
15
16	## Workflow
17
18	1. Define the published contract.
19	Include:
20	- owner
21	- audience
22	- schema
23	- grain
24	- delivery method
25	- freshness and retention expectations
26
27	2. Identify compatibility and versioning needs.
28
29	3. Define access and usage boundaries.
30	Capture:
31	- allowed consumers
32	- privacy constraints
33	- SLA expectations
34	- communication path for changes
35
36	4. Validate publish readiness before release.
37
38	5. Document change policy.
39	Consumers should know what can change, how they will be notified, and how long deprecated behavior lasts.
40
41	## Common Rationalizations
42
43	\| Rationalization \| Reality \|
44	\| --- \| --- \|
45	\| "It is just one extract for another team." \| One-off exports often become critical dependencies. \|
46	\| "Consumers can ask if something changes." \| Many consumers only discover changes after failure. \|
47	\| "The schema tells them everything they need." \| Delivery timing, freshness, retention, and ownership matter too. \|
48
49	## Red Flags
50
51	- published outputs have no owner
52	- delivery or freshness expectations are missing
53	- breaking changes are shipped without versioning or notice
54	- access boundaries are unclear for shared datasets
55
56	## Verification
57
58	- [ ] The publish contract covers audience, schema, delivery, and freshness
59	- [ ] Ownership and communication path are defined
60	- [ ] Compatibility and access expectations are explicit
61	- [ ] Release readiness is validated before consumers depend on it

People who liked this also viewed

6 picks

Type

data-sharing-and-publishing-contracts

19stars4forks

View on GitHub

How to install data-sharing-and-publishing-contracts?

vaquarkhan/data-engineering-agent-skills/data-sharing-and-publishing-contracts

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-sharing-and-publishing-contracts

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Sharing And Publishing Contracts
2
3	## Overview
4
5	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.
6
7	## When to Use
8
9	- publishing curated tables or marts
10	- sharing extracts or files with other teams or partners
11	- exposing governed data through APIs or reverse ETL
12	- modifying an existing consumer-facing dataset
13
14	Do not publish widely-used data with implicit contracts.
15
16	## Workflow
17
18	1. Define the published contract.
19	Include:
20	- owner
21	- audience
22	- schema
23	- grain
24	- delivery method
25	- freshness and retention expectations
26
27	2. Identify compatibility and versioning needs.
28
29	3. Define access and usage boundaries.
30	Capture:
31	- allowed consumers
32	- privacy constraints
33	- SLA expectations
34	- communication path for changes
35
36	4. Validate publish readiness before release.
37
38	5. Document change policy.
39	Consumers should know what can change, how they will be notified, and how long deprecated behavior lasts.
40
41	## Common Rationalizations
42
43	\| Rationalization \| Reality \|
44	\| --- \| --- \|
45	\| "It is just one extract for another team." \| One-off exports often become critical dependencies. \|
46	\| "Consumers can ask if something changes." \| Many consumers only discover changes after failure. \|
47	\| "The schema tells them everything they need." \| Delivery timing, freshness, retention, and ownership matter too. \|
48
49	## Red Flags
50
51	- published outputs have no owner
52	- delivery or freshness expectations are missing
53	- breaking changes are shipped without versioning or notice
54	- access boundaries are unclear for shared datasets
55
56	## Verification
57
58	- [ ] The publish contract covers audience, schema, delivery, and freshness
59	- [ ] Ownership and communication path are defined
60	- [ ] Compatibility and access expectations are explicit
61	- [ ] Release readiness is validated before consumers depend on it

People who liked this also viewed

6 picks

Type