dbt-skill

Use when working with dbt (data build tool) - creating models, writing tests, CI/CD pipelines, materializations, sources, staging/intermediate/marts layers, Snowflake/BigQuery warehouse configuration, incremental strategies, Jinja macros, data quality, semantic layer, or making analytics engineering decisions

dtsong/my-claude-setup2 installsApache-2.0Synced Aug 26

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: dbt-skill
description: Use when working with dbt (data build tool) - creating models, writing tests, CI/CD pipelines, materializations, sources, staging/intermediate/marts layers, Snowflake/BigQuery warehouse configuration, incremental strategies, Jinja macros, data quality, semantic layer, or making analytics engineering decisions
license: Apache-2.0
---

# dbt Skill for Claude

Comprehensive dbt guidance: project structure, modeling, testing, CI/CD, production patterns. Targets Snowflake and BigQuery. Beginner-friendly with progressive scaling.

## When to Use

Activate when: creating/modifying dbt models, choosing materializations, structuring layers, setting up tests, implementing CI/CD, configuring sources/freshness, writing Jinja macros, reviewing dbt projects, making analytics engineering decisions.

Skip when: basic SQL syntax, warehouse admin, raw pipeline config (Fivetran/Airbyte), BI tool config.

## Core Principles

1. **DRY via ref()/source()** -- never hardcode table names
2. **Single Source of Truth** -- each concept defined once; staging = entry point, marts = consumer interface
3. **Idempotent Transformations** -- `dbt run` twice produces identical results
4. **Test Everything** -- every model has at minimum PK uniqueness and not-null tests
5. **Progressive Complexity** -- start with views/tables, add complexity when volume demands it

## Project Structure

```
dbt_project/
├── dbt_project.yml
├── packages.yml
├── profiles.yml                 # local only, not committed
├── models/
│   ├── staging/                 # 1:1 with source tables
│   │   └── <source>/
│   │       ├── _<source>__models.yml
│   │       ├── _<source>__sources.yml
│   │       └── stg_<source>__<entity>.sql
│   ├── intermediate/            # business logic, joins, pivots
│   │   └── <domain>/
│   └── marts/                   # business-facing tables
│       └── <domain>/
│           ├── _<domain>__models.yml
│           ├── fct_<entity>.sql
│           └── dim_<entity>.sql
├── macros/
├── tests/
│   └── generic/
├── seeds/
├── snapshots/
└── analyses/
```

## Layer Decision Matrix

| Layer | Materialization | Purpose | Naming | Tests |
|-------|----------------|---------|--------|-------|
| Staging | `view` | Clean/rename raw data, 1:1 with source | `stg_<source>__<entity>` | not_null, unique on PK |
| Intermediate | `ephemeral` | Business logic, joins, pivots | `int_<entity>_<verb>ed` | Tested via downstream |
| Marts | `table`/`incremental` | Business-facing facts and dimensions | `fct_<entity>`, `dim_<entity>` | Full coverage |

## Materialization Decision Matrix

| Situation | Materialization | Why |
|-----------|----------------|-----|
| Staging models | `view` | Always fresh, minimal storage |
| Intermediate logic | `ephemeral` | Zero cost, inlined as CTE |
| Marts < 100M rows | `table` | Simple, fast reads |
| Marts > 100M rows | `incremental` | Process only new/changed data |
| SCD Type 2 | `snapshot` | Track historical changes |

## ref() and source() Rules

1. `source()` only in staging -- staging is the sole gateway to raw data
2. `ref()` everywhere else
3. Never skip layers -- marts must not ref() staging directly
4. Never hardcode schema names

## SQL Style

- Leading commas, lowercase keywords, CTEs over subqueries
- Explicit columns in marts (no `select *`), final CTE named `final`
- 4-space indentation, one column per line

## Source Configuration

Define sources in `_<source>__sources.yml` with `loaded_at_field` and freshness thresholds. Configure `warn_after` and `error_after` per table.

| Concept | Snowflake | BigQuery |
|---------|-----------|----------|
| Top-level container | Database | Project |
| Schema grouping | Schema | Dataset |

## Warehouse Quick Reference

| Config | Snowflake | BigQuery |
|--------|-----------|----------|
| Profile type | `snowflake` | `bigquery` |
| Auth | User/password or key-pair | OAuth or service account |
| Schema gen | `database.schema.model` | `project.dataset.model` |
| Incremental default | `merge` | `merge` |
| Partitioning | Automatic micro-partitions | `partition_by` required for large tables |
| Clustering | `cluster_by` (automatic) | `cluster_by` (manual) |
| Cost model | Credits (compute time) | Bytes scanned / Slots |

## Common Commands

| Command | Purpose |
|---------|---------|
| `dbt build` | Run + test in DAG order (recommended) |
| `dbt build --select +model` | Build model and all ancestors |
| `dbt build --select model+` | Build model and all descendants |
| `dbt build --select tag:finance` | All models tagged `finance` |
| `dbt build --select state:modified+` | Modified + descendants (Slim CI) |
| `dbt source freshness` | Check source freshness |
| `dbt deps` | Install packages |
| `dbt docs generate && dbt docs serve` | Documentation site |

## Gotchas

- `ref()` only in staging-and-above, `source()` only in staging — using `source()` in marts bypasses the staging contract and breaks lineage
- Incremental models without `unique_key` silently duplicate rows on re-runs — always set `unique_key` for merge strategy
- `ephemeral` models can't be tested directly or selected with `dbt test --select` — test via downstream consumers
- `dbt run` doesn't run tests — always use `dbt build` to get run + test in DAG order
- `--full-refresh` on a large incremental model can blow warehouse credits — scope with `--select` first
- Jinja whitespace control: `{%- -%}` vs `{% %}` — trailing whitespace breaks `compile` output silently
- `packages.yml` version ranges (`>=1.0,<2.0`) can pull breaking changes — pin exact versions in production

```sql
-- WRONG: source() in marts (skips staging layer)
SELECT * FROM {{ source('stripe', 'payments') }}
-- RIGHT: ref staging model
SELECT * FROM {{ ref('stg_stripe__payments') }}

-- WRONG: incremental without unique_key (duplicates on re-run)
{{ config(materialized='incremental') }}
-- RIGHT: always specify unique_key
{{ config(materialized='incremental', unique_key='payment_id') }}
```

## Reference Files

Load on demand when detailed guidance is needed:

| Reference | Topics |
|-----------|--------|
| [Testing & Quality](references/testing-quality.md) | Schema/generic/singular/unit tests, dbt-expectations, layer strategy |
| [CI/CD & Deployment](references/ci-cd-deployment.md) | Slim CI, GitHub Actions, dbt Cloud, environments, blue/green, SQLFluff |
| [Jinja, Macros & Packages](references/jinja-macros-packages.md) | Jinja fundamentals, custom macros, packages, debugging |
| [Incremental & Performance](references/incremental-performance.md) | Microbatch, merge, delete+insert, insert_overwrite, warehouse tuning |
| [Data Quality & Observability](references/data-quality-observability.md) | Source freshness, Elementary, anomaly detection, alerting, incidents |
| [Semantic Layer & Governance](references/semantic-layer-governance.md) | MetricFlow, contracts, versions, access controls, dbt Mesh |

## License

Apache License 2.0. See LICENSE file for full terms.

**Copyright 2026 Daniel Song**

More Deployment & CI/CD skills

azure-enterprise-infra-planner

microsoft/azure-skills

Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud architects and platform engineers planning networking, identity, security, compliance, and multi-resource topologies with WAF alignment. Generates Bicep or Terraform directly (no azd). WHEN: 'plan Azure infrastructure', 'architect Azure landing zone', 'design hub-spoke network', 'plan multi-region DR topology', 'set up VNets firewalls and private endpoints', 'subscription-scope Bicep deployment', 'Azure Backup for VM workloads'. PREFER azure-prepare FOR app-centric workflows.

387.5k

azure-kubernetes-app-deploy

microsoft/azure-skills

Use when deploying an existing web application or API to an already-running Azure Kubernetes Service cluster. Detects the framework, generates a Dockerfile and Kubernetes manifests, validates against AKS Deployment Safeguards, and deploys with verification. WHEN: deploy app to AKS, deploy to existing AKS cluster, containerize app for Kubernetes, generate K8s manifests for Azure, set up CI/CD for AKS, my AKS deployment is failing safeguard checks, I have a Django/Express/Spring Boot app to run on AKS. DO NOT USE FOR: creating or provisioning an AKS cluster (use azure-kubernetes), assessing migration to AKS Automatic (use azure-kubernetes-automatic-readiness), or deploying to non-AKS targets like Web Apps, Container Apps, or Functions.

380.4k

finetuning

microsoft/azure-skills

Fine-tune models on Microsoft Foundry using SFT (supervised), DPO (preference), or RFT (reinforcement with graders). Covers dataset preparation, training job submission, deployment, and evaluation. USE FOR: fine-tune, SFT, DPO, RFT, training data, grader, distillation, fine-tuned model, training job, large file upload, calibrate grader, deploy fine-tuned model, evaluate fine-tuned model. DO NOT USE FOR: general model deployment without fine-tuning (use deploy-model), agent creation (use agents), prompt optimization without training (use prompt-optimizer).

323.2k

← All Deployment & CI/CD skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY