dbt
Skill15 starsChanged 43 days agoMITView on GitHub
Expert dbt (data build tool) assistance covering SQL modeling, Jinja macros, tests, documentation, and semantic layer. Use when building analytics engineering pipelines on BigQuery, Snowflake, or PostgreSQL.
In this repository350 other files it gives its agents.
- airflowSkill
- catboostSkill
- claudeSkill
- comfyuiSkill
- cursor-aiSkill
- dalleSkill
- daskSkill
- deepseekSkill
- fastaiSkill
- geminiSkill
- github-copilotSkill
- huggingfaceSkill
- jaxSkill
- jupyterSkill
- kerasSkill
- langchainSkill
- lightgbmSkill
- llamaindexSkill
- llamaSkill
- matplotlibSkill
- midjourneySkill
- mistralSkill
- mlflowSkill
- nltkSkill
- numpySkill
- ollamaSkill
- openai-gptSkill
- opencvSkill
- pandasSkill
- perplexitySkill
- plotlySkill
- polarsSkill
- pytorchSkill
- raySkill
- scikit-learnSkill
- seabornSkill
- spacySkill
- sparkSkill
- stable-diffusionSkill
- tensorflowSkill
- vaexSkill
- weights-biasesSkill
- whisperSkill
- xgboostSkill
- api-gatewaySkill
- clean-architectureSkill
- cqrsSkill
- domain-driven-designSkill
- event-drivenSkill
- event-sourcingSkill
- graphqlSkill
- grpcSkill
- hexagonalSkill
- microservicesSkill
- modular-monolithSkill
- monolithSkill
- rest-apiSkill
- sagaSkill
- serverlessSkill
- service-meshSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 132
Use incremental materialization with is_incremental():
- Very specific: line 153
Always use {{ ref('model_name') }} and {{ source('source_name', 'table_name') }} to maintain DAG lineage.
- Very specific: line 155
Run dbt test in CI pipelines on every pull request to catch data schema regressions.
- Very specific: line 159
Write raw database table references (e.g.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
dbt (Data Build Tool)
dbt manages data transformation in the warehouse using SQL. v2.0 introduces the Fusion Engine (Rust) for performance.
When to Use
- Analytics Engineering & Data Transformations: Transforming raw data inside modern cloud warehouses (Snowflake, BigQuery, Databricks, Redshift).
- Modular SQL with Jinja & Version Control: Building reusable SQL models with DAG dependencies and macros.
- Data Quality & Schema Testing: Enforcing
unique,not_null, referential integrity, and custom singular tests. - Automated Data Documentation & Lineage: Generating interactive dependency lineage graphs directly from codebase schemas.
Quick Start
-- models/marts/fct_orders.sql
{{ config(materialized='table') }}
with orders as (
select * from {{ ref('stg_orders') }}
),
payments as (
select * from {{ ref('stg_payments') }}
)
select
orders.order_id,
orders.customer_id,
orders.order_date,
coalesce(payments.amount, 0) as total_amount
from orders
left join payments using (order_id)Core Concepts
Declarative SQL Modeling with ref() & source()
Building transformation models with dependency resolution:
-- models/marts/core/fct_customer_orders.sql
{{
config(
materialized = 'incremental',
unique_key = 'order_id',
on_schema_change = 'fail'
)
}}
with orders as (
select * from {{ ref('stg_orders') }}
{% if is_incremental() %}
where order_date >= (select coalesce(max(order_date), '1970-01-01') from {{ this }})
{% endif %}
),
customers as (
select * from {{ ref('stg_customers') }}
)
select
o.order_id,
o.customer_id,
c.full_name as customer_name,
o.order_date,
o.total_amount_usd
from orders o
inner join customers c on o.customer_id = c.customer_idSchema Testing & Documentation in YAML
Enforcing column constraints and documentation:
# models/marts/core/schema.yml
version: 2
models:
- name: fct_customer_orders
description: "Daily customer order fact table combining staged orders and customer dimensions."
columns:
- name: order_id
description: "Primary key for orders."
tests:
- unique
- not_null
- name: customer_id
description: "Foreign key referencing staging customers."
tests:
- not_null
- relationships:
to: ref('stg_customers')
field: customer_id
- name: total_amount_usd
description: "Total transaction value in USD."
tests:
- not_nullJinja Macros for DRY Reusable Logic
Creating custom reusable SQL utilities:
-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name, decimal_places=2) -%}
round(cast(({{ column_name }} / 100.0) as numeric), {{ decimal_places }})
{%- endmacro %}
-- Usage in model:
select
id,
{{ cents_to_dollars('amount_in_cents') }} as amount_usd
from {{ ref('stg_payments') }}Common Patterns
Incremental Models with Timestamp Filtering
Problem: Rebuilding multi-billion-row tables from scratch on every dbt run is slow and expensive.
Solution:
Use incremental materialization with is_incremental():
{{ config(
materialized='incremental',
unique_key='event_id'
) }}
select * from {{ source('raw', 'events') }}
{% if is_incremental() %}
-- Only query rows created after the most recent event in the target table
where event_timestamp > (select max(event_timestamp) from {{ this }})
{% endif %}Best Practices
Do:
- Organize projects into standard layers:
staging(1-to-1 with raw sources),intermediate, andmarts. - Always use
{{ ref('model_name') }}and{{ source('source_name', 'table_name') }}to maintain DAG lineage. - Implement incremental models (
materialized='incremental') for multi-million row fact tables. - Run
dbt testin CI pipelines on every pull request to catch data schema regressions.
Don't:
- Write raw database table references (e.g.
analytics.raw.users); always usesource()orref(). - Perform business logic inside staging models; staging should only clean, cast, and rename columns.
- Hardcode environments (dev vs prod); use
target.nameconditionals in profiles.yml.
Troubleshooting
| Error | Cause | Solution |
Compilation Error: Model '...' depends on a node named '...' which was not found | Typo in {{ ref('model_name') }} or model file missing. | Check model filename matches referenced string exactly. |
dbt test failed: unique constraint violated | Duplicate keys generated by non-unique join condition. | Inspect duplicate keys in compiled SQL in target/compiled/. |
Schema change error during incremental run | Upstream model added/removed columns breaking existing incremental table. | Run with --full-refresh once to rebuild schema: dbt run --full-refresh. |
References
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

