Purpose
Inspect a dbt change set before it ships: identify which assets changed, estimate downstream impact, detect likely gaps in testing, contracts, documentation, and YAML alignment, and recommend the narrowest safe validation path. Preflight is read-only — do not edit code unless explicitly asked.
When to Use
- Before opening a PR in an analytics repository
- Reviewing someone else's dbt change
- Assessing the risk of a change whose downstream impact is unclear
Inputs
- The change set (branch diff or working tree)
- The dbt project, for lineage and selector queries
Workflow
Enumerate changed assets:
git diff --name-status origin/main...HEAD
Classify each change: models, snapshots, seeds, macros, tests, schema YAML, semantic models, metrics, saved queries, exposures or BI-facing assets.
Estimate blast radius. For each changed model, list downstream dependents:
dbt ls --select <model>+
If a production manifest is available, cover the whole change set at once:
dbt ls --select state:modified+ --state <path-to-prod-artifacts>
Run the review checklist. Check for:
- model grain changes
- renamed columns or breaking contract changes
- missing or weakened tests
- YAML not updated after model changes
- metrics or semantic definitions drifting from prior meaning
- high blast radius due to downstream dependencies
- incremental logic changes
- snapshot logic changes
- joins or filters that may alter business meaning
Recommend the narrowest meaningful validation path first:
- targeted checks:
dbt build --select <changed_model>
- narrow downstream checks:
dbt build --select <changed_model>+1
- broader PR-level validation only if needed:
dbt build --select state:modified+ --state <path>
If exact commands are available in the repo (Makefile, CI config, docs), prefer them. If not, say what should be validated conceptually.
Output
- changed assets summary
- likely blast radius
- likely missing checks or weak spots
- recommended validation plan
- items that need stakeholder or domain-owner confirmation
Verification
Failure Modes
- Style distraction — preflight is about correctness and semantic impact, not formatting.
- Overclaiming impact — be conservative with claims; verify lineage before asserting blast radius.
- Validating everything — defaulting to a full rebuild obscures which check actually covers the risk; the goal is the narrowest safe path.
- Editing instead of reporting — do not edit code unless explicitly asked.
1---2name: dbt-preflight3description: Use when a dbt change needs preflight before a PR, review, or merge -- changed models, snapshots, seeds, macros, or semantic YAML whose blast radius and test coverage are not yet known.4---56## Purpose78Inspect a dbt change set before it ships: identify which assets changed, estimate downstream impact, detect likely gaps in testing, contracts, documentation, and YAML alignment, and recommend the narrowest safe validation path. Preflight is read-only — do not edit code unless explicitly asked.910## When to Use1112- Before opening a PR in an analytics repository13- Reviewing someone else's dbt change14- Assessing the risk of a change whose downstream impact is unclear1516## Inputs1718- The change set (branch diff or working tree)19- The dbt project, for lineage and selector queries2021## Workflow22231. **Enumerate changed assets:**2425 ```bash26 git diff --name-status origin/main...HEAD27 ```2829 Classify each change: models, snapshots, seeds, macros, tests, schema YAML, semantic models, metrics, saved queries, exposures or BI-facing assets.30312. **Estimate blast radius.** For each changed model, list downstream dependents:3233 ```bash34 dbt ls --select <model>+35 ```3637 If a production manifest is available, cover the whole change set at once:3839 ```bash40 dbt ls --select state:modified+ --state <path-to-prod-artifacts>41 ```42433. **Run the review checklist.** Check for:44 - model grain changes45 - renamed columns or breaking contract changes46 - missing or weakened tests47 - YAML not updated after model changes48 - metrics or semantic definitions drifting from prior meaning49 - high blast radius due to downstream dependencies50 - incremental logic changes51 - snapshot logic changes52 - joins or filters that may alter business meaning53544. **Recommend the narrowest meaningful validation path first:**55 1. targeted checks: `dbt build --select <changed_model>`56 2. narrow downstream checks: `dbt build --select <changed_model>+1`57 3. broader PR-level validation only if needed: `dbt build --select state:modified+ --state <path>`5859 If exact commands are available in the repo (Makefile, CI config, docs), prefer them. If not, say what should be validated conceptually.6061## Output62631. changed assets summary642. likely blast radius653. likely missing checks or weak spots664. recommended validation plan675. items that need stakeholder or domain-owner confirmation6869## Verification7071- [ ] Every changed file classified by asset type72- [ ] Blast radius backed by lineage (`dbt ls`), not guessed73- [ ] Each checklist hit mapped to a recommended validation step74- [ ] Validation plan starts with the narrowest step that covers the risk75- [ ] Stakeholder-confirmation items listed separately7677## Failure Modes7879- **Style distraction** — preflight is about correctness and semantic impact, not formatting.80- **Overclaiming impact** — be conservative with claims; verify lineage before asserting blast radius.81- **Validating everything** — defaulting to a full rebuild obscures which check actually covers the risk; the goal is the narrowest safe path.82- **Editing instead of reporting** — do not edit code unless explicitly asked.
yeaight7