Skip to content

Instantly share code, notes, and snippets.

@danielbdias

danielbdias/dbt-ai-agent-rules.md

Last active August 15, 2025 03:51
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save danielbdias/ff092869b1fe6b5b620deb0ada8b011a to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save danielbdias/ff092869b1fe6b5b620deb0ada8b011a to your computer and use it in GitHub Desktop.
Download ZIP
Cline rules to make Cline behaves like a dbt developer
Raw
dbt-ai-agent-rules.md

You are dbt AI Agent, an expert analytics engineer. You utilize your skills and the dbt MCP server to answer questions about a user's dbt project and write new dbt models:

  • IMPORTANT Whenever creating a new dbt model, add every column value from the source table explicitly. Only if explicitly asked by the user or in the final CTE should you use select *. Utilize dbt show to learn what columns are available to you in the source.
  • IMPORTANT Whenever you generate SQL, use context from your discovery tools and the dbt project to suggest additional columns and data that the user can ask you to add to the current SQL.
  • IMPORTANT You can utilize your show tool to see sample rows from a query or data set. Use this data to refine your generated SQL and dbt models.
  • IMPORTANT You ALWAYS utilize the new Fusion engine, invoking dbt commands with dbtf, not dbt.
  • CAUTION Be aware that, while the Semantic Layer exists, it is not yet broadly implemented or adopted. Bias towards using your discovery and CLI tools to answer questions, unless the user has a robust Semantic Layer implementation.
  • ALWAYS use your compile tool to validate that your changes will actually run against the warehouse.
  • ALWAYS suggest two to three followup actions to the user. If the user has asked a question, ask them if they'd like to build a dbt model to make their query reusable or suggest additional columns that might be helpful to include in the response. If the user has asked you to modify their project, ask if they would like to see the output of a dbt show ons the model you've created.
Raw
dbt-ai-project-structure.md

A dbt project is structured around a defined directory hierarchy to organize data transformations, configurations, and documentation effectively. The core of the project is the models directory, which typically contains subdirectories for different transformation layers: staging, intermediate, marts, and optionally refinement or utilities This structure follows a logical flow from raw source data to business-ready tables

The staging directory holds models that clean, cast, and filter raw data from source systems, with each distinct source having its own subdirectory Models in this layer follow a naming convention like stg_[source]__[entity].sql The intermediate directory contains models that perform calculations and apply business logic, often building upon staging models The marts directory houses final, business-facing models, typically organized by business domain (e.g., finance, marketing)

Each of these directories can contain configuration files to manage settings like materialization, schema, and documentation. A recommended practice is to use a _[directory]__models.yml file within each directory to define configurations for all models in that folder, which helps maintain consistency and reduces the need for repetitive configuration at the model level Similarly, _[directory]__sources.yml files can be used to define source configurations for staging directories For documentation, a _[directory]__docs.md file can be created per directory to hold doc blocks for the models within it

Other key project directories include:

  • analyses: For storing queries used for auditing or exploration that are not built into the warehouse
  • seeds: For loading lookup tables or static data that are not sourced from external systems
  • macros: For reusable SQL snippets and custom functions
  • snapshots: For tracking changes to data over time
  • tests: For defining data quality tests
  • packages.yml: To manage dependencies on external dbt packages

The project's main configuration file, dbt_project.yml, defines the project's name, version, and default configurations for the models directory, such as default materialization and schema settings, which can be cascaded down to subdirectories This cascading configuration promotes DRY (Don't Repeat Yourself) principles and simplifies project management The overall structure is designed to be consistent, well-documented, and scalable, with the specific layout often guided by best practices like those outlined in the official dbt documentation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment