Provides guidance on building dbt data pipelines.

Install

mkdir -p .claude/skills/data-dbt-guide && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17158" && unzip -o skill.zip -d .claude/skills/data-dbt-guide && rm skill.zip

Installs to .claude/skills/data-dbt-guide

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Transformation de données avec dbt — models, tests, sources, macros et documentation automatisée. Se déclenche avec "dbt", "data build tool", "dbt model", "dbt test", "transformation de données dbt".
199 charsno explicit “when” trigger
Intermediate

Key capabilities

  • Initialize and structure dbt projects
  • Declare data sources with freshness checks
  • Develop dbt models for staging, intermediate, and marts layers
  • Test data with YAML and custom SQL tests
  • Generate automated documentation for models

How it works

The skill guides users through initializing a dbt project, declaring sources, developing models with specific materializations, creating tests, and generating documentation, following a structured workflow.

Inputs & outputs

You give it
Raw data sources and transformation requirements
You get back
Structured dbt project with models, tests, and documentation

When to use data-dbt-guide

  • Build dbt models
  • Test data sources
  • Structure data transformation

About this skill

Guide dbt

Workflow

1. Initialiser et structurer le projet

dbt init mon_projet        # crée le squelette
cd mon_projet
dbt debug                  # vérifie la connexion au warehouse

Arborescence cible :

models/
  staging/         ← nettoyage source, renommage, cast ; materialisation = view
  intermediate/    ← jointures, logique métier complexe ; materialisation = view ou ephemeral
  marts/           ← modèles finaux consommables ; materialisation = table
macros/
tests/
seeds/
snapshots/

dbt_project.yml — materialisations par dossier :

models:
  mon_projet:
    staging:
      +materialized: view
      +schema: staging
    intermediate:
      +materialized: view
    marts:
      +materialized: table
      +schema: marts

2. Déclarer les sources

# models/staging/sources.yml
version: 2
sources:
  - name: raw_crm
    schema: raw
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _loaded_at
    tables:
      - name: orders
        description: "Commandes brutes issues du CRM"
        columns:
          - name: order_id
            tests: [unique, not_null]

Référencer dans un modèle :

select * from {{ source('raw_crm', 'orders') }}

Tester la fraîcheur :

dbt source freshness

3. Développer les modèles

Staging — un modèle par table source, préfixe stg_ :

-- models/staging/stg_orders.sql
with source as (
    select * from {{ source('raw_crm', 'orders') }}
),
renamed as (
    select
        order_id::varchar      as order_id,
        customer_id::int       as customer_id,
        created_at::timestamp  as created_at,
        status::varchar        as status
    from source
)
select * from renamed

Mart — utilise ref() pour chaque dépendance :

-- models/marts/fct_orders.sql
with orders as (
    select * from {{ ref('stg_orders') }}
),
customers as (
    select * from {{ ref('stg_customers') }}
)
select
    o.order_id,
    o.created_at,
    c.customer_name,
    o.status
from orders o
left join customers c on o.customer_id = c.customer_id

Critères de choix de materialisation :

CasMaterialisation recommandée
Nettoyage léger / peu consomméview
Rapport BI / dashboardtable
Table > 10M lignes avec clé temporelleincremental
Sous-requête intermédiaire réutiliséeephemeral
Suivi de changements type SCD2snapshot

Modèle incrémental :

-- models/marts/fct_events.sql
{{ config(materialized='incremental', unique_key='event_id') }}

select * from {{ ref('stg_events') }}

{% if is_incremental() %}
  where event_at > (select max(event_at) from {{ this }})
{% endif %}

4. Tester les données

Fichier YAML associé à chaque modèle :

# models/marts/fct_orders.yml
version: 2
models:
  - name: fct_orders
    description: "Faits commandes enrichis"
    columns:
      - name: order_id
        tests: [unique, not_null]
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'confirmed', 'shipped', 'cancelled']
      - name: customer_id
        tests:
          - relationships:
              to: ref('stg_customers')
              field: customer_id

Test custom SQL dans tests/ :

-- tests/assert_no_negative_amount.sql
select order_id
from {{ ref('fct_orders') }}
where amount < 0

Commandes :

dbt test                          # tous les tests
dbt test --select fct_orders      # tests d'un modèle
dbt test --store-failures         # stocker les lignes en erreur dans le warehouse

5. Créer des macros

-- macros/generate_surrogate_key.sql
{% macro generate_surrogate_key(fields) %}
    {{ dbt_utils.generate_surrogate_key(fields) }}
{% endmacro %}

-- macros/audit_columns.sql
{% macro audit_columns() %}
    current_timestamp as dbt_loaded_at,
    '{{ invocation_id }}' as dbt_run_id
{% endmacro %}

Usage dans un modèle :

select
    {{ generate_surrogate_key(['order_id', 'customer_id']) }} as sk_order,
    order_id,
    {{ audit_columns() }}
from {{ ref('stg_orders') }}

6. Documenter

models:
  - name: fct_orders
    description: >
      Faits commandes joints avec les clients.
      Utilisé par le dashboard Revenue dans Metabase.
    columns:
      - name: order_id
        description: "Identifiant unique de la commande (source CRM)"
dbt docs generate   # génère catalog.json
dbt docs serve      # ouvre le site sur localhost:8080

7. CI/CD et environnements

profiles.yml — deux targets :

mon_projet:
  target: dev
  outputs:
    dev:
      type: snowflake
      schema: "dbt_{{ env_var('DBT_USER', 'dev') }}"
      ...
    prod:
      type: snowflake
      schema: marts
      ...

Pipeline CI (GitHub Actions) :

- run: dbt build --target prod --select state:modified+  # uniquement les modèles modifiés et leurs dépendants
- run: dbt test  --target prod --select state:modified+
dbt build           # compile + run + test en une commande
dbt build --select +fct_orders   # modèle + tous ses ancêtres
dbt run --exclude tag:slow       # exclure les modèles lourds

Anti-patterns / Pièges

PiègeCorrection
select * en mart sans liste expliciteLister les colonnes exposées, ça évite les régressions silencieuses
Table en dur dans un modèle SQLToujours {{ ref() }} ou {{ source() }}
Pas de unique_key sur un incrémentalCrée des doublons à chaque run ; définir unique_key obligatoirement
Tests YAML uniquement sur la PKTester aussi les FK (relationships), les valeurs acceptées et les colonnes NOT NULL métier
Incrémental sans stratégie full refreshAjouter +full_refresh: false en dev seulement ; prévoir dbt run --full-refresh planifié
Modèles staging qui joinent plusieurs sourcesUn modèle staging = une source ; les jointures vont en intermediate/
Documentation rédigée après-coupÉcrire description + tests en même temps que le modèle, sinon jamais fait
dbt run en prod sans dbt testUtiliser dbt build qui enchaîne les deux et stoppe à la première erreur

Bonnes pratiques 2026

  • dbt Core ≥ 1.8 : utiliser dbt_project.yml v10 et les groupes de modèles pour les accès (access: private/protected/public).
  • Contrats de modèle (contract: {enforced: true}) sur les marts exposés — casse le build si le schéma dévie.
  • Unit tests dbt (natif depuis 1.8) pour tester la logique SQL sans données réelles :
    unit_tests:
      - name: test_order_total
        model: fct_orders
        given:
          - input: ref('stg_orders')
            rows: [{order_id: 1, amount: 100}, {order_id: 2, amount: 0}]
        expect:
          rows: [{order_id: 1, total: 100}]
    
  • dbt-utils et dbt-expectations : packages standards pour tests avancés (expect_column_values_to_be_between, expression_is_true, etc.).
  • Semantic Layer dbt : définir les métriques dans metrics: pour exposer des KPIs cohérents aux outils BI.
  • Sélecteur state:modified+ en CI : ne rebuilder que ce qui a changé, réduit les coûts warehouse jusqu'à 80 %.

Communication Rules — MANDATORY

  • Ultra-concise. No filler, no preamble, no pleasantries.
  • Never say "happy to help", "sure!", "great question", "let me", or similar.
  • Tool first, talk second. Act before explaining.
  • Result first. Lead with outcome, not process.
  • Stop when done. No summary, no recap, no trailing commentary.
  • No politeness wrappers. Direct and blunt.
  • Minimum words. If one word works, do not use ten.
  • No unsolicited explanations.
  • No emoji unless asked.

When not to use it

  • When a staging model needs to join multiple sources
  • When using `select *` in mart models without explicit column listing
  • When an incremental model lacks a `unique_key`

Prerequisites

dbt Core

Limitations

  • The skill assumes a specific project structure for models, macros, and tests
  • Incremental models require a `unique_key` to prevent duplicates
  • The skill emphasizes specific materialization choices for different use cases

How it compares

This skill provides a structured, automated approach to data transformation and documentation using dbt, contrasting with manual SQL scripting and documentation efforts.

Compared to similar skills

data-dbt-guide side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
data-dbt-guide (this skill)01moReviewIntermediate
data-quality-frameworks04moNo flagsIntermediate
soda-core03moReviewIntermediate
sqlmesh03moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

data-quality-frameworks

Anhvu1107

ALWAYS use this when the request matches Data Quality Frameworks: Implement data quality validation with Great Expectations, dbt tests, and data contracts.

00

soda-core

ivanshamaev

Soda Core data quality — SodaCL checks (row_count, missing, invalid, duplicate, freshness, schema, reference, custom SQL), configuration.yml for PostgreSQL/Spark/ClickHouse/BigQuery, soda scan CLI, Airflow integration, dbt integration, alerting

00

sqlmesh

droher

Use when working with SQLMesh — writing or editing MODEL blocks, Python @model decorators, Python @macros, audits, unit tests, external_models.yaml, or seeds; running `sqlmesh plan/apply/audit/render/evaluate/test`; debugging plans, snapshots, virtual environments, or state issues; configuring `conf

00

snowflake-connections

sfc-gh-dflippo

Configuring Snowflake connections using connections.toml (for Snowflake CLI, Streamlit, Snowpark) or profiles.yml (for dbt) with multiple authentication methods (SSO, key pair, username/password, OAuth), managing multiple environments, and overriding settings with environment variables. Use this skill when setting up Snowflake CLI, Streamlit apps, dbt, or any tool requiring Snowflake authentication and connection management.

7130

sql-queries

anthropics

Write correct, performant SQL across all major data warehouse dialects (Snowflake, BigQuery, Databricks, PostgreSQL, etc.). Use when writing queries, optimizing slow SQL, translating between dialects, or building complex analytical queries with CTEs, window functions, or aggregations.

1888

senior-data-engineer

davila7

World-class data engineering skill for building scalable data pipelines, ETL/ELT systems, and data infrastructure. Expertise in Python, SQL, Spark, Airflow, dbt, Kafka, and modern data stack. Includes data modeling, pipeline orchestration, data quality, and DataOps. Use when designing data architectures, building data pipelines, optimizing data workflows, or implementing data governance.

2179

Search skills

Search the agent skills registry