dbt Operational Slash Commands

This note covers operational Claude Code slash commands for the daily dbt workflow: building models, scaffolding base models, running modified code, auditing existing models, and cleaning up artifacts. For foundational command patterns (anatomy, $ARGUMENTS, allowed-tools), see Claude Code Slash Commands for dbt.

Commands live in .claude/commands/ at the project root. Commit them to git so the whole team gets the same workflows. Invoke with /project:command-name from Claude Code.

/dbt-build: Build a Model with Dependencies

Wraps dbt build --select with context injection. Instead of typing dbt build --select +stg_orders, type /project:dbt-build +stg_orders.

Create .claude/commands/dbt-build.md:

---
allowed-tools: Bash(dbt:*), Bash(git:*)
argument-hint: [+]model_name
description: Build a dbt model (prefix with + for upstream deps)
---

## What we're working with

Current branch: !`git branch --show-current`

Recently modified:
!`git diff --name-only HEAD | grep "\.sql$" | head -5`

## Your task

Build the model: **$ARGUMENTS**

Run `dbt build --select $ARGUMENTS` and let me know:
- Did it succeed?
- How long did it take?
- If tests failed, what went wrong and how should I fix it?

The ! prefix runs bash inline and includes the output as context. The allowed-tools field restricts Claude to dbt and git commands. The argument-hint tells you what to type. The + prefix is dbt’s upstream selector — +stg_orders builds stg_orders and all its dependencies.

/dbt-base: Generate a Base Model from a Source

Generates a base model by reading existing base models first to understand project conventions, then producing a new model that matches them.

Create .claude/commands/dbt-base.md:

---
allowed-tools: Bash(dbt:*), Read, Write, Glob
argument-hint: source_name table_name
description: Generate a base model following project conventions
---

## Our conventions

Here's how our existing base models look:
!`ls models/base/base__*.sql | head -3 | xargs head -30`

## Your task

Create a base model for source **$1**, table **$2**.

1. Create `models/base/base__$1__$2.sql` with:
   - A source CTE pulling from `{{ source('$1', '$2') }}`
   - A renamed CTE with clean snake_case column names
   - Appropriate type casting (especially for dates)

1. Add the model to `models/base/_base__$1__models.yml` with:
   - A clear description
   - Primary key uniqueness + not_null tests
   - Not-null tests on required columns

1. Run `dbt compile --select base__$1__$2` to verify it works

Usage: /project:dbt-base ga4 events

The ! block reads existing base models before generating a new one, so the output reflects actual project conventions — CTE naming, column naming, casting style, deduplication approach — rather than a generic template.

Note the use of $1 and $2 instead of $ARGUMENTS. When the argument-hint specifies multiple parameters, Claude Code splits the input. $1 gets the first argument, $2 gets the second.

This command also adds Write to allowed-tools because it needs to create the SQL file and update the YAML. The Glob tool lets Claude find the right YAML file if your naming convention doesn’t exactly match the pattern in the command.

/dbt-modified: Build Only What You’ve Changed

When iterating on a feature branch, you usually just want to build the models you’ve touched. This command figures out what changed and builds exactly that.

Create .claude/commands/dbt-modified.md:

---
allowed-tools: Bash(dbt:*), Bash(git:*)
description: Build only the models modified in this branch
---

## What's changed

Models modified vs main:
!`git diff --name-only origin/main...HEAD | grep "models/.*\.sql$" || echo "No model changes found"`

## Your task

Build only the modified models using `dbt build --select state:modified`.

If anything fails, tell me what went wrong and suggest a fix.

No argument-hint because this command doesn’t take arguments. It discovers what to build by comparing the current branch to origin/main. The state:modified selector requires a production manifest to compare against — make sure your project has target/ from a prior dbt compile or a CI manifest.

Run before opening a PR to verify the branch builds cleanly.

/dbt-audit: Audit a Model for Best Practices

Examines a model for code quality, documentation, test coverage, and dependency issues.

Create .claude/commands/dbt-audit.md:

---
allowed-tools: Read, Glob, Bash(dbt:*)
argument-hint: model_name
description: Audit a model for dbt best practices
---

## Your task

Audit **$ARGUMENTS** and tell me if anything looks off.

Check:
1. **Code quality**: Uses CTEs (not subqueries), has comments where logic is complex, follows naming conventions
2. **Documentation**: Model is described in YAML, key columns are documented
3. **Testing**: Has primary key tests (unique + not_null), critical columns are tested
4. **Dependencies**: Run `dbt ls --select +$ARGUMENTS` — is it referencing base models or raw tables directly?

Be specific. If something's missing, show me exactly what to add.

Usage: /project:dbt-audit mrt__sales__orders

Notice the allowed-tools field: Read and Glob for inspecting files, Bash(dbt:*) for running dbt commands. No Write — this command is read-only. It reports findings but doesn’t change anything. You decide what to fix.

The dependency check (dbt ls --select +model) surfaces cases where mart models reference raw sources directly, bypassing the base layer, or where models have unexpectedly deep dependency chains.

/dbt-cleanup: Clean Up Development Artifacts

Create .claude/commands/dbt-cleanup.md:

---
allowed-tools: Bash(dbt:*), Bash(rm:*)
description: Clean up dbt development artifacts
---

## Your task

Clean up the local environment:

1. Remove `target/` (compiled artifacts)
2. Remove `dbt_packages/` (installed packages)
3. Run `dbt clean`
4. Run `dbt deps` to reinstall packages fresh

Tell me how much space was freed up.

A housekeeping command. When compiled artifacts get stale, package versions drift, or you’re getting mysterious errors that might be cached state, /project:dbt-cleanup resets everything. The Bash(rm:*) tool permission is scoped to rm commands — Claude can delete artifacts but nothing else.

Designing Commands for Your Team

The five commands above cover common operations, but the real value comes from commands tailored to your project’s specific workflows. A few principles from Claude Code Slash Commands for dbt that apply especially to operational commands:

Include context with ! blocks. The dbt-build command shows the current branch and modified files. The dbt-base command reads existing models. This context makes Claude’s output more relevant than a blind execution.

Scope allowed-tools tightly. Audit commands don’t need write access. Build commands don’t need file editing. Each constraint reduces the chance of Claude doing something unexpected.

Keep the variable part in $ARGUMENTS. The workflow steps, quality standards, and conventions should be fixed in the command. Only the model name or target comes from the user.

Combine with hooks. When you run /project:dbt-build, the safety hook still fires on the dbt command. The Stop hook still runs quality checks after Claude finishes. Commands and hooks work together — commands define what to do, hooks enforce how it’s done.