Automated summary
This skill guides creating dbt model versions through the native `versions:` config instead of `_v2`-suffixed standalone copies.
Strengths
- Explains the exact YAML structure (`versions:`, `defined_in`, `latest_version`) with a concrete example
- Clearly separates a versioned node (`model.project.dim_customers.v2`) from a standalone `_v2` model
- Details how `ref()` resolves with or without version pinning for downstream models
- Provides a `dbt ls` command to confirm version nodes are registered
Limitations
- Assumes dbt-core 1.6 or newer and does not address earlier versions
- Does not cover version-level tests, model contracts, or intentional breaking changes
- The YAML sample in the document has inconsistent indentation that may mislead
Use it when a task asks for a dbt model v2 or a backward-compatible change that must keep existing `ref()` calls working.
Avoid it for deliberate breaking changes, full model rewrites, or dbt projects predating version 1.6.
Security analysis
SafeThe skill only instructs read and dbt CLI commands (dbt ls) within an allowed dbt scope; no destructive, network exfiltration, or obfuscated actions.
No concerns found
How this analysis is madeExamples
Create a v2 of dim_customers that renames account_status to customer_status, keeping v1 as the latest version for now.Update fct_orders to use version 2 of dim_customers while other models stay on the default version.Check that dim_customers is properly registered as versions v1 and v2 in dbt.name: dbt-versioning description: "Load when task involves dbt model versioning, creating v2 of a model, or backward-compatible model changes. Covers versions YAML config, defined_in, latest_version, and ref() with version pins." disable-model-invocation: false allowed-tools: Bash(dbt *)
dbt Model Versioning
1. Versioned Model vs Standalone Copy
When a task says "create a v2," "add a new version," or "backward-compatible change," use dbt's native versions: config (dbt-core 1.6+). Do NOT create a standalone model with a _v2 suffix - that produces a separate node (model.project.dim_customers_v2) instead of a version node (model.project.dim_customers.v2).
2. YAML Structure
Declare versions inside the model's .yml file under the model entry:
models:
- name: dim_customers
latest_version: 1
versions:
- v: 1
- v: 2
defined_in: dim_customers_v2
Rules:
versions:is a list ofv:entries inside themodels:block, under the model name.defined_in:maps a version to its SQL filename (without.sql). Omitdefined_inwhen the filename matches the default<model_name>_v<N>.sql.latest_version:controls which versionref('dim_customers')resolves to. If the task says "not yet the primary version," setlatest_versionto the old version number.
3. File Naming
Version SQL files use the pattern <model_name>_v<N>.sql.
dim_customers.sql- original model, becomes v1 implicitly.dim_customers_v2.sql- new version.
Do NOT rename or move the original SQL file. It remains v1 without changes.
4. How ref() Works with Versions
ref('dim_customers')resolves to whichever versionlatest_versionspecifies.ref('dim_customers', v=2)pins to version 2 regardless oflatest_version.
Downstream models that need the new version must use ref('dim_customers', v=2). Models using bare ref('dim_customers') continue to get the old version until latest_version is updated.
5. Writing the v2 SQL
Read the original model's SQL first. If the v2 only renames or adds columns, write a thin wrapper:
select
customer_id,
customer_name,
account_status as customer_status -- renamed column
from {{ ref('dim_customers', v=1) }}
Do NOT duplicate all upstream logic into the v2 file when a SELECT-with-renames suffices.
6. Verification
After creating the versioned model, run:
dbt ls --select dim_customers --output json
Confirm the output contains nodes model.<project>.dim_customers.v1 and model.<project>.dim_customers.v2. If these nodes are missing, the versions: YAML is wrong.
Rules
- NEVER create a standalone
_v2model withoutversions:YAML - dbt will not register it as a version. - NEVER rename or move the original SQL file when adding a new version.
- ALWAYS set
latest_versionexplicitly - omitting it defaults to the highest version number, which may break downstream refs. - ALWAYS read test files in
tests/before writing models - they reveal required dbt features the task may only hint at.
Prompt Engineering
Data & AI
Prompt engineering best practices and templates to maximize AI outputs.
Data Visualization
Data & AI
Generates data visualizations and charts tailored to your data.
RAG Architecture Setup
Data & AI
Setup guide for RAG (Retrieval-Augmented Generation) architectures.