Agent Skills: dbt

Use when building dbt models, adding tests, or designing data models. Covers dimensional modeling, model organization (staging/intermediate/marts), testing patterns, and warehouse-specific configurations.

UncategorizedID: bbrewington/software-data-and-ai-tools/dbt

Install this agent skill to your local

pnpm dlx add-skill https://github.com/bbrewington/software-data-and-ai-tools/tree/HEAD/skills/dbt

Skill Files

Browse the full folder contents for dbt.

Download Skill

Loading file tree…

skills/dbt/SKILL.md

Skill Metadata

Name
dbt
Description
Use when building dbt models, adding tests, or designing data models. Covers dimensional modeling, model organization (staging/intermediate/marts), testing patterns, and warehouse-specific configurations.

dbt

Patterns for dbt data transformation projects.

Skill Modules

This skill is organized into the following modules. Read the relevant module(s) based on the task:

| Module | File | Use When | |--------|------|----------| | Data Modeling | references/data-modeling.md | Designing dimensional models, defining grain, facts vs dimensions, SCDs | | Model Layers | references/model-layers.md | Organizing staging/intermediate/marts, naming conventions, project structure | | Package Testing | references/testing-packages.md | Integration tests for dbt package development |

Quick Reference

Commands

dbt run                          # Run all models
dbt run --select +model_name     # Model + upstream
dbt run --select model_name+     # Model + downstream
dbt run --select tag:daily       # Models with tag
dbt test                         # Run all tests
dbt test --select "test_type:unit"      # Unit tests only
dbt test --select "test_type:data"      # Data tests only
dbt build                        # Run + test in DAG order
dbt build --select state:modified+      # Modified + downstream (CI)
dbt docs generate                # Generate documentation
dbt source freshness             # Check source freshness

Naming Conventions

| Layer | Pattern | Example | |-------|---------|---------| | Staging | stg__<source>__<table> | stg__stripe__customers | | Intermediate | int_<entity>__<transform> | int_customers__enriched | | Fact | fct_<event> | fct_orders | | Dimension | dim_<entity> | dim_customers |

Column Naming

| Type | Convention | Examples | |------|------------|----------| | IDs | <entity>_id | customer_id, order_id | | Timestamps | <event>_at | created_at, updated_at, shipped_at | | Dates | <event>_date | order_date, birth_date | | Booleans | is_<state> or has_<thing> | is_active, has_subscription | | Amounts | <name>_<unit> | amount_usd, quantity_units | | Counts | <thing>_count | order_count, item_count |

Testing Pyramid

          Integration Tests  ← Package development only
              Unit Tests     ← Complex transformation logic
           Singular Tests    ← Business rules
           Generic Tests     ← Keys, constraints, patterns
         Source Freshness    ← Pipeline health
             Contracts       ← Schema enforcement

What to Test (Quick Guide)

| Always | Sometimes | Rarely | |--------|-----------|--------| | Primary keys (unique + not_null) | Optional FKs | Every column not_null | | Required foreign keys | Numeric ranges | Columns in contracts | | Business-critical derived fields | String patterns | Staging columns | | Status/enum columns | Row count bounds | Intermediate models |

Best Practices Summary

Things to do

  • DO Define grain for every model (what does one row represent?)
  • DO Use staging for renaming/casting only—no business logic
  • DO Test primary keys on every model (unique + not_null)
  • DO Use contracts for marts (enforce schema at build time)
  • DO Add tests when you find bugs (regression prevention)
  • DO Document models and columns in YAML
  • DO Use incremental models for large tables
  • DO Tag critical tests and run them more frequently

Don't

  • DON'T Skip the staging layer
  • DON'T Put business logic in staging models
  • DON'T Hardcode values (use {{ var() }} or {{ env_var() }})
  • DON'T Test every column (diminishing returns)
  • DON'T Ignore test warnings indefinitely
  • DON'T Forget source freshness checks
  • DON'T Create circular dependencies between models