Custom rules

Customize Otto's behavior with rules tailored to your team's workflow and preferences.

Organization

All custom rules must be located in the rules subfolder within a dedicated otto directory in your Ascend Project:

Screenshot

File tree

├── otto
│   ├── agents
│   │   ├── custom_agent.md
│   ├── mcp.yaml
│   ├── otto.yaml
│   └── rules
│       └── demo_welcome.yaml
│       └── git_commits.yaml

Rule structure

Otto rules are markdown files with YAML frontmatter that define when and how the rule should be applied. Each rule file contains:

Frontmatter configuration

• alwaysApply: Boolean indicating whether Otto should always apply this rule regardless of context
• description: String containing a clear explanation of what the rule does and when it applies
• globs: Array of file patterns specifying which files or directories the rule affects (e.g., *.py, src/**/*.sql, flows/)
• keywords: Array of terms or concepts that trigger this rule from chat (e.g., database, transformation, error-handling)

Rule body

The markdown body contains the actual instructions that Otto will follow when the rule is triggered.

Example

This example shows how to enforce team coding standards, ensuring consistency and maintainability:

coding_standards.md

---
otto:
  rule:
    alwaysApply: false
    description: >
      Enforce coding standards and best practices for Python files
      in Ascend Projects. Applies when reviewing code, creating new files, or
      discussing code quality.
    globs:
      - "*.py"
      - "*.sql"
      - "*.yaml"
      - "*.yml"
      - "flows/**/*"
      - "transforms/**/*"

General Standards

• Always validate inputs and handle edge cases
• Use meaningful variable and function names
• Remove commented-out code before committing
• Include TODO comments for future improvements
• Test code changes before suggesting them
• Explain complex logic in comments
• Follow DRY (Don't Repeat Yourself) principles
• Use consistent formatting throughout the project

When Otto reviews or creates code, it must:

1. Point out any violations of these standards
2. Suggest specific improvements with examples
3. Explain why the standard matters for maintainability
4. Offer to rewrite code sections to meet standards
5. Prioritize readability and maintainability over brevity