Replies: 7 comments 4 replies
-
Example skillFor reference, here is a simple definition for ---
name: list-fqn
description: List fully qualified database relation names (`database.schema.identifier`) for selected dbt nodes.
---
Run `dbt ls --select "<selector>" --output json --output-keys "name database schema alias"`. For each JSON row, print one line per node: `name` plus `<database>.<schema>.<alias>`.It can sit within a folder named $ tree .
.
└── skills
└── list_fqn
└── SKILL.mdIf you use Claude Code, and the skills folder is located at 
|
Beta Was this translation helpful? Give feedback.
-
|
💡 💡 💡 Brainstorming optionsBelow is a completely non-exhaustive brainstorm of various options. Please share any other ideas you have! Skills locationThere’s a discussion here regarding standardizing where skills should live by default, regardless of vendor. In the meantime, we’d still need to make a decision on the standard installation location dbt would default to. Option 1: Top-level $ tree .
.
├── dbt_project.yml
└── skills
├── building-dbt-semantic-layer
│ ├── references
│ │ └── time-spine.md
│ └── SKILL.md
└── some-other-skill
└── SKILL.mdPotentially able to be configured as # dbt_project.yml
skills-paths: [".claude/skills", ".cursor/skills", ...] # just top-level `skills/` by defaultOption 2: Vendor-conventional folders inside the project ( $ tree .
.
├── .claude
│ └── skills
│ ├── building-dbt-semantic-layer
│ │ ├── references
│ │ │ └── time-spine.md
│ │ └── SKILL.md
│ └── some-other-skill
│ └── SKILL.md
└── dbt_project.yml Expressing dependenciesOption 1: New # dependencies.yml
skills:
# GitHub URL (which is not a dbt project)
- git: "https://github.com/dbt-labs/dbt-agent-skills.git"
revision: 0.9.2 # git tag, branch name, or SHA (40-character hash)Option 2: Auto-detect skills inside existing package entries in ConfigurationOption 1: No ability to configure skills within dbt. Option 2: Configure skills under a # dbt_project.yml
skills:
<resource-path>:
+enabled: true | false
+meta: {<dictionary>}
+tags: <string> | [<string>]
+scope: project | global
+agents: <string> | [<string>]
+paths: <string> | [<string>]# _properties.yml
skills:
- name: skill_name
description: <string>
config:
+enabled: true | false
+meta: {<dictionary>}
+tags: <string> | [<string>]Installable contentSkills are standardized across vendors. But some vendors bundle other components together with skills into a “plugin”. For example, Claude plugins also includes custom agents, hooks, MCP servers, and LSP servers. Here’s some options: Option 1: Only install skills (and nothing else) Option 2: Install skills and also the other items (like custom agents, hooks, MCP servers, and LSP servers, etc) Installation locationThere’s not a standardized location where all vendors look for agent skills. In fact, it’s just the opposite — every vendor has a specific location where they look for skills that is separate from other vendors. So dbt would need to know which vendor(s) to install each skill for (and which to not). It would also need to know the scope of the installation (global, user, project, etc). Here’s some options: Option 1: Only install for a single vendor product (i.e. just Copilot or Codex, etc) Option 2: Install for several of the biggest vendor products (Claude, Cursor, Copilot, and Codex) Option 3: Install for every vendor under the sun (Everything! Everywhere! All at once!) Installation behaviorOption 1: Install automatically on Option 2: New dbt flag(s) (like dbt deps --agents claude codexOption 3: New subcommand (like Option 4: No installation by dbt - use something like Vercel skills CLI instead (technically an option but this discussion mainly pre-supposed installation by dbt somehow) Jinja templatingPrefect's Colin enables templating for skills. I’m guessing that we would be adverse to allowing Jinja within skills, but is there any potential value or use-cases we would be cutting off by not allowing it? Option 1: dbt does no rendering of Jinja templates found within Option 2: dbt looks for Jinja within Template: ---
name: deployment-process
description: How to deploy code to staging and production
---
# Deployment
{{ some_dbt_macro('acme/platform', 'docs/DEPLOY.md') }}Output: ---
name: deployment-process
description: How to deploy code to staging and production
---
# Deployment
All changes ship through CI. Push to main, wait for checks, then promote:
1. Open a PR against `main`
2. CI runs tests, linting, and builds a preview
3. Get approval from a code owner |
Beta Was this translation helpful? Give feedback.
-
|
❓❓❓ Open questionsWe've got a lot of open questions we're curious about -- also interested if there's anything not on this list that's on your mind!
|
Beta Was this translation helpful? Give feedback.
-
|
Great discussion. I've been building an agent-driven dbt project (~485 models, 10 source systems, energy domain) and have spent the last few months iterating on exactly this problem — how to make agents effective at real dbt work, not just simple tasks. A few things I've learned that might be useful as you think about the spec. Three tiers, not two The discussion frames skills as community ("how to do the thing") vs. project-specific ("how we do things here"). In practice I've found there are actually three distinct layers:
The first two are about building models correctly. The third is about building the right models. Community skills handle tier 1. Project skills handle tier 2. But the hardest problem — building gold-layer models that accurately represent business logic — requires tier 3, and no community skill can provide that. For any spec work, I think this matters because skills should be designed to reference project context, not embed it. A community skill says "load the source context for this table." The project provides the actual context. That separation is what makes skills composable across projects. Skills without enforcement are just documentation We had well-documented staging conventions in markdown. Agents read them. We still had 56% non-compliance across our staging models — the agents would pattern-match against whatever existing model they happened to read first, which was often an older model that predated the conventions. What actually moved the needle was building a structural validator (a Python script) that checks every staging model for the required CTE pattern, tag schema, surrogate keys, and explicit column lists — and returns agent-readable error messages with specific remediation instructions pointing back to the convention docs. The agent runs this as part of its workflow, reads the structured errors, fixes them, reruns until clean. We went from 56% to 100% compliance on the sources we've applied it to. The insight: skills need to be able to include or reference executable validation, not just instructions. A skill that says "build it this way" is useful. A skill that says "build it this way, then run this validator, and here's what the errors mean" is dramatically more effective. If the spec supports a Context assembly is the hard problem The discussion is mostly about distribution — how to install and manage skills via A project might have 20 installed skills plus hundreds of context files. Without a routing mechanism, the agent either loads everything (blows the context window) or guesses (gets it wrong). We solved this with a decision table pattern — a file that maps request types to deterministic action sequences specifying exactly which files to load in what order: This is progressive disclosure — the agent loads a lightweight router first, then task-specific instructions, then data. Maximum two hops to any piece of information. Token-efficient and deterministic. I don't think dbt needs to solve context assembly in the spec, but it's worth acknowledging that distribution without assembly guidance leaves the hardest part to every individual project. Even a convention for how skills can declare their dependencies on other skills or project context files would go a long way. On @gwenwindflower's point about project scope Strongly agree. The unique value here is dbt managing skills inside dbt projects. Our most valuable skills are deeply project-specific — they reference our source systems, our conventions, our validator scripts, our business entity definitions. Those belong in the repo, versioned with the code they describe. Community skills from One thing I'd add to the |
Beta Was this translation helpful? Give feedback.
-
|
Completely agree with this, and the emphasis on composition+progressive disclosure especially. The default patterns do not really encourage best practices here, you have to do what @rstover-fo described somewhat manually — model providers are not terribly incentivized to help you maximize context efficiency. Also, given how early all these constructs are, the composition and reference patterns are likely to evolve even further. It might not be possible to handle all of this, but I think digging into this area could be another potential advantage here: dbt-managed skill creators could focus on the content, while dbt implements the current best practices for access and composition. If those evolve, the The decision-tree level is probably too deep/specific, but some of the space below that is more generic: see this pattern in how Vercel implements their web-design-guidelines and vercel skills https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals (I believe the skills are linked in there in addition to the context on why they use this approach, but essentially it's: make a bunch of reference material available and then give the agent a compressed index of it). This kind of thing. "You bring the content, we'll give you the best composition pattern, and evolve it as research progresses" is very compelling, particularly if patterns specific to the most effective data modeling context emerge. |
Beta Was this translation helpful? Give feedback.
-
|
It is definitely a work in progress - will report back - unless things change by the time I get to really experiment. Even with some of this implemented, my context windows rapidly close (outside of playing around with the new 1M context windows) |
Beta Was this translation helpful? Give feedback.
-
To me, the ✨unique advantage✨ of dbt-managed skills is based on dbt's ability to serve both deeply technical and less technical users equally. The latter are less likely to spend lots of time thinking about their skill library and agent configs, so your points around onboarding/setup feel the strongest to me: this creates a way for the former to provide easy, accessible consistency for the latter — trés dbt! With that in mind, here are my thoughts on how I would want to see it work, based on some of your questions:
One interesting way to manage this would be a installing dbt skills into a global store (like My impression of the vibes is that users are yearning for more unity/stability/simplicity in the rapidly shifting world of agent configs, so adding another potential source to the mix that works outside the project and requires more config files and overrides feels more complex, while a simple system that works inside the world of dbt projects based on a new deps YAML key and does not require users to think about the gnarly web of agent configs is appealing. Essentially — dbt managing skills in dbt projects feels good, but dbt managing skills outside of dbt projects feels like it doesn't add unique advantage and does add complexity and surface for problems (to me). |
Beta Was this translation helpful? Give feedback.
-
|
Y'all should name this "cbt": Context Build Tool |
Beta Was this translation helpful? Give feedback.
-
|
At last a single acronym we could adopt with no potential for confusion |
Beta Was this translation helpful? Give feedback.
-
Can you please elaborate on how you made the jump from "quickly onboard agents" to "agent skills"? |
Beta Was this translation helpful? Give feedback.
-
|
Great question. Other options considered:
Agents.md is great for single repos, but the lack of composability and progressive disclosure more or less makes it a no go for this since we're going to need to include much more context than we can reasonably put in an agents.md. Building a dbt first context management spec was compelling. Could this just live in existing dbt constructs? Could we have something lightweight (text only dbt models that can get chained together to build the prompts). But cross compatibility is critical here. We need to make it so that the context you build and use in dbt is accessible to other agents. In that world, skills look like the best pick. There's also a lot of great discussion happening around how to extend agent skills - most of the things we'd want to see (versioning, reffing etc) are already being discussed by the team maintaining skills. Anything else on your mind that we should be looking at? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Background
Agents are increasingly being used alongside dbt to build, test, and manage data projects. Agent skills are increasingly being used to transform generalist coding agents into agents with real depth of expertise into dbt (see dbt agent skills). Skills are instructions that tell agents how to do something. Since they're text-based with minimal syntax requirements, anyone on a team can author them. Once written, those skills can be picked up by tools like Claude Code, Cursor, Copilot, Codex, and others.
Some of these skills are very dbt-specific, teaching agents the ins and outs of the dbt framework and language, capabilities like "how to add a unit test" or "how to troubleshoot a failing build". Others are more general but still essential to doing dbt work effectively. This includes things like understanding the data context surrounding a dbt project, knowing team development conventions, or navigating the structure of an org-wide mesh deployment. In practice, we expect people to accumulate skills that range from tightly coupled to the dbt framework to broader development workflows.
We believe this is going to accelerate. Over the coming months, more and more people will be using agents with dbt, and those agents will rely on multiple interacting skills — some for one specific dbt project, some shared across an organization, some published to the community.
👉 The question we're exploring here is whether dbt itself should provide a native way to manage these skills. 👈
dbt could facilitate using agent skills and sharing amongst dbt practitioners by extending the dbt language spec, dbt Package Hub, and dbt commands to be aware of Agent Skills. The rest of this Discussion explores different ideas of how we could do that.
Why dbt? Why not just use existing skill distribution tools?
This is the most important question to address up front.
Skill installers like the Vercel Skills CLI and Tessl already exist. If those are strictly superior for our use case, dbt should probably stay out of it. So what could dbt offer beyond what's already available?
The short hypothesis is making skills feel native and organic to dbt.
A few things we think matter:
dependencies.ymlthe same way you declare packages, anddbt depswould handle the rest.dbt depsand get everything they need — packages and skills. No separate orchestration step, no additional tooling to learn. That's a meaningful reduction in friction. (Note: you'd still need to install your coding agent separately —dbt depswould give you the skills half, not the agent half.)If, after reading all of this, your reaction is "NPX skills are plenty good enough and dbt shouldn't bother" — that's a completely valid outcome of this discussion. We want to hear if that's the case!
A note on pace
Historically, the dbt language spec has evolved deliberately, and there's been a high bar to add new features.
But today's technologies are moving faster than at any time in history. Even though skills as a concept is only a few months old, we are already seeing significant adoption among our user base. If we wait for the kind of certainty we'd normally want before changing the language spec, we risk leaving friction in the workflows people are already adopting.
We're thinking it may be worth adding skills support so we can iterate and learn (possibly experimentally, or behind a feature flag). We're not fully convinced yet, but we think we're closer than we expected to be. This discussion is a big part of how we figure that out, together.
Problems to solve for
For agent skills that are specific to dbt:
Ultimately the question boils down to two questions:
Potential solution
Today, dbt packages are shareable, discoverable, and installable via the dbt Package Hub at hub.getdbt.com. We could solve all three problems above by extending the dbt language spec, dbt Package Hub, and dbt commands to be aware of Agent Skills.
dbt could:
Details to consider
Potential spec
Here’s a potential spec to add a new
skills:top level key intodependencies.yml:A simple example:
More examples with different skill locations and install methods
To install skills:
To disable installation of skills:
Conclusion
It’s a real open question how (and if!) we should natively support skills as part of the dbt language spec. We’re looking forward to hearing from the Community and integrating your thoughts into the ultimate decision.
Beta Was this translation helpful? Give feedback.
All reactions