The .dinorules file allows you to define custom instructions and development standards to tailor how DinoAI responds to your prompts and questions. These rules are specific to your project and will apply to all DinoAI interactions within your environment.
.dinorules file is git-tracked by default
If you don't want this file git-tracked, see docs to disable.
Key Benefits
Define Project-Specific Rules: Customize DinoAI's behavior to match your team's unique needs and workflows.
Set Technical Standards: Specify coding patterns, architecture guidelines, and best practices for your project.
Adapt Over Time: Easily modify the rules as your project evolves and requirements change.
Team Collaboration: Files are git-tracked by default, enabling shared standards across your entire data team.
Setting Up .dinorules
From the Code IDE, Click the DinoAI icon (πͺ) icon on the right-side panel.
Click the settings icon (βοΈ) at the top right of the DinoAI panel
Click "Edit" in the .dinorules section to create file.
Alternatively, you manually add a .dinorules file in your project files
Make sure the .dinorules file is placed in the root directory of your repository
.dinorules file is git-trackedby default to enable seamless team collaboration on DinoAI configurations.
What This Means
.dinorules is be tracked by git automatically
You can commit, modify, and request reviews like any other file in your repository
Full change tracking and version history
Seamless team collaboration on AI configurations
Disabling Git Tracking
If you haven't agreed internally on rules/prompts: You may encounter a merge conflict when updating your branch. You can use Paradime to resolve it, but we recommend agreeing on common versions for the .dinorules file first.
To disable, simply add .dinorules to your .gitignore file.
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.