PluginBench
Skill
Review
Audit score 70

dbt-transformation-patterns

wshobson/agents

Master dbt model organization, testing, documentation, and incremental strategies for analytics engineering.

What is dbt-transformation-patterns?

dbt-transformation-patterns provides production-ready guidance for building data transformation pipelines using dbt (data build tool). Use this skill when organizing models into medallion architecture layers, implementing data quality tests, creating incremental models, and documenting data lineage.

  • Organize models into staging, intermediate, and marts layers following medallion architecture
  • Implement naming conventions for different model types (stg_, int_, dim_, fct_)
  • Set up dbt project structure with proper materialization strategies
  • Create and manage data quality tests (not null, unique, relationships)
  • Build incremental models for efficient processing of large datasets
  • Document data models and lineage with YAML descriptions

How to install dbt-transformation-patterns

npx skills add https://github.com/wshobson/agents --skill dbt-transformation-patterns
Claude Code
Cursor
Windsurf
Cline

How to use dbt-transformation-patterns

  1. 1.Review the medallion architecture pattern (sources → staging → intermediate → marts)
  2. 2.Configure dbt_project.yml with appropriate model paths, materialization settings, and variables
  3. 3.Create staging models with 1:1 mappings to source tables for light cleaning
  4. 4.Build intermediate models for business logic, joins, and aggregations
  5. 5.Create final mart tables (dimensions and facts) for analytics consumption
  6. 6.Implement tests at each layer (not null, unique, relationships)
  7. 7.Add YAML documentation for models and columns
  8. 8.Use incremental materialization for large tables with appropriate unique_key configuration

Use cases

Good for
  • Building data transformation pipelines from raw sources to analytics-ready tables
  • Organizing a multi-source dbt project with staging, intermediate, and mart layers
  • Implementing incremental models for tables with millions of rows to optimize run time
  • Setting up data quality tests to catch data issues early in the pipeline
  • Documenting data models and creating lineage documentation for stakeholders
Who it's for
  • Analytics engineers building data pipelines
  • Data engineers implementing dbt projects
  • Analytics teams setting up transformation infrastructure
  • Organizations standardizing data modeling practices

dbt-transformation-patterns FAQ

What is the medallion architecture and why use it?

The medallion architecture organizes models into layers: staging (1:1 with sources, light cleaning), intermediate (business logic and joins), and marts (final analytics tables). This approach enables reusability, maintainability, and clear separation of concerns.

When should I use incremental models?

Use incremental materialization for tables with more than 1 million rows to optimize run time and costs. Incremental models only process new or changed data after the initial full refresh.

What naming conventions should I follow?

Use prefixes: stg_ for staging models, int_ for intermediate models, and dim_/fct_ for dimensional and fact tables in marts. Include source system names (e.g., stg_stripe__payments).

How do I avoid repeating transformation logic?

Extract common logic into dbt macros and use them across multiple models. This reduces duplication and makes updates easier.

Should I test in production?

No, always use a dev target for testing and development. Reserve production for validated, tested transformations.

Full instructions (SKILL.md)

Source of truth, from wshobson/agents.


name: dbt-transformation-patterns description: 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.

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

LayerPrefixExample
Stagingstg_stg_stripe__payments
Intermediateint_int_payments_pivoted
Martsdim_, 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