dbt-patternslisted
Install: claude install-skill Methasit-Pun/data_engineer_claude_skills
# dbt Patterns for Analytics Engineering
## Model Layer Architecture
The most important design decision in a dbt project is how to organize model layers. A clear layer structure means every model has exactly one place it belongs, and anyone reading the project can understand what each model does.
```
models/
staging/ # 1:1 with source tables — rename, cast, light cleaning only
stg_salesforce__accounts.sql
stg_stripe__charges.sql
intermediate/ # business logic, joins, calculations — not exposed to BI
int_customer_lifetime_value.sql
int_churn_features.sql
marts/ # final business-facing tables, by domain
core/
dim_customers.sql
fct_subscriptions.sql
finance/
fct_revenue.sql
```
**Why layers matter:** Staging models are cheap to replace when sources change. Marts are stable surfaces for BI tools. Intermediate is where the hard logic lives — if it's complex, it belongs there, not in a mart. Never skip straight from raw source to mart.
---
## Staging Models
Staging models are one-to-one with source tables. Their only job is to standardize — rename columns to snake_case, cast types, and add trivial derived columns. No joins, no aggregations.
```sql
-- stg_stripe__charges.sql
WITH source AS (
SELECT * FROM {{ source('stripe', 'charges') }}
),
renamed AS (
SELECT
id AS charge_id,
customer AS customer_id,
amo