Commandes slash opérationnelles dbt pour Claude Code

Cette note couvre les commandes slash Claude Code opérationnelles pour le workflow dbt quotidien : build de modèles, scaffolding de modèles base, exécution du code modifié, audit de modèles existants et nettoyage des artefacts. Pour les patterns de commandes fondamentaux (anatomie, $ARGUMENTS, allowed-tools), voir Commandes slash Claude Code pour dbt.

Les commandes résident dans .claude/commands/ à la racine du projet. Commitez-les dans git afin que toute l’équipe bénéficie des mêmes workflows. Invoquez-les avec /project:nom-de-commande depuis Claude Code.

/dbt-build : Builder un modèle avec ses dépendances

Encapsule dbt build --select avec injection de contexte. Au lieu de taper dbt build --select +stg_orders, tapez /project:dbt-build +stg_orders.

Créez .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?

Le préfixe ! exécute bash en ligne et inclut la sortie comme contexte. Le champ allowed-tools restreint Claude aux commandes dbt et git. Le argument-hint indique ce que vous devez taper. Le préfixe + est le sélecteur amont de dbt — +stg_orders build stg_orders et toutes ses dépendances.

/dbt-base : Générer un modèle base depuis une source

Génère un modèle base en lisant d’abord les modèles base existants pour comprendre les conventions du projet, puis en produisant un nouveau modèle qui leur correspond.

Créez .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

Le bloc ! lit les modèles base existants avant d’en générer un nouveau, de sorte que la sortie reflète les conventions réelles du projet — nommage des CTE, nommage des colonnes, style de casting, approche de déduplication — plutôt qu’un template générique.

Notez l’utilisation de $1 et $2 au lieu de $ARGUMENTS. Lorsque le argument-hint spécifie plusieurs paramètres, Claude Code divise la saisie. $1 reçoit le premier argument, $2 le second.

Cette commande ajoute également Write à allowed-tools car elle doit créer le fichier SQL et mettre à jour le YAML. L’outil Glob permet à Claude de trouver le bon fichier YAML si votre convention de nommage ne correspond pas exactement au pattern dans la commande.

/dbt-modified : Builder uniquement ce que vous avez modifié

Lors de l’itération sur une branche de fonctionnalité, vous souhaitez généralement uniquement builder les modèles que vous avez modifiés. Cette commande détermine ce qui a changé et ne build que cela.

Créez .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.

Pas d’argument-hint car cette commande ne prend pas d’arguments. Elle détermine ce qu’il faut builder en comparant la branche courante à origin/main. Le sélecteur state:modified nécessite un manifest de production pour la comparaison — assurez-vous que votre projet dispose d’un target/ issu d’un dbt compile préalable ou d’un manifest CI.

À exécuter avant d’ouvrir une PR pour vérifier que la branche se build proprement.

/dbt-audit : Auditer un modèle selon les bonnes pratiques

Examine un modèle pour la qualité du code, la documentation, la couverture de tests et les problèmes de dépendances.

Créez .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

Notez le champ allowed-tools : Read et Glob pour inspecter les fichiers, Bash(dbt:*) pour exécuter des commandes dbt. Pas de Write — cette commande est en lecture seule. Elle rapporte les résultats mais ne modifie rien. C’est à vous de décider quoi corriger.

La vérification des dépendances (dbt ls --select +model) révèle les cas où des modèles mart référencent directement des sources brutes en contournant la couche base, ou où des modèles ont des chaînes de dépendances anormalement profondes.

/dbt-cleanup : Nettoyer les artefacts de développement

Créez .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.

Une commande de maintenance. Lorsque les artefacts compilés deviennent obsolètes, que les versions de packages dérivent, ou que vous obtenez des erreurs mystérieuses pouvant être liées à un état mis en cache, /project:dbt-cleanup réinitialise tout. La permission d’outil Bash(rm:*) est limitée aux commandes rm — Claude peut supprimer des artefacts mais rien d’autre.

Concevoir des commandes pour votre équipe

Les cinq commandes ci-dessus couvrent les opérations courantes, mais la vraie valeur vient des commandes adaptées aux workflows spécifiques de votre projet. Quelques principes tirés des commandes slash Claude Code pour dbt qui s’appliquent particulièrement aux commandes opérationnelles :

Inclure du contexte avec des blocs !. La commande dbt-build montre la branche courante et les fichiers modifiés. La commande dbt-base lit les modèles existants. Ce contexte rend la sortie de Claude plus pertinente qu’une exécution aveugle.

Limiter allowed-tools strictement. Les commandes d’audit n’ont pas besoin d’accès en écriture. Les commandes de build n’ont pas besoin d’édition de fichiers. Chaque contrainte réduit le risque que Claude fasse quelque chose d’inattendu.

Garder la partie variable dans $ARGUMENTS. Les étapes du workflow, les standards de qualité et les conventions doivent être figés dans la commande. Seul le nom du modèle ou la cible provient de l’utilisateur.

Combiner avec les hooks. Lorsque vous exécutez /project:dbt-build, le hook de sécurité se déclenche toujours sur la commande dbt. Le hook Stop s’exécute toujours après la fin de Claude. Les commandes et les hooks fonctionnent ensemble — les commandes définissent quoi faire, les hooks imposent comment c’est fait.