Working With Dbt Mesh

If you're working with dbt Mesh, this handles the governance layer and cross-project refs that make splitting monolithic projects possible. The core insight is simple: upstream data flows through ref(), not source(), and every cross-project reference needs an explicit project name. It walks through dependencies.yml first, shows you how to disambiguate models with identical names across projects, and covers the four governance primitives (contracts, groups, access modifiers, versions) in adoption order. One critical callout: cross-project refs require dbt Cloud Enterprise, and the skill correctly gates you before writing two-argument refs if you can't confirm the plan level. Useful if you're either setting up mesh from scratch or debugging why a ref() is ambiguous.

skills.sh installs: 892
GitHub stars: 759
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add dbt-labs/dbt-agent-skills --skill working-with-dbt-mesh --agent claude-code

Installs into .claude/skills of the current project.

Files

Working with dbt Mesh

Core principle: In a mesh project, upstream data comes through ref(), not source(). Every cross-project reference requires the project name. When in doubt, read dependencies.yml first.

When to Use

Making a potentially breaking change to a model — renaming, removing, or retyping a column — especially when other models, exposures, or BI tools depend on it. Assess the blast radius before changing it, and reach for model versions rather than editing in place.
Versioning a model (versions:, latest_version, latest_version_pointer, deprecation_date) — this applies in a single project, not just multi-project setups
Working in a dbt project that references models from other dbt projects
Resolving ambiguity when multiple upstream projects have similarly-named models (e.g. multiple stg_ models)
Adding model contracts, access modifiers, or groups
Setting up cross-project references with dependencies.yml
Splitting a monolithic dbt project into multiple mesh projects