Custom Rules for DinoAI

The .dinorules file is a configuration file that lives in your project's root directory and provides custom instructions for DinoAI. This file isn't tracked by git and applies to all copilot chat interactions within your project, helping you maintain consistent development practices.

Key Benefits

• Define Project Rules: Create any custom instructions specific to your development needs

• Set Technical Standards: Specify your team's coding patterns, architecture, and best practices

• Control AI Behavior: Tailor how the AI assists with your code and documentation

• Adapt Over Time: Modify rules as your project evolves and requirements change

• Enhance Team Workflow: Establish consistent development practices across your team

Setup Instructions

1. From the Code IDE, navigate to your project's root directory and right click to open develop options.

2. Create a new file named .dinorules.

The .dinorules file should be placed in the root directory of your repository, not within the dbt project directory.

your-repository
├── dbt_project/
│   ├── staging/
│   └── marts/
├── macros/
├── seeds/
├── .dinorules              # .dinorules file location
├── README.md

1. Add your custom instructions (see example configuration). These rules can be generalized or hyper-specific, and they don't need to follow any specific syntax or structure.

Example .dinorules Configuration

You can provide the copilot with specific SQL and dbt™ best practices in the .dinorules file. DinoAI will produce responses that satisfy your rules.

The rules can be generalized or hyper-specific, and they don't need to follow any specific syntax or structure.

Example .dinorules file configuration

General Project Context
- Domain: E-commerce analytics
- Data Stack: dbt project using Snowflake
- Primary Goal: Provide accurate, reusable, and scalable answers to analytics engineering-related questions.


Modeling Guidelines
- Naming: Use `snake_case` for all model and column names.
- Structure: Assume models follow a `staging → marts` hierarchy.


Materialization Standards
- Staging Models: Typically materialized as views.
- Mart Models: Typically materialized as incremental.
- Performance Exceptions: Assume exceptions may exist for performance reasons.


SQL and dbt Best Practices
1. Trailing Commas: Always use trailing commas in `SELECT` statements for clean diffs.
2. SQL Keywords: Write all SQL keywords (`SELECT`, `FROM`, etc.) in uppercase.
3. snake_case: Consistently use `snake_case` for names.
4. CTEs: Use Common Table Expressions (CTEs) instead of subqueries for clarity.
5. Comments: Add comments to improve readability, especially for complex logic.


Testing Standards
- Schema Tests: Recommend `unique` and `not_null` tests for all primary keys and critical columns.
- Data Tests: Suggest data tests for key metrics and transformations to ensure quality.


Answering Style
1. Specificity: Tailor answers to dbt-specific workflows.
2. No Assumptions: Focus on answering questions without assuming the capability to execute code.
3. Best Practices: Default to dbt and analytics engineering best practices unless otherwise requested.


Documentation Standards
- Descriptive Naming: Recommend clear and descriptive names for models and columns.
- Comments: Suggest adding column comments to enhance data lineage clarity.
- schema.yml: Emphasize the importance of keeping `schema.yml` files updated.

Important Notes

• The file is environment-specific and not committed to version control

• Rules apply only to the specific project containing the file

• Changes do not work retroactively

• More specific rules lead to better AI assistance

• Regular updates help maintain alignment with evolving project needs