datahub skills

The judgment, separated from the code

A tool is a discrete action. A skill is the judgment needed to chain actions into an answer that is right rather than merely plausible. DataHub's registry covers lineage, search, enrichment, quality and setup. None of them cover the question this project is about, so this one was written in the registry format and carries what the build cost to learn.

format SKILL.md, registry schema
tools DataHub CLI and MCP only
failure modes encoded 4
depends on Ariadne no

the gap it fills

Why a sixth skill

The existing skills are good and general. The moment a model is on one end of the question, a generic lineage walk starts producing confident wrong answers, because four things about ML lineage are different and each fails silently.

existing skill	covers	where it stops
`datahub-lineage`	upstream, downstream, impact, root cause between tables	does not cross into models, or read deployment stage
`datahub-search`	finding entities, ownership, metadata	sibling resolution is not its problem
`datahub-quality`	assertions, unhealthy assets, incidents	quality is about the data, not about what a model learned
`datahub-enrich`	tags, terms, owners, descriptions	writes metadata rather than reasoning about it

The skill is explicit about its own boundary. If nothing downstream is a model, it tells the agent to use /datahub-lineage instead, because that is simpler and correct.

what it encodes

Four ways to be wrong, written down

Tags live on the sibling you did not walk dbt holds the governance tags, the warehouse entity holds none, and traversal returns the warehouse one. Ask it whether a column is protected and the answer is no. Nothing errors. A check written this way reports all clear forever.
Filtering a column walk by column name drops the origin A warehouse renames as it cleans. The graph has already scoped the walk to that column's lineage, so every node it returns is on the path by construction, and a name check can only lose the rename.
Column edges stop at the feature table dbt emits column level edges. ML platforms emit a table level edge into the model, because a training run consumes a table. A walk that does not cross that boundary reports the column reaches nothing, which is the exact question asked.
The environment in a urn is not a deployment status PROD is the fabric the entity lives in. Read the stage from the registry, where a promotion actually happened, or every archived experiment counts as live.

the file

Frontmatter, and the shape of the workflow

---
name: datahub-ml-impact
description: |
  Use this skill when a change to a table or column needs to be judged against
  the ML models downstream of it, or when a deployed model has changed behaviour
  and the cause has to be found in the warehouse. Triggers on: "what models does
  this column reach", "is this feature in a deployed model", "did a protected
  attribute get into the model", "why did this model change" ...
user-invocable: true
min-cli-version: 1.5.0.1rc1
allowed-tools: Bash(datahub *)
---

Step 1  Find the entity, and pick the right sibling
Step 2  Walk the column, not the table
Step 3  Cross the boundary into the model
Step 4  Separate deployed from merely registered
Step 5  Say what the change means, not only what it touches

It ends with a checklist the agent runs against its own answer, including the one that matters most: if nothing was found, can you say what you looked at, so that "no impact" is a result rather than a silence.

installing

It runs on DataHub's own tools

The workflow uses the DataHub CLI and the MCP server and nothing from this repository, so it stands alone. The implementation of the same workflow, if you want to read one, is tools/blast.py and tools/rootcause.py.

npx skills add datahub-project/datahub-skills
npx skills add cnpierrepapi/ariadne --path skills

the same workflow as a run, unedited