using-dbt-for-analytics-engineering

Name: using-dbt-for-analytics-engineering
Author: dbt-labs

666installs55forks

How to install using-dbt-for-analytics-engineering?

dbt-labs/dbt-agent-skills/using-dbt-for-analytics-engineering

$npx -y skills add dbt-labs/dbt-agent-skills --skill using-dbt-for-analytics-engineering

Installs into the current project.

Summary

Builds and modifies dbt models, writes SQL transformations using ref() and source(), creates tests, and validates results with dbt show. Use when doing any dbt work - building or modifying models, debugging errors, exploring unfamiliar data sources, writing tests, or evaluating i

Files · 1

View on GitHub

SKILL.md

1	# Using dbt for Analytics Engineering
2
3	Core principle: Apply software engineering discipline (DRY, modularity, testing) to data transformation work through dbt's abstraction layer.
4
5	STOP — is this a breaking change to a model with consumers? Renaming, removing, or retyping a column — on a model that downstream models, exposures, or external/BI consumers depend on — is a breaking change. Do not edit it in place (that breaks those consumers the moment it deploys). REQUIRED SUB-SKILL: Use the `working-with-dbt-mesh` skill to roll it out with model versions (and a latest version pointer) so consumers get a migration window. Come back here for the SQL once the versioning approach is decided.
6
7	## When to Use
8
9	- Building new dbt models, sources, or tests
10	- Modifying existing model logic or configurations
11	- Refactoring a dbt project structure
12	- Creating analytics pipelines or data transformations
13	- Working with warehouse data that needs modeling
14
15	Do NOT use for:
16
17	- Querying the semantic layer (use the `answering-natural-language-questions-with-dbt` skill)
18	- Breaking changes to a model with consumers (column rename/remove/retype) — use the `working-with-dbt-mesh` skill to version the model instead of editing in place
19
20	## Reference Guides
21
22	This skill includes detailed reference guides for specific techniques. Read the relevant guide when needed:
23
24	\| Guide \| Use When \|
25	\|-------\|----------\|
26	\| [references/planning-dbt-models.md](references/planning-dbt-models.md) \| Building new models - work backwards from desired output and use `dbt show` to validate results \|
27	\| [references/discovering-data.md](references/discovering-data.md) \| Exploring unfamiliar sources or onboarding to a project \|
28	\| [references/writing-data-tests.md](references/writing-data-tests.md) \| Adding tests - prioritize high-value tests over exhaustive coverage \|
29	\| [references/debugging-dbt-errors.md](references/debugging-dbt-errors.md) \| Fixing project parsing, compilation, or database errors \|
30	\| [references/evaluating-impact-of-a-dbt-model-change.md](references/evaluating-impact-of-a-dbt-model-change.md) \| Assessing downstream effects before modifying models \|
31	\| [references/writing-documentation.md](references/writing-documentation.md) \| Write documentation that doesn't just restate the column name \|
32	\| [references/managing-packages.md](references/managing-packages.md) \| Installing and managing dbt packages \|
33
34	## DAG building guidelines
35
36	- Conform to the existing style of a project (medallion layers, stage/intermediate/mart, etc)
37	- Focus heavily on DRY principles.
38	- Before adding a new model or column, always be sure that the same logic isn't already defined elsewhere that can be used.
39	- Prefer a change that requires you to add one column to an existing intermediate model over adding an entire additional model to the project.
40
41	When users request new models: Always ask "why a new model vs extending existing?" before proceeding. Legitimate reasons exist (different grain, precalculation for performance), but users often request new models out of habit. Your job is to surface the tradeoff, not blindly comply.
42
43	## Model building guidelines
44
45	- Always use data modelling best practices when working in a project
46	- Follow dbt best practices in code:
47	- Always use `{{ ref }}` and `{{ source }}` over hardcoded table names
48	- Use CTEs over subqueries
49	- Before building a model, follow [references/planning-dbt-models.md](references/planning-dbt-models.md) to plan your approach.
50	- Before modifying or building on existing models, read their YAML documentation:
51	- Find the model's YAML file (can be any `.yml` or `.yaml` file in the models directory, but normally colocated with the SQL file)
52	- Check the model's `description` to understand its purpose
53	- Read column-level `description` fields to understand what each column represents
54	- Review any `meta` properties that document business logic or ownership
55	- This context prevents misusing columns or duplicating existing logic
56
57	## You must look at the data to be able to correctly model the data
58
59	When implementing a model, you must use `dbt show` regularly to:
60	- preview the input data you will work with, so that you use relevant columns and values
61	- preview the results of your model, so that you know your work is correct
62	- run basic data profiling (counts, min, max, nulls) of input and output data, to check for misconfigured joins or other logic errors
63
64	## Handling external data
65
66	When processing results fro

People who liked this also viewed

6 picks

Type

using-dbt-for-analytics-engineering

666installs55forks

View on GitHub

How to install using-dbt-for-analytics-engineering?

dbt-labs/dbt-agent-skills/using-dbt-for-analytics-engineering

$npx -y skills add dbt-labs/dbt-agent-skills --skill using-dbt-for-analytics-engineering

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Using dbt for Analytics Engineering
2
3	Core principle: Apply software engineering discipline (DRY, modularity, testing) to data transformation work through dbt's abstraction layer.
4
5	STOP — is this a breaking change to a model with consumers? Renaming, removing, or retyping a column — on a model that downstream models, exposures, or external/BI consumers depend on — is a breaking change. Do not edit it in place (that breaks those consumers the moment it deploys). REQUIRED SUB-SKILL: Use the `working-with-dbt-mesh` skill to roll it out with model versions (and a latest version pointer) so consumers get a migration window. Come back here for the SQL once the versioning approach is decided.
6
7	## When to Use
8
9	- Building new dbt models, sources, or tests
10	- Modifying existing model logic or configurations
11	- Refactoring a dbt project structure
12	- Creating analytics pipelines or data transformations
13	- Working with warehouse data that needs modeling
14
15	Do NOT use for:
16
17	- Querying the semantic layer (use the `answering-natural-language-questions-with-dbt` skill)
18	- Breaking changes to a model with consumers (column rename/remove/retype) — use the `working-with-dbt-mesh` skill to version the model instead of editing in place
19
20	## Reference Guides
21
22	This skill includes detailed reference guides for specific techniques. Read the relevant guide when needed:
23
24	\| Guide \| Use When \|
25	\|-------\|----------\|
26	\| [references/planning-dbt-models.md](references/planning-dbt-models.md) \| Building new models - work backwards from desired output and use `dbt show` to validate results \|
27	\| [references/discovering-data.md](references/discovering-data.md) \| Exploring unfamiliar sources or onboarding to a project \|
28	\| [references/writing-data-tests.md](references/writing-data-tests.md) \| Adding tests - prioritize high-value tests over exhaustive coverage \|
29	\| [references/debugging-dbt-errors.md](references/debugging-dbt-errors.md) \| Fixing project parsing, compilation, or database errors \|
30	\| [references/evaluating-impact-of-a-dbt-model-change.md](references/evaluating-impact-of-a-dbt-model-change.md) \| Assessing downstream effects before modifying models \|
31	\| [references/writing-documentation.md](references/writing-documentation.md) \| Write documentation that doesn't just restate the column name \|
32	\| [references/managing-packages.md](references/managing-packages.md) \| Installing and managing dbt packages \|
33
34	## DAG building guidelines
35
36	- Conform to the existing style of a project (medallion layers, stage/intermediate/mart, etc)
37	- Focus heavily on DRY principles.
38	- Before adding a new model or column, always be sure that the same logic isn't already defined elsewhere that can be used.
39	- Prefer a change that requires you to add one column to an existing intermediate model over adding an entire additional model to the project.
40
41	When users request new models: Always ask "why a new model vs extending existing?" before proceeding. Legitimate reasons exist (different grain, precalculation for performance), but users often request new models out of habit. Your job is to surface the tradeoff, not blindly comply.
42
43	## Model building guidelines
44
45	- Always use data modelling best practices when working in a project
46	- Follow dbt best practices in code:
47	- Always use `{{ ref }}` and `{{ source }}` over hardcoded table names
48	- Use CTEs over subqueries
49	- Before building a model, follow [references/planning-dbt-models.md](references/planning-dbt-models.md) to plan your approach.
50	- Before modifying or building on existing models, read their YAML documentation:
51	- Find the model's YAML file (can be any `.yml` or `.yaml` file in the models directory, but normally colocated with the SQL file)
52	- Check the model's `description` to understand its purpose
53	- Read column-level `description` fields to understand what each column represents
54	- Review any `meta` properties that document business logic or ownership
55	- This context prevents misusing columns or duplicating existing logic
56
57	## You must look at the data to be able to correctly model the data
58
59	When implementing a model, you must use `dbt show` regularly to:
60	- preview the input data you will work with, so that you use relevant columns and values
61	- preview the results of your model, so that you know your work is correct
62	- run basic data profiling (counts, min, max, nulls) of input and output data, to check for misconfigured joins or other logic errors
63
64	## Handling external data
65
66	When processing results fro

People who liked this also viewed

6 picks

Type