dbt-agent-skills: Packaged dbt Knowledge for AI Coding Agents
A curated collection of Agent Skills for working with dbt, to help AI agents understand and execute dbt workflows more effectively.
At a glance
- What is it?
- dbt-labs/dbt-agent-skills is an Apache-2.0 collection of Agent Skills that load into a compatible AI agent so it can build dbt models, write unit tests, and run CLI commands without being told the conventions. The value is real but conditional: it depends on your agent supporting the Agent Skills format and on the skills matching your dbt version.
- Who is it for?
- Adopt dbt-agent-skills if your team already drives dbt work through an Agent Skills compatible client and you want the agent to follow dbt conventions rather than improvise them. Skip it if your agent does not implement the format, or if you cannot pin the installed skills to the dbt version your project actually runs.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Agents That Do Not Know dbt Conventions
An AI agent asked to add a dbt model will usually produce something plausible and wrong. It may invent a config block, guess at a selector syntax, or write a test that does not match how the project already does tests. The failure is not the model's reasoning. It is missing context about dbt's file layout, command flags, and testing idioms. dbt-agent-skills addresses that gap by shipping the context as files the agent loads on its own. The README describes these as folders of instructions, scripts, and resources that agents discover and use. The target user is an analytics engineer or data platform engineer who already uses an AI coding agent and wants its dbt output to follow conventions instead of being corrected by hand. It is not a dbt plugin, not a CLI extension, and not something that runs on its own. Nothing happens until an agent reads the skill files.
How a Skill Loads Without You Invoking It
The README is explicit that these skills are not slash commands or user-invoked actions. Once installed, the agent loads the relevant skill when the prompt matches its use case, and the user just describes the need in natural language. That is the whole mechanism: prompt matching against skill metadata, then the skill body enters the agent's context. The repository links to Claude's skill invocation control documentation for the details of who invokes a skill, so the matching behaviour is a property of the client, not of this repository. That matters for evaluation. Two agents that both claim Agent Skills support can behave differently on the same prompt, because the trigger logic lives in the client. The repository also follows the Agent Skills specification, which is what makes one skill folder portable across products. The layout splits into a dbt plugin and a dbt-migration plugin, with the migration skills described as one-off use rather than something loaded every session.
What Is Actually in the Two Plugin Groups
The dbt group covers ten named skills. using-dbt-for-analytics-engineering builds and modifies models, debugs errors, explores sources, and writes tests. adding-dbt-unit-test targets test-driven development for models. maintaining-dbt-documentation audits model and column doc coverage and drafts missing descriptions in the project's own style, which is a narrower and more interesting claim than generic doc generation. building-dbt-semantic-layer and answering-natural-language-questions-with-dbt cover MetricFlow metrics, dimensions, and semantic models. working-with-dbt-mesh handles contracts, access, groups, versions, and cross-project refs. The remaining four are operational: troubleshooting-dbt-job-errors, configuring-dbt-mcp-server, fetching-dbt-docs, and running-dbt-commands. The dbt-migration group holds three: migrating-dbt-core-to-v2, migrating-dbt-project-across-platforms, and upgrading-dbt-core, the last scoped to dbt-core v1 projects from 1.3 to 1.7. The split is deliberate. Migration knowledge is large and rarely relevant, so keeping it in a separate plugin avoids paying its context cost on every session.
Installing via Claude Code, the Skills CLI, or Tessl
Claude Code uses a marketplace flow. The README gives three commands: /plugin marketplace add dbt-labs/dbt-agent-skills, then /plugin install dbt@dbt-agent-marketplace, and optionally /plugin install dbt-migration@dbt-agent-marketplace. The README notes the migration install is typically a one-off and not needed for every session. For other clients, the Vercel Skills CLI is the documented path and reportedly supports 30+ agents including Cursor, Cline, and GitHub Copilot. The commands are npx skills add dbt-labs/dbt-agent-skills --list to preview, then npx skills add dbt-labs/dbt-agent-skills to install everything. Scoped installs are available: append /skills/dbt or /skills/dbt-migration to the repository path, or pass --skill using-dbt-for-analytics-engineering for one skill. The --global flag stores skills in ~/.<agent>/skills/ so they are available across projects. Updates go through npx skills check and npx skills update. Tessl offers a third path with tessl install dbt-labs/dbt-agent-skills, a --skill flag, and a github: prefix for direct installs. Note that the README does not document a version pinning flag for any of these three installers.
Prerequisites and the Version Assumption Nobody States
Most skills assume dbt is installed and configured, that a dbt project with dbt_project.yml exists, and that the user knows basic dbt concepts. Two skills, fetching-dbt-docs and configuring-dbt-mcp-server, work without an existing project. Those prerequisites are reasonable, but they hide the sharper question. Nothing in the README says which dbt versions the skills target. The migration skill upgrading-dbt-core covers dbt-core 1.3 through 1.7, and migrating-dbt-core-to-v2 implies a v2 target, so the collection clearly tracks recent dbt releases. For a team on an older dbt-core, the analytics engineering skills could describe config syntax or command flags that do not exist in that version, and the agent would apply them confidently. This is the main risk of instruction files that load silently: a wrong instruction looks exactly like a right one from inside the agent's context. The README does not offer a compatibility matrix, so the only reliable check is reading the skill files against your installed dbt version.
A Limitation Worth Taking Seriously: No Release History
The repository has no releases retrieved and no version tags in the supplied material. Installation is from the default branch through three different installers, and the README's update commands (npx skills check, npx skills update) pull whatever is current. For a set of files that change an agent's behaviour, that is a weak supply chain. A skill edit lands in your next session with no changelog entry to review. The repository does include an evals directory with an A/B testing tool to compare skill variations, per evals/README.md, which is a genuine quality signal for contributors. It does not solve the consumer-side problem of knowing what changed between two installs. Teams that need reproducible agent behaviour should treat this as a moving dependency and snapshot the installed skill folders into their own repository rather than relying on --global installs. The README does not describe a snapshot or lock workflow.
How This Differs from Prompt Files and MCP Servers
The closest alternative most teams already have is a checked-in instruction file, such as a CLAUDE.md or .cursorrules in the repository. The difference is scope and packaging. A project instruction file is written by the team, lives beside the code, and covers whatever the team remembers to write down. dbt-agent-skills is written upstream by dbt-labs, covers ten analytics topics plus three migration topics, and installs at the agent level rather than the repository level. The trade-off runs both ways. Upstream skills carry dbt's own conventions and stay current with dbt releases, but they cannot know your naming scheme, your folder structure, or your review rules. A project instruction file knows all of that and goes stale quietly. A second alternative is the dbt MCP server, which this repository has a skill for configuring. MCP gives the agent live access to a dbt environment; skills give it procedural knowledge. They solve different problems and are not substitutes. If your agent can only use one, choose based on whether the failure you see is wrong knowledge or missing access.
Licence, Maintenance, and What to Verify First
The repository is Apache-2.0, which permits commercial use, modification, and redistribution provided the licence and notices are preserved, and it includes an explicit patent grant. The README's licence section only says to see LICENSE for details, so read that file for the authoritative terms rather than relying on the repository metadata. For a collection of instruction files, the practical licence question is different from a library: you are redistributing text that shapes agent behaviour, so if you fork skills for internal use, keep the attribution intact. Maintenance cost is lower than a dependency you compile, but it is not zero. The skills reference dbt features that move, and the migration skills are tied to specific version ranges. The realistic ongoing cost is a periodic read of the skill files against your dbt version, plus the update commands when you want upstream changes. The repository has no releases, so there is no changelog to do that reading for you. Start with npx skills add dbt-labs/dbt-agent-skills --list to see what would be installed before installing anything.
Editorial conclusion
Adopt dbt-agent-skills if your team already drives dbt work through an Agent Skills compatible client and you want the agent to follow dbt conventions rather than improvise them. Skip it if your agent does not implement the format, or if you cannot pin the installed skills to the dbt version your project actually runs. Before rolling it out, run the list command for your install path, read the SKILL.md of using-dbt-for-analytics-engineering and running-dbt-commands, and confirm in your own project that the agent's generated commands match your dbt version and selectors.
Community notes