mit einem Klick
dbt-docs
// Document dbt models and columns in schema.yml with business context — model descriptions, column definitions, and doc blocks. Use when adding or improving documentation for discoverability. Powered by altimate-dbt.
// Document dbt models and columns in schema.yml with business context — model descriptions, column definitions, and doc blocks. Use when adding or improving documentation for discoverability. Powered by altimate-dbt.
REQUIRED before writing or modifying ANY dbt model. Invoke this skill FIRST whenever a task says "create", "build", "add", "modify", "update", "fix", or "refactor" a dbt model, staging file, mart, incremental, or snapshot. Skipping this skill is the leading cause of silent-correctness bugs — models that compile and `dbt build` cleanly but produce wrong values. It contains the patterns that prevent the most common such bugs encountered in real dbt projects: • Incremental high-water marks (`>=` vs `>` ties → silent row dropout) • Snapshot strategy selection (timestamp vs check, `unique_key` choice) • `LEFT JOIN + COUNT(*)` phantom rows from unmatched parents • Type harmonization in `COALESCE` / `CASE` / `UNION` legs • Date-spine completeness (every period present, even empty ones) • Off-by-one window boundaries (`BETWEEN d - (N-1) AND d` for N-wide) • Uniqueness enforcement when schema implies a key • Window-function `LIMIT` with deterministic tiebreaker • Verifying transformation correctness with dbt unit te
REQUIRED after building or modifying ANY dbt model that has columns declared in `schema.yml` / `_models.yml`. Run `altimate-dbt schema-verify --model <name>` to diff actual columns against the spec, and treat any `mismatch` verdict as "not done." The most common reason "the build is green but the tests still fail" is that the model produces the right *data values* in the wrong *column shape* — extra columns, missing columns, wrong order, wrong types. Many dbt equality tests grade the column tuple `(name, type, position)` exactly, and the agent's prior bias is to add "helpful" extras (`p1`/`p2`/`p3` rank breakdowns, name-resolved variants, lineage metadata) or reorder columns "more logically." Both break the contract. This skill enforces the mechanical check that catches those bugs before declaring done. Use it before declaring any model task complete.
Generate dbt unit tests automatically for any model. Analyzes SQL logic (CASE/WHEN, JOINs, window functions, NULLs), creates type-correct mock inputs from manifest schema, and assembles complete YAML. Use when a user says "generate tests", "add unit tests", "test this model", or "test coverage" for dbt models.
Validate that two tables or query results are identical — or diagnose exactly how they differ. Discover schema, identify keys, profile cheaply, then diff. Use for migration validation, ETL regression, and query refactor verification.
Add schema tests, unit tests, and data quality checks to dbt models. Use when validating data integrity, adding test definitions to schema.yml, writing unit tests, or practicing test-driven development in dbt. Powered by altimate-dbt.
Analyze downstream impact of dbt model changes using column-level lineage and the dependency graph. Use when evaluating the blast radius of a change before shipping. Powered by altimate-dbt.
| name | dbt-docs |
| description | Document dbt models and columns in schema.yml with business context — model descriptions, column definitions, and doc blocks. Use when adding or improving documentation for discoverability. Powered by altimate-dbt. |
Agent: builder or migrator (requires file write access)
Tools used: bash (runs altimate-dbt commands), read, glob, write, edit
Use when the user wants to:
Do NOT use for:
dbt-testdbt-developdbt-developaltimate-dbt columns --model <name> # what columns exist
altimate-dbt parents --model <name> # what feeds this model
altimate-dbt children --model <name> # who consumes it
altimate-dbt compile --model <name> # see the rendered SQL
Read the model SQL to understand the transformations:
glob models/**/<name>.sql
read <model_file>
Check what's already documented:
glob models/**/*schema*.yml models/**/*_models.yml
read <yaml_file>
See references/documentation-standards.md for quality guidelines.
Cover: What (business entity), Why (use case), How (key transforms), When (materialization).
- name: fct_daily_revenue
description: >
Daily revenue aggregation by product category. Joins staged orders with
product dimensions and calculates gross/net revenue. Materialized as
incremental with unique key on (date_day, category_id). Used by the
finance team for daily P&L reporting.
Describe business meaning, derivation formula, and caveats:
columns:
- name: net_revenue
description: >
Total revenue minus refunds and discounts for the day.
Formula: gross_revenue - refund_amount - discount_amount.
Can be negative if refunds exceed sales.
altimate-dbt compile --model <name> # ensure YAML is valid
| Mistake | Fix |
|---|---|
| Restating the column name as the description | "order_id: The order ID" → describe business meaning |
| Empty descriptions | Every column should have a description. If unsure, describe the source. |
| Not reading the SQL before documenting | Read the model to understand derivation logic |
| Duplicating descriptions across models | Use doc blocks for shared definitions |
| Writing implementation details instead of business context | Describe what it means to the business, not how it's computed |
| Guide | Use When |
|---|---|
| references/altimate-dbt-commands.md | Need the full CLI reference |
| references/documentation-standards.md | Writing high-quality descriptions |