Use when executing dbt commands via CLI - running models, tests, builds, compiles, or show queries. Use when unsure which dbt executable to use or how to format command parameters.
Install with Tessl CLI
npx tessl i github:dbt-labs/dbt-agent-skills --skill running-dbt-commands95
Quality
95%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
dbt_build, dbt_run, dbt_show, etc.) - they handle paths, timeouts, and formatting automaticallybuild 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--quiet with --warn-error-options '{"error": ["NoNodesForSelectionCriteria"]}' to reduce output while catching selector typos--select - never run the entire project without explicit user approval# 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 modelThree 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.
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 |
--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 selectionResource type filter:
--resource-type model
--resource-type test --resource-type unit_testValid types: model, test, unit_test, snapshot, seed, source, exposure, metric, semantic_model, saved_query, analysis
Use dbt list to preview what will be selected before running. Helpful for validating complex selectors.
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 configAvailable 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
Preview data with dbt show. Use --inline for arbitrary SQL queries.
dbt show --select my_model --limit 10
dbt show --inline "select * from {{ ref('orders') }} where status = 'pending'" --limit 5Important: Use --limit flag, not SQL LIMIT clause.
Pass as STRING, not dict. No special characters (\, \n).
--vars 'my_var: value' # Single
--vars '{"k1": "v1", "k2": 42, "k3": true}' # Multiple (JSON)After a dbt command, check target/run_results.json for detailed execution info:
# 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, warnexecution_time: seconds spent executingcompiled_code: rendered SQLadapter_response: database metadata (rows affected, bytes processed)Reference production data instead of building upstream models:
dbt build --select my_model --defer --state prod-artifactsFlags:
--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 locallydbt build --select my_model --defer --state prod-artifacts --favor-stateOverride SQL analysis for models with dynamic SQL or unrecognized UDFs:
dbt run --static-analysis=off
dbt run --static-analysis=unsafe| 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 |
65d2e0b
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.