running-dbt-commands
Formats and executes dbt CLI commands, selects the correct dbt executable, and structures command parameters. Use when running models, tests, builds, compiles, or show queries via dbt CLI. Use when unsure which dbt executable to use or how to format command parameters.
Best use case
running-dbt-commands is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Formats and executes dbt CLI commands, selects the correct dbt executable, and structures command parameters. Use when running models, tests, builds, compiles, or show queries via dbt CLI. Use when unsure which dbt executable to use or how to format command parameters.
Teams using running-dbt-commands should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/running-dbt-commands/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How running-dbt-commands Compares
| Feature / Agent | running-dbt-commands | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Formats and executes dbt CLI commands, selects the correct dbt executable, and structures command parameters. Use when running models, tests, builds, compiles, or show queries via dbt CLI. Use when unsure which dbt executable to use or how to format command parameters.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Running dbt Commands
## Preferences
1. **Use MCP tools if available** (`dbt_build`, `dbt_run`, `dbt_show`, etc.) - they handle paths, timeouts, and formatting automatically
2. **Use `build` instead of `run` or `test`** - `test` doesn't refresh the model, so testing a model change requires `build`. `build` does a `run` and a `test` of each node (model, seed, snapshot) in the order of the DAG
3. **Always use `--quiet`** with `--warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}'` to reduce output while catching selector typos
4. **Always use `--select`** - never run the entire project without explicit user approval
## Quick Reference
```bash
# Standard command pattern
dbt build --select my_model --quiet --warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}'
# Preview model output
dbt show --select my_model --limit 10
# Run inline SQL query
dbt show --inline "select * from {{ ref('orders') }}" --limit 5
# With variables (JSON format for multiple)
dbt build --select my_model --vars '{"key": "value"}'
# Full refresh for incremental models
dbt build --select my_model --full-refresh
# List resources before running
dbt list --select my_model+ --resource-type model
```
## dbt CLI Flavors
Three CLIs exist. **Ask the user which one if unsure.**
| Flavor | Location | Notes |
|--------|----------|-------|
| **dbt Core** | Python venv | `pip show dbt-core` or `uv pip show dbt-core` |
| **dbt Fusion** | `~/.local/bin/dbt` or `dbtf` | Faster and has stronger SQL comprehension |
| **dbt Cloud CLI** | `~/.local/bin/dbt` | Go-based, runs on platform |
**Common setup:** Core in venv + Fusion at `~/.local/bin`. Running `dbt` uses Core. Use `dbtf` or `~/.local/bin/dbt` for Fusion.
## Selectors
**Always provide a selector.** Graph operators:
| Operator | Meaning | Example |
|----------|---------|---------|
| `model+` | Model and all downstream | `stg_orders+` |
| `+model` | Model and all upstream | `+dim_customers` |
| `+model+` | Both directions | `+orders+` |
| `model+N` | Model and N levels downstream | `stg_orders+1` |
```bash
--select my_model # Single model
--select staging.* # Path pattern
--select fqn:*stg_* # FQN pattern
--select model_a model_b # Union (space)
--select tag:x,config.mat:y # Intersection (comma)
--exclude my_model # Exclude from selection
```
**Resource type filter:**
```bash
--resource-type model
--resource-type test --resource-type unit_test
```
Valid types: `model`, `test`, `unit_test`, `snapshot`, `seed`, `source`, `exposure`, `metric`, `semantic_model`, `saved_query`, `analysis`
## List
Use `dbt list` to preview what will be selected before running. Helpful for validating complex selectors.
```bash
dbt list --select my_model+ # Preview selection
dbt list --select my_model+ --resource-type model # Only models
dbt list --output json # JSON output
dbt list --select my_model --output json --output-keys unique_id name resource_type config
```
**Available output keys for `--output json`:**
`unique_id`, `name`, `resource_type`, `package_name`, `original_file_path`, `path`, `alias`, `description`, `columns`, `meta`, `tags`, `config`, `depends_on`, `patch_path`, `schema`, `database`, `relation_name`, `raw_code`, `compiled_code`, `language`, `docs`, `group`, `access`, `version`, `fqn`, `refs`, `sources`, `metrics`
## Show
Preview data with `dbt show`. Use `--inline` for arbitrary SQL queries.
```bash
dbt show --select my_model --limit 10
dbt show --inline "select * from {{ ref('orders') }} where status = 'pending'" --limit 5
```
**Important:** Use `--limit` flag, not SQL `LIMIT` clause.
## Variables
Pass as STRING, not dict. No special characters (`\`, `\n`).
```bash
--vars 'my_var: value' # Single
--vars '{"k1": "v1", "k2": 42, "k3": true}' # Multiple (JSON)
```
## Analyzing Run Results
After a dbt command, check `target/run_results.json` for detailed execution info:
```bash
# Quick status check
cat target/run_results.json | jq '.results[] | {node: .unique_id, status: .status, time: .execution_time}'
# Find failures
cat target/run_results.json | jq '.results[] | select(.status != "success")'
```
**Key fields:**
- `status`: success, error, fail, skipped, warn
- `execution_time`: seconds spent executing
- `compiled_code`: rendered SQL
- `adapter_response`: database metadata (rows affected, bytes processed)
## Defer (Skip Upstream Builds)
Reference production data instead of building upstream models:
```bash
dbt build --select my_model --defer --state prod-artifacts
```
**Flags:**
- `--defer` - enable deferral to state manifest
- `--state <path>` - path to manifest from previous run (e.g., production artifacts)
- `--favor-state` - prefer node definitions from state even if they exist locally
```bash
dbt build --select my_model --defer --state prod-artifacts --favor-state
```
## Static Analysis (Fusion Only)
Override SQL analysis for models with dynamic SQL or unrecognized UDFs:
```bash
dbt run --static-analysis=off
dbt run --static-analysis=unsafe
```
## Common Mistakes
| Mistake | Fix |
|---------|-----|
| Using `test` after model change | Use `build` - test doesn't refresh the model |
| Running without `--select` | Always specify what to run |
| Using `--quiet` without warn-error | Add `--warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}'` |
| Running `dbt` expecting Fusion when we are in a venv | Use `dbtf` or `~/.local/bin/dbt` |
| Adding LIMIT to SQL in `dbt_show` | Use `limit` parameter instead |
| Vars with special characters | Pass as simple string, no `\` or `\n` |Related Skills
using-dbt-for-analytics-engineering
Builds and modifies dbt models, writes SQL transformations using ref() and source(), creates tests, and validates results with dbt show. Use when doing any dbt work - building or modifying models, debugging errors, exploring unfamiliar data sources, writing tests, or evaluating impact of changes.
troubleshooting-dbt-job-errors
Diagnoses dbt Cloud/platform job failures by analyzing run logs, querying the Admin API, reviewing git history, and investigating data issues. Use when a dbt Cloud/platform job fails and you need to diagnose the root cause, especially when error messages are unclear or when intermittent failures occur. Do not use for local dbt development errors.
migrating-dbt-project-across-platforms
Use when migrating a dbt project from one data platform or data warehouse to another (e.g., Snowflake to Databricks, Databricks to Snowflake) using dbt Fusion's real-time compilation to identify and fix SQL dialect differences.
migrating-dbt-core-to-fusion
Classifies dbt-core to Fusion migration errors into actionable categories (auto-fixable, guided fixes, needs input, blocked). Use when a user needs help triaging migration errors to understand what they can fix vs what requires Fusion engine updates.
fetching-dbt-docs
Retrieves and searches dbt documentation pages in LLM-friendly markdown format. Use when fetching dbt documentation, looking up dbt features, or answering questions about dbt Cloud, dbt Core, or the dbt Semantic Layer.
configuring-dbt-mcp-server
Generates MCP server configuration JSON, resolves authentication setup, and validates server connectivity for dbt. Use when setting up, configuring, or troubleshooting the dbt MCP server for AI tools like Claude Desktop, Claude Code, Cursor, or VS Code.
building-dbt-semantic-layer
Use when creating or modifying dbt Semantic Layer components — semantic models, metrics, dimensions, entities, measures, or time spines. Covers MetricFlow configuration, metric types (simple, derived, cumulative, ratio, conversion), and validation for both latest and legacy YAML specs.
auditing-skills
Use when checking skills for security or quality issues, reviewing audit results from skills.sh or Tessl, or remediating findings across published skills.
answering-natural-language-questions-with-dbt
Writes and executes SQL queries against the data warehouse using dbt's Semantic Layer or ad-hoc SQL to answer business questions. Use when a user asks about analytics, metrics, KPIs, or data (e.g., "What were total sales last quarter?", "Show me top customers by revenue"). NOT for validating, testing, or building dbt models during development.
adding-dbt-unit-test
Creates unit test YAML definitions that mock upstream model inputs and validate expected outputs. Use when adding unit tests for a dbt model or practicing test-driven development (TDD) in dbt.
review-django-commands
Review Django management commands for proper structure and refactor if needed
long-running-harness
**UNIVERSAL TRIGGER**: Use when user wants to START/CONTINUE/MANAGE a long-running development project across multiple sessions. Common patterns: - "start/init/begin new project [description]" - "continue/resume working on [project]" - "начать/инициализировать проект", "продолжить работу над проектом" - "set up harness for [project]", "create project scaffolding" Session types supported: **Initialize (first run)**: - "init long-running project", "start new multi-session project" - "set up project harness", "create progress tracking" - "initialize [web-app/api/cli] project", "начать долгий проект" **Continue (subsequent sessions)**: - "continue project", "resume work", "продолжить работу" - "pick up where I left off", "what's next", "следующая фича" - "next feature", "continue implementation" **Status & Progress**: - "show project progress", "what features are done" - "project status", "статус проекта", "что сделано" - "remaining features", "what's left to do" **Management**: - "mark feature as done", "update progress" - "add new feature to list", "reprioritize features" Context patterns: - "get/show/list project progress" - "check project status" - "what features in project" - "display remaining features" - "fetch session history" - "retrieve progress log" TRIGGERS: long-running, multi-session, project harness, initialize project, continue project, resume work, progress tracking, feature list, session handoff, incremental development, cross-session, долгий проект, продолжить работу, прогресс проекта, следующая сессия, инициализация проекта, get project status, show features, list remaining, check progress, display status, fetch history, retrieve log, what features done, start harness, begin project, resume session, next feature, pick up work, update progress, mark done, end session Based on Anthropic's research on effective harnesses for long-running agents. Source: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents