dbt Model Index
When to Use
- Before writing any BigQuery SQL against production data
- When the task has not already explicitly stated which models/tables to query
- When resolving a vague or ambiguous data question into the right BigQuery tables
How to Set Up This Skill
This skill is a curated index of your dbt models. Each entry describes a model (a BigQuery table), what it contains, and what types of questions it is best suited to answer.
To customize this index for your project:
- Organize models into logical domain sections (e.g., Users, Activity, Revenue, Events)
- For each model, include: the table name, a 1–2 sentence description of its grain and content, and "Useful for:" bullets covering common query patterns
- Note key join keys, standard filters, and partition fields where relevant
[Domain: e.g., Users & Identity]
your_model_name
Brief description of what this model contains. One row per [entity]. Include what makes this model's grain unique and the most important fields.
Useful for:
- [Type of question this model answers, e.g., user counts, cohort sizes]
- [Another use case, e.g., filtering to a specific user segment]
- [Common join pattern, e.g., joining to other tables as the canonical user dimension]
another_model_name
Description of this model and its grain.
Useful for: [Brief use case description]
[Domain: e.g., Activity & Engagement]
your_activity_model
Description of the activity signal (e.g., what counts as "active"), the grain, and the time dimension.
Useful for:
- [Use case 1, e.g., daily/weekly active user metrics]
- [Use case 2, e.g., retention analysis]
your_engagement_model
Description.
Useful for:
- [Use case 1]
- [Use case 2]
[Domain: e.g., Revenue & Subscriptions]
your_revenue_model
Description of the revenue grain (e.g., one row per customer per day, or one row per subscription event).
Useful for:
- [Use case 1, e.g., MRR/ARR reporting]
- [Use case 2, e.g., churn analysis]
your_subscription_model
Description.
Useful for:
- [Use case 1]
- [Use case 2]
[Domain: e.g., Events & Telemetry]
your_events_model
Description of the event source, enrichment applied, and key fields available.
Useful for:
- [Use case 1, e.g., raw event-level analysis]
- [Use case 2, e.g., building domain-specific funnels]
Important Notes
- Standard filters: Document any filters that should always be applied in user-facing queries (e.g., excluding test accounts, soft-deleted records, internal users, or flagged/fraudulent users). Example:
where not is_internal_user
- Production data: Specify your default project/dataset path. Example:
your-gcp-project.prod.<model_name>
- Cost control: For large partitioned tables, always filter on the partition field and constrain the date range to avoid full-table scans
- Model grain: Always note the grain (one row per what?) for each model to avoid accidental fan-outs in joins
- Plan/tier types: If your product has subscription tiers or plan types, document the valid values here so queries filter correctly
- Sensitive datasets: If any models live in a separate dataset, call that out explicitly so queries use the right fully-qualified table reference
1---2name: dbt-model-index3description: Provide a lookup index of dbt models (BigQuery tables) to guide query writing against a data warehouse. Use when you need to query, analyze, or look up data in a dbt-powered data warehouse, or when resolving a vague data question into the right BigQuery tables to query.4---5
6# dbt Model Index
7
8## When to Use
9
10- Before writing any BigQuery SQL against production data
11- When the task has not already explicitly stated which models/tables to query
12- When resolving a vague or ambiguous data question into the right BigQuery tables
13
14## How to Set Up This Skill
15
16This skill is a curated index of your dbt models. Each entry describes a model (a BigQuery table), what it contains, and what types of questions it is best suited to answer.
17
18To customize this index for your project:
19- Organize models into logical domain sections (e.g., Users, Activity, Revenue, Events)
20- For each model, include: the table name, a 1–2 sentence description of its grain and content, and "Useful for:" bullets covering common query patterns
21- Note key join keys, standard filters, and partition fields where relevant
22
23---
24
25## [Domain: e.g., Users & Identity]
26
27### `your_model_name`
28
29Brief description of what this model contains. One row per [entity]. Include what makes this model's grain unique and the most important fields.
30
31**Useful for:**
32
33- [Type of question this model answers, e.g., user counts, cohort sizes]
34- [Another use case, e.g., filtering to a specific user segment]
35- [Common join pattern, e.g., joining to other tables as the canonical user dimension]
36
37---
38
39### `another_model_name`
40
41Description of this model and its grain.
42
43**Useful for:** [Brief use case description]
44
45---
46
47## [Domain: e.g., Activity & Engagement]
48
49### `your_activity_model`
50
51Description of the activity signal (e.g., what counts as "active"), the grain, and the time dimension.
52
53**Useful for:**
54
55- [Use case 1, e.g., daily/weekly active user metrics]
56- [Use case 2, e.g., retention analysis]
57
58---
59
60### `your_engagement_model`
61
62Description.
63
64**Useful for:**
65
66- [Use case 1]
67- [Use case 2]
68
69---
70
71## [Domain: e.g., Revenue & Subscriptions]
72
73### `your_revenue_model`
74
75Description of the revenue grain (e.g., one row per customer per day, or one row per subscription event).
76
77**Useful for:**
78
79- [Use case 1, e.g., MRR/ARR reporting]
80- [Use case 2, e.g., churn analysis]
81
82---
83
84### `your_subscription_model`
85
86Description.
87
88**Useful for:**
89
90- [Use case 1]
91- [Use case 2]
92
93---
94
95## [Domain: e.g., Events & Telemetry]
96
97### `your_events_model`
98
99Description of the event source, enrichment applied, and key fields available.
100
101**Useful for:**
102
103- [Use case 1, e.g., raw event-level analysis]
104- [Use case 2, e.g., building domain-specific funnels]
105
106---
107
108## Important Notes
109
110- **Standard filters:** Document any filters that should always be applied in user-facing queries (e.g., excluding test accounts, soft-deleted records, internal users, or flagged/fraudulent users). Example: `where not is_internal_user`
111- **Production data:** Specify your default project/dataset path. Example: `your-gcp-project.prod.<model_name>`
112- **Cost control:** For large partitioned tables, always filter on the partition field and constrain the date range to avoid full-table scans
113- **Model grain:** Always note the grain (one row per _what_?) for each model to avoid accidental fan-outs in joins
114- **Plan/tier types:** If your product has subscription tiers or plan types, document the valid values here so queries filter correctly
115- **Sensitive datasets:** If any models live in a separate dataset, call that out explicitly so queries use the right fully-qualified table reference
warpdotdev