dbt-and-analytics-engineering

Name: dbt-and-analytics-engineering
Author: vaquarkhan

19stars4forks

How to install dbt-and-analytics-engineering?

vaquarkhan/data-engineering-agent-skills/dbt-and-analytics-engineering

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill dbt-and-analytics-engineering

Installs into the current project.

Summary

Guides agents through analytics engineering workflows with dbt. Use when building or modifying staging models, marts, tests, snapshots, documentation, exposures, or semantic-layer-facing models.

Files · 1

View on GitHub

SKILL.md

1	# dbt And Analytics Engineering
2
3	## Overview
4
5	Use this skill when the job is analytics engineering rather than raw ingestion. It helps agents build trustworthy `dbt` projects with clear layering, reusable models, tests, documentation, and publish-safe business definitions.
6
7	## When to Use
8
9	- creating or changing `dbt` models
10	- building staging, intermediate, or mart layers
11	- adding tests, snapshots, or exposures
12	- organizing business logic for analysts and BI tools
13	- preparing semantic-layer-friendly outputs
14
15	Do not use this to justify putting ingestion or orchestration logic inside `dbt`.
16
17	## Workflow
18
19	1. Confirm the model's role.
20	Decide whether it belongs in:
21	- staging
22	- intermediate
23	- marts
24	- snapshot or semantic-serving layers
25
26	2. Define the business grain and contract.
27	Capture:
28	- keys
29	- metric intent
30	- filter logic
31	- null handling
32	- freshness expectations
33
34	3. Add tests and documentation with the model.
35	Typical checks:
36	- unique
37	- not null
38	- relationships
39	- accepted values
40	- source freshness where relevant
41
42	4. Keep model boundaries clean.
43	Avoid mixing raw cleanup, business logic, and publish semantics in one model.
44
45	5. Validate downstream usability.
46	Make sure the output is understandable to analysts, dashboards, and metric consumers.
47
48	## Common Rationalizations
49
50	\| Rationalization \| Reality \|
51	\| --- \| --- \|
52	\| "It is only SQL, we do not need model structure." \| Poor layering creates brittle marts and duplicate business logic. \|
53	\| "We can add tests after the dashboard is working." \| Untested metrics create trust problems that are hard to unwind. \|
54	\| "A giant model is easier to maintain." \| Monolithic models hide grain changes, assumptions, and reuse opportunities. \|
55
56	## Red Flags
57
58	- model grain is unclear
59	- business logic is duplicated across marts
60	- no YAML tests or documentation accompany the change
61	- publish models depend directly on raw sources without clear staging
62
63	## Verification
64
65	- [ ] The model has a clear layer and business purpose
66	- [ ] Grain, keys, and metric assumptions are explicit
67	- [ ] Tests and documentation ship with the model
68	- [ ] Output usability for downstream consumers has been considered

People who liked this also viewed

6 picks

Type

dbt-and-analytics-engineering

19stars4forks

View on GitHub

How to install dbt-and-analytics-engineering?

vaquarkhan/data-engineering-agent-skills/dbt-and-analytics-engineering

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill dbt-and-analytics-engineering

Installs into the current project.

Summary

Guides agents through analytics engineering workflows with dbt. Use when building or modifying staging models, marts, tests, snapshots, documentation, exposures, or semantic-layer-facing models.

Files · 1

View on GitHub

SKILL.md

1	# dbt And Analytics Engineering
2
3	## Overview
4
5	Use this skill when the job is analytics engineering rather than raw ingestion. It helps agents build trustworthy `dbt` projects with clear layering, reusable models, tests, documentation, and publish-safe business definitions.
6
7	## When to Use
8
9	- creating or changing `dbt` models
10	- building staging, intermediate, or mart layers
11	- adding tests, snapshots, or exposures
12	- organizing business logic for analysts and BI tools
13	- preparing semantic-layer-friendly outputs
14
15	Do not use this to justify putting ingestion or orchestration logic inside `dbt`.
16
17	## Workflow
18
19	1. Confirm the model's role.
20	Decide whether it belongs in:
21	- staging
22	- intermediate
23	- marts
24	- snapshot or semantic-serving layers
25
26	2. Define the business grain and contract.
27	Capture:
28	- keys
29	- metric intent
30	- filter logic
31	- null handling
32	- freshness expectations
33
34	3. Add tests and documentation with the model.
35	Typical checks:
36	- unique
37	- not null
38	- relationships
39	- accepted values
40	- source freshness where relevant
41
42	4. Keep model boundaries clean.
43	Avoid mixing raw cleanup, business logic, and publish semantics in one model.
44
45	5. Validate downstream usability.
46	Make sure the output is understandable to analysts, dashboards, and metric consumers.
47
48	## Common Rationalizations
49
50	\| Rationalization \| Reality \|
51	\| --- \| --- \|
52	\| "It is only SQL, we do not need model structure." \| Poor layering creates brittle marts and duplicate business logic. \|
53	\| "We can add tests after the dashboard is working." \| Untested metrics create trust problems that are hard to unwind. \|
54	\| "A giant model is easier to maintain." \| Monolithic models hide grain changes, assumptions, and reuse opportunities. \|
55
56	## Red Flags
57
58	- model grain is unclear
59	- business logic is duplicated across marts
60	- no YAML tests or documentation accompany the change
61	- publish models depend directly on raw sources without clear staging
62
63	## Verification
64
65	- [ ] The model has a clear layer and business purpose
66	- [ ] Grain, keys, and metric assumptions are explicit
67	- [ ] Tests and documentation ship with the model
68	- [ ] Output usability for downstream consumers has been considered

People who liked this also viewed

6 picks

Type