dbt Model Style

Purpose & scope

An adoptable dbt + Redshift model writing-style template: once a team adopts it, every model anyone (or an agent) writes looks consistent, reads well, maintains easily, and parses cleanly for tooling. This is an opinionated default, not the only right answer — items tagged (adapt) (naming vocabulary, header schema, warehouse-persistence mechanism) are tuned per project; the remaining MUST/SHOULD rules are cross-project dbt good habits.

When it applies: whenever you author / edit / review any dbt model. Write comment text and frontmatter values in the user's working language (the examples in this doc stay in Chinese as a demonstration).

Style & structure only — not computation. This skill covers how CTEs are arranged, how columns are named, how comments are written, how JOINs are declared. It does not cover calculation logic, business rules, metric formulas, NULL/denominator semantics, or layer-dependency design — those are a separate matter, out of scope here.

When a request mixes style and logic (common — e.g. "fix the source-A→B fallback and tidy the final CTE"): do the style/structure part under this skill; for the calculation/business-rule part, name it explicitly and hand it back as out of scope — don't silently change computation, and don't refuse the whole request. Split the edit; don't let "I'm already in here" pull you across the boundary.

One boundary that genuinely blurs — name-vs-content. A few style rules can only be checked by glancing at the computation: the name-matches-content MUST (§3) says a __paid column must not smuggle in trial rows, so confirming the name matches what the column computes requires reading the logic. That read-to-verify-the-name is in scope; changing the computation to fix a mismatch is not — flag the mismatch and hand the logic fix back.

Rules come in four levels: