using-dbt-wiki

name

using-dbt-wiki

description

Family-entry router for dbt-wiki — the knowledge base distilled from a dbt project (manifest + compiled SQL + column lineage) into .dbt-wiki/. Use when unsure which dbt-wiki skill applies: first-time setup, bringing the wiki up to date, asking a dbt question, or certifying pages. Triggers: 'dbt wiki', 'dbt 知識庫', 'dbt ドキュメント', '不知道該用哪個 dbt-wiki', 'どの dbt-wiki を使えばいい'. Do NOT use for an Obsidian vault wiki (obsidian:using-obsidian) or a source-repo wiki (repo-wiki).

Using dbt-wiki

Ask first: "Are you setting it up, updating it, reading it, or shipping it to someone else?" That answer picks the skill.

.dbt-wiki/ has two layers: an evidence layer (mechanical — manifest

• sqlglot lineage, no LLM) and a knowledge layer (LLM-distilled business meaning, human-certifiable). Most skills below touch one layer; update is the one that keeps both current.

Routing table

Setup — once per project

Skill	Use when
init	First time. Scaffolds .dbt-wiki/ from manifest.json + compiled/*.sql. Run dbt parse && dbt compile first.

Input — record what the manifest can't know

Skill	Use when
ingest	You want tribal knowledge on a model page — sort_key rationale, dialect gotchas, incident links. Survives every update.

Maintain — the main line

Skill	Use when
update	The default maintenance verb. "Bring my wiki up to date" after dbt models changed. One pass, every mechanical step: (optional) ingest a note you brought → rescan evidence → asks before spending on a re-distill (and only for pages whose evidence changed in meaning) → phantom-column lint gate (pages citing a column their model lacks) → hands you the review queue → scorecard. It stops where human judgment starts: it never certifies a page itself.
rescan	Advanced — update runs this for you. Reach for it alone only to refresh evidence with zero LLM cost and defer the semantic half.
redistill	Advanced — update runs this for you. Reach for it alone only when evidence is already current and you just want the stale knowledge pages rewritten.

Read — the payoff

Skill	Use when
query	Any dbt question: model structure, column lineage, config, refactor/rename impact, ingested notes. Use it before reading dbt/ files.

Certify — human in the loop

Skill	Use when
review	Pages start developing (LLM-written). A human reads and confirms → mature. Lists what needs review, prioritized by risk.

Export — hand it off

Skill	Use when
pack	Emit a portable, warehouse-agnostic analytics Agent Skill a teammate can use with their own warehouse tool — no dbt project required.

Quick Start

dbt parse && dbt compile     ← dbt's own step, not ours; init needs its output
        ↓
init → update → query → review
        ↑
   (ingest — any time after init, whenever you have a note)

• No .dbt-wiki/ yet? Every skill except init needs it to exist. They check on entry and send you back to init rather than guessing.
• New project: init (after dbt parse && dbt compile).
• Models changed: update. That is the whole answer — don't pick between rescan and redistill unless you are optimizing LLM cost.
• Someone asks a dbt question: query.
• Trust the pages enough to rely on them: review to certify.

Not this family

• Obsidian vault notes → obsidian:using-obsidian (wiki-* skills).
• A source-code repository's wiki → repo-wiki.
• dbt SQL style/authoring → dev-workflow:dbt-model-style.