effective-dbt-sql

Writes semantically correct dbt model SQL using CTEs, explicit joins, and field reuse.

6.1k|768|Updated Mar 19, 2021
One-click install
npx skills add https://github.com/lightdash/lightdash --skill effective-dbt-sql
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: effective-dbt-sql
Source: https://github.com/lightdash/lightdash/tree/main/skills/effective-dbt-sql
Command: npx skills add https://github.com/lightdash/lightdash --skill effective-dbt-sql

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

When writing or modifying dbt model SQL, it is easy to produce semantically wrong queries: correlated subqueries that recompute values per row, recomputed metrics that diverge from existing definitions, implicit joins that silently fan out rows, and select * statements that break when upstream models change. This Skill encodes the SQL semantic-correctness rules that prevent those mistakes.

Core Features & Use Cases

  • Reuse before re-deriving: Checks existing dimensions and metrics on a model and composes them instead of writing new SQL that recomputes the same value.
  • CTE pipeline structure: Structures queries as named CTEs referenced in sequence, banning correlated subqueries and preferring aggregated CTE joins.
  • Explicit joins and columns: Enforces stated join types with on conditions and named column lists so upstream changes cannot silently alter model output.
  • Use Case: When asked to add an average order value metric to a model that already has total_revenue and order_count, the Skill composes the two existing metrics rather than writing a fresh subquery against raw rows.

Quick Start

Ask the assistant to add a new metric or modify the SQL of a dbt model, and it will apply these semantic rules while matching the repo's existing conventions.

Frequently Asked Questions about effective-dbt-sql

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write dbt model SQL without correlated subqueries?

Replace per-row correlated subqueries with an aggregated CTE that is joined back to the main query. Aggregate once in a named CTE grouped by the join key, then left join it, which is faster, more readable, and explicit about grain.

How should I structure a dbt model query with CTEs?

Structure the model as a pipeline of named CTEs where each does one job and is referenced by the next, ending in a single final select. This makes each step independently readable and keeps the grain explicit at every stage.

When should I reuse an existing dbt metric instead of writing new SQL?

Reuse existing fields whenever the requested value is already expressed by a dimension or metric, or by combining two of them, such as ratios and rates. Only write new base SQL when the value genuinely is not modelled yet.

Does this skill cover dbt naming and formatting conventions?

No, it covers SQL semantics only and does not prescribe naming schemes, file layout, or indentation. You should match the target repository's established conventions, and casting rules are delegated to a separate warehouse skill.

Why is select star discouraged in dbt models?

Selecting explicit named columns prevents an upstream model change from silently altering this model's output. A pass-through select star from a final CTE is acceptable because the columns are already pinned by the preceding CTEs.