dbt-transformation-patterns
A development tool for dbt that enforces analytics engineering best practices through model organization and testing patterns.
Install
mkdir -p .claude/skills/dbt-transformation-patterns && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/452" && unzip -o skill.zip -d .claude/skills/dbt-transformation-patterns && rm skill.zipInstalls to .claude/skills/dbt-transformation-patterns
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.
Master dbt (data build tool) for analytics engineering with model organization, testing, documentation, and incremental strategies. Use when building data transformations, creating data models, or implementing analytics engineering best practices.Key capabilities
- →Organize models into staging, intermediate, and marts layers
- →Implement data quality tests for nulls, uniqueness, and relationships
- →Configure incremental model strategies for large datasets
- →Define project structure using dbt_project.yml
- →Document model lineage and column descriptions
How it works
It organizes data pipelines into a medallion architecture, separating raw sources from cleaned staging, business-logic intermediate, and final marts layers.
Inputs & outputs
When to use dbt-transformation-patterns
- →Implementing medallion architecture in dbt
- →Adding data quality tests to models
- →Structuring new analytics projects
- →Setting up incremental model strategies
About this skill
dbt Transformation Patterns
Production-ready patterns for dbt (data build tool) including model organization, testing strategies, documentation, and incremental processing.
When to Use This Skill
- Building data transformation pipelines with dbt
- Organizing models into staging, intermediate, and marts layers
- Implementing data quality tests
- Creating incremental models for large datasets
- Documenting data models and lineage
- Setting up dbt project structure
Core Concepts
1. Model Layers (Medallion Architecture)
sources/ Raw data definitions
↓
staging/ 1:1 with source, light cleaning
↓
intermediate/ Business logic, joins, aggregations
↓
marts/ Final analytics tables
2. Naming Conventions
| Layer | Prefix | Example |
|---|---|---|
| Staging | stg_ | stg_stripe__payments |
| Intermediate | int_ | int_payments_pivoted |
| Marts | dim_, fct_ | dim_customers, fct_orders |
Quick Start
# dbt_project.yml
name: "analytics"
version: "1.0.0"
profile: "analytics"
model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
vars:
start_date: "2020-01-01"
models:
analytics:
staging:
+materialized: view
+schema: staging
intermediate:
+materialized: ephemeral
marts:
+materialized: table
+schema: analytics
# Project structure
models/
├── staging/
│ ├── stripe/
│ │ ├── _stripe__sources.yml
│ │ ├── _stripe__models.yml
│ │ ├── stg_stripe__customers.sql
│ │ └── stg_stripe__payments.sql
│ └── shopify/
│ ├── _shopify__sources.yml
│ └── stg_shopify__orders.sql
├── intermediate/
│ └── finance/
│ └── int_payments_pivoted.sql
└── marts/
├── core/
│ ├── _core__models.yml
│ ├── dim_customers.sql
│ └── fct_orders.sql
└── finance/
└── fct_revenue.sql
Detailed patterns and worked examples
Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.
Best Practices
Do's
- Use staging layer - Clean data once, use everywhere
- Test aggressively - Not null, unique, relationships
- Document everything - Column descriptions, model descriptions
- Use incremental - For tables > 1M rows
- Version control - dbt project in Git
Don'ts
- Don't skip staging - Raw → mart is tech debt
- Don't hardcode dates - Use
{{ var('start_date') }} - Don't repeat logic - Extract to macros
- Don't test in prod - Use dev target
- Don't ignore freshness - Monitor source data
When not to use it
- →When skipping the staging layer for raw data
- →When hardcoding dates instead of using variables
- →When testing in production environments
Prerequisites
Limitations
- →Requires incremental strategies for tables exceeding 1 million rows
- →Staging layer is mandatory to avoid technical debt
How it compares
It enforces a standardized directory structure and naming convention compared to ad-hoc SQL script management.
Compared to similar skills
dbt-transformation-patterns side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| dbt-transformation-patterns (this skill) | 6 | 2mo | No flags | Intermediate |
| embu-data-audit | 0 | 3mo | Review | Intermediate |
| interface-lint | 1 | 7mo | Review | Intermediate |
| code-review | 0 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by wshobson
View all by wshobson →You might also like
embu-data-audit
murzoglu
Audit active EMBU data pipeline decisions in the doktoratezi repository. Use when working on EMBU, EMBU-C, EMBU-P, Likert 4pt/6pt, Stage 1, Stage 2, Stage 3, family matching, outliers, ICC, CFA, mixed Likert families, find_embu_columns, PII removal, or EMBU v2.0 validation.
interface-lint
Layr-Labs
Format and lint Solidity interface files following EigenLayer conventions. Use when the user asks to format an interface, add documentation to an interface, or create a new interface. Ensures proper organization with Errors/Events/Types sub-interfaces.
code-review
jonatron55
Instructions for reviewing changes and ensuring quality before completion. Use when asking for a review or before committing changes.
analyse-issue
monarch-initiative
Analyze MONDO GitHub issues for validity, suggest improvements, and generate structured reports with duplication checks and identifier validation
reconciliation
anthropics
Reconcile accounts by comparing GL balances to subledgers, bank statements, or third-party data. Use when performing bank reconciliations, GL-to-subledger recs, intercompany reconciliations, or identifying and categorizing reconciling items.
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.