What this prompt does
This prompt asks the model to act as a senior analytics engineer setting up a fresh dbt project and to define standards a team will actually follow -- not a 40-page style guide nobody reads. You supply [warehouse], [team_size], and [sources], and it returns conventions for layout, naming, testing, documentation, performance, and CI tuned to that context.
The structure works because it ties abstract "best practices" to your real constraints. [team_size] controls how heavy the process should be -- a 3-person team needs lighter ceremony than twenty analysts. [warehouse] shapes materialization and incremental advice, since cost and performance tradeoffs differ across BigQuery, Snowflake, and Redshift. [sources] grounds the staging layer in your actual raw tables. By forcing concrete examples and a PR checklist, the prompt produces something enforceable rather than aspirational, and the example models give the team patterns to copy instead of rules to memorize.
When to use it
- You're starting a new dbt project and want conventions set before the first model lands.
- An existing project has drifted -- every analyst names things differently and trust is eroding.
- You need a staging/intermediate/marts split with clear rules for what belongs where.
- You want a short, real PR-review checklist instead of a doc nobody reads.
- You're onboarding analysts and need naming and testing standards written down once.
- You want guidance on when to go incremental and how to tag models for selective runs.
- You need exposures defined so downstream dashboards are documented as first-class consumers.
Example output
You get a starter directory tree, two example models -- one staging and one mart -- each with tests and docs attached, and a one-page PR-review checklist. The standards cover the layer layout, stg_/int_/fct_/dim_ naming, mandatory vs nice-to-have tests, source freshness checks, exposures, materialization choices, and slim CI on PRs. It reads as a blueprint you can commit to the repo and start working against, not an essay you skim once and forget.
Pro tips
- Set
[team_size]honestly; a smaller team should get lighter process, and the prompt calibrates ceremony to it. - Make
[warehouse]specific because incremental and materialization advice depends on its cost model. - List your real
[sources](e.g.Postgres app DB, Stripe, GA4) so the staging examples map to tables you actually have. - Keep the generated PR checklist short -- if it balloons, ask the model to cut it to the items that catch the most real mistakes.
- Ask it to mark which tests are mandatory (unique, not_null, relationships) versus optional so reviewers don't argue every PR.
- Adopt the slim CI suggestion (
state:modified+) early so PR runs stay fast as the project grows. - Add exposures for the dashboards built on top so a model change flags what it might break downstream.
