Claude Skill

data-governance

Establishes ownership, definitions, quality, access, and lineage for the organization's data. Use this when metrics disagree between teams, when nobody knows which dataset is authoritative, when setting up data ownership or access policy, when data quality is unreliable, or befor

LLM Mart · 0 points · 16 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download cbrock84-headcount-plugins_data-analytics_skills_data-governance-98d1c17.zip · 2 KB

cbrock84/headcount 1633 245 forks MIT Updated 7d ago

Part of cbrock84/headcount — 160 skills

Install

skills CLI npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/data-analytics/skills/data-governance

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart

Git git clone https://github.com/cbrock84/headcount.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Data governance

Governance has a reputation for bureaucracy because it is usually implemented as approval queues. Done properly it is the opposite: it makes data usable without asking anyone.

Start with definitions, not policy

The highest-value governance artifact is a metric dictionary. For each business metric:

The plain-language definition — what it counts, and what it deliberately excludes.
The computation, unambiguously: source table, filters, time grain, timezone.
The owner — a person who decides when it is disputed.
Known caveats — when it is misleading, and what changed historically.

Most metric disputes dissolve once both parties read the same definition and discover they were measuring different things. Almost none require a policy.

Watch the ones that look obvious. "Active customer," "revenue," and "signup" each have half a dozen defensible definitions, and the ambiguity surfaces at the worst moment.

Ownership

Every dataset has a named owner accountable for its quality and access — a person, not a team. Unowned datasets decay, and nobody notices until a decision is made on stale data.

The owner should sit with the business meaning, not with the pipeline. The team that generates the data understands what it means; the platform team understands how it moves.

Quality, measured rather than asserted

Test data like code, continuously, and alert on failures:

Freshness — did it arrive when expected?
Volume — is the row count within its normal range? A silent drop to zero is the classic failure.
Uniqueness and nullity on key fields.
Referential integrity across joins.
Distribution — has the shape shifted in a way nothing explains?

The point is finding breakage before a decision is made on it. A pipeline that fails loudly is better than one that silently produces yesterday's numbers.

Access

Default to open for internal, non-personal data. Restrictive-by-default drives the shadow spreadsheet layer, which is genuinely less safe than a governed warehouse.

Personal, financial, and regulated data are the exception: least privilege, purpose stated, reviewed periodically, with Legal & Risk involved on anything with a lawful-basis question.

Lineage

Know where a number came from and what feeds it. Without lineage, you cannot answer the two questions that matter during an incident: what broke upstream, and what downstream is now wrong.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Never

Let two systems each claim to be the source of truth for the same fact.
Fix a data-quality issue in a dashboard. Fix it upstream or it recurs in every other consumer.
Retire a dataset because it looks unused — you cannot see every consumer. Deprecate, announce, then remove.

Files (headcount)

references

sources.md 1.7 KB

# Sources — `data-analytics:data-governance`

<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->

Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.

## California Consumer Privacy Act — Attorney General

California Office of the Attorney General · US-CA · public domain — quote freely

<https://oag.ca.gov/privacy/ccpa>

**Authoritative for:** The largest US state privacy regime, and the template several other states followed. Start here before generalizing about 'US state privacy law', which is not one thing.

## European Data Protection Board guidelines and recommendations

EDPB · EU · free to use with attribution — credit the publisher

<https://www.edpb.europa.eu/our-work-tools/general-guidance/guidelines-recommendations-best-practices_en>

**Authoritative for:** How supervisory authorities actually read the GDPR — lawful basis, transfers, legitimate interest balancing — which is where a plain reading of the regulation stops being enough.

## Regulation (EU) 2016/679 — GDPR

Publications Office of the European Union · EU · free to use with attribution — credit the publisher

<https://eur-lex.europa.eu/eli/reg/2016/679/oj>

**Authoritative for:** The operative text of the GDPR. EU legal texts are reusable with attribution under the Commission's reuse decision, so this is quotable where a national summary is not.

---

Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

SKILL.md 3.4 KB

---
name: data-governance
description: Establishes ownership, definitions, quality, access, and lineage for the organization's data. Use this when metrics disagree between teams, when nobody knows which dataset is authoritative, when setting up data ownership or access policy, when data quality is unreliable, or before opening a dataset to a wider audience.
---

# Data governance

Governance has a reputation for bureaucracy because it is usually implemented as approval queues.
Done properly it is the opposite: it makes data usable without asking anyone.

## Start with definitions, not policy

The highest-value governance artifact is a metric dictionary. For each business metric:

- The **plain-language definition** — what it counts, and what it deliberately excludes.
- The **computation**, unambiguously: source table, filters, time grain, timezone.
- The **owner** — a person who decides when it is disputed.
- **Known caveats** — when it is misleading, and what changed historically.

Most metric disputes dissolve once both parties read the same definition and discover they were
measuring different things. Almost none require a policy.

Watch the ones that look obvious. "Active customer," "revenue," and "signup" each have half a dozen
defensible definitions, and the ambiguity surfaces at the worst moment.

## Ownership

Every dataset has a named owner accountable for its quality and access — a person, not a team.
Unowned datasets decay, and nobody notices until a decision is made on stale data.

The owner should sit with the business meaning, not with the pipeline. The team that generates the
data understands what it means; the platform team understands how it moves.

## Quality, measured rather than asserted

Test data like code, continuously, and alert on failures:

- **Freshness** — did it arrive when expected?
- **Volume** — is the row count within its normal range? A silent drop to zero is the classic
  failure.
- **Uniqueness and nullity** on key fields.
- **Referential integrity** across joins.
- **Distribution** — has the shape shifted in a way nothing explains?

The point is finding breakage before a decision is made on it. A pipeline that fails loudly is
better than one that silently produces yesterday's numbers.

## Access

Default to open for internal, non-personal data. Restrictive-by-default drives the shadow spreadsheet
layer, which is genuinely less safe than a governed warehouse.

Personal, financial, and regulated data are the exception: least privilege, purpose stated, reviewed
periodically, with Legal & Risk involved on anything with a lawful-basis question.

## Lineage

Know where a number came from and what feeds it. Without lineage, you cannot answer the two
questions that matter during an incident: what broke upstream, and what downstream is now wrong.

## Sources

`references/sources.md` in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.

## Never

- Let two systems each claim to be the source of truth for the same fact.
- Fix a data-quality issue in a dashboard. Fix it upstream or it recurs in every other consumer.
- Retire a dataset because it looks unused — you cannot see every consumer. Deprecate, announce,
  then remove.