@clipboard-health/ai-rules 1.6.2 → 1.6.3

package/datamodeling/AGENTS.md

@@ -16,7 +16,7 @@ Use the dbt-mcp server to:
 
 ## Querying Snowflake Data Warehouse (using Snowflake MCP)
 
-- When you need to answer data-related questions or obtain analytics by querying the Snowflake data warehouse, you should use the `mcp-cli` tool.
+- When you need to answer data-related questions or obtain analytics by querying the Snowflake data warehouse, please use the `snowflake` mcp tool.
 - When using the Snowflake MCP to run queries, you must set the database context properly in your queries. Use fully qualified table names or set the database context to avoid connection errors.
 - The `describe_object` tool in the Snowflake MCP has a bug where it misinterprets the target_object structure, treating the table name as a database name and causing 404 "database does not exist" errors. Use `run_snowflake_query` with "DESCRIBE TABLE" instead to get table schema information successfully.
 
@@ -80,10 +80,14 @@ Instead of using LIKE clauses or partial matching which can be imprecise.
 - README.md
 - models/DEVIN_ANALYST_MODEL_GUIDE.md
 - models/DEVIN_ANALYST_FOLDER_STRUCTURE.md
-  These define our modeling rules, patterns, and safety constraints.
+- .github/pull_request_template.md
+
+These define our modeling rules, patterns, and safety constraints.
 
 # Key best practices to follow
 
+- DEVIN ONLY: When running dbt commands in the data-modeling repository, always reuse the existing SNOWFLAKE_SCHEMA environment variable value that is already set. Do NOT replace it with a hardcoded value like "dbt_devin" - the SNOWFLAKE_SCHEMA is set to a unique per-session string and overwriting it will cause issues.
+- Use `dbt build` to verify your changes.
 - ALL dbt staging models must have strictly defined datatypes. Please Read the "Casting DBT Staging Model Datatype Heuristic" Knowledge we have. These datatypes need to defined in the yaml documentation too.
 - Use doc blocks for any YAML column descriptions that span across more than one model. Do NOT repeat descriptions for the same column - please reuse a doc-block!
 - When adding new fields to tables keep the original source field name format, but remove any custom field prefix (**c). For example assignment_type**c should be renamed to assignment_type. Please do not hallucinate the column field names as this is misleading for users.
@@ -91,6 +95,13 @@ Instead of using LIKE clauses or partial matching which can be imprecise.
 - A model must always have a primary/unique key. If there's no obvious one, please create a surrogate key using a combination of fields and by looking at the data. Use `dbt_utils.generate_surrogate_key` to do so.
 - Keep It Simple. Don't overcomplicate.
 
+# When creating PR's for the data-modeling repo
+
+- Read .github/pull_request_template.md. It contains the structure of how you would format the PR Description.
+- Under the **Validation of models** section in the PR Description, print the full table names of the dev models you've built, so it's easy for us to review the data.
+- Keep PR descriptions concise and focused. A reader should be able to quickly understand the intent and scope of the change.
+- Include the **dbt commands run** to validate the models.
+
 <!-- Source: .ruler/datamodeling/dbtYamlDocumentation.md -->
 
 # .yaml documentation rules

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@clipboard-health/ai-rules",
   "description": "Pre-built AI agent rules for consistent coding standards.",
-  "version": "1.6.2",
+  "version": "1.6.3",
   "bugs": "https://github.com/ClipboardHealth/core-utils/issues",
   "devDependencies": {
     "@intellectronica/ruler": "0.3.20"