the-collective-hub/.roo/rules-mode-writer/3_mode_configuration_patterns.xml

<mode_configuration_patterns>
  <overview>
    Common patterns and templates for creating different types of modes, with examples from existing modes in the Roo-Code software.
  </overview>

  <mode_types>
    <type name="specialist_mode">
      <description>
        Modes focused on specific technical domains or tasks
      </description>
      <characteristics>
        <characteristic>Deep expertise in a particular area</characteristic>
        <characteristic>Restricted file access based on domain</characteristic>
        <characteristic>Specialized workflows and decision criteria</characteristic>
      </characteristics>
      <example_template>
- slug: api-specialist
  name: 🔌 API Specialist
  roleDefinition: &gt;-
    You are Roo Code, an API development specialist with expertise in:
    - RESTful API design and implementation
    - GraphQL schema design
    - API documentation with OpenAPI/Swagger
    - Authentication and authorization patterns
    - Rate limiting and caching strategies
    - API versioning and deprecation

    You ensure APIs are:
    - Well-documented and discoverable
    - Following REST principles or GraphQL best practices
    - Secure and performant
    - Properly versioned and maintainable
  whenToUse: &gt;-
    Use this mode when designing, implementing, or refactoring APIs.
    This includes creating new endpoints, updating API documentation,
    implementing authentication, or optimizing API performance.
  groups:
    - read
    - - edit
      - fileRegex: (api/.*\.(ts|js)|.*\.openapi\.yaml|.*\.graphql|docs/api/.*)$
        description: API implementation files, OpenAPI specs, and API documentation
    - command
    - mcp
      </example_template>
    </type>

    <type name="workflow_mode">
      <description>
        Modes that guide users through multi-step processes
      </description>
      <characteristics>
        <characteristic>Step-by-step workflow guidance</characteristic>
        <characteristic>Heavy use of focused clarifying questions</characteristic>
        <characteristic>Process validation at each step</characteristic>
      </characteristics>
      <example_template>
- slug: migration-guide
  name: 🔄 Migration Guide
  roleDefinition: &gt;-
    You are Roo Code, a migration specialist who guides users through
    complex migration processes:
    - Database schema migrations
    - Framework version upgrades
    - API version migrations
    - Dependency updates
    - Breaking change resolutions

    You provide:
    - Step-by-step migration plans
    - Automated migration scripts
    - Rollback strategies
    - Testing approaches for migrations
  whenToUse: &gt;-
    Use this mode when performing any kind of migration or upgrade.
    This mode will analyze the current state, plan the migration,
    and guide you through each step with validation.
  groups:
    - read
    - edit
    - command
      </example_template>
    </type>

    <type name="analysis_mode">
      <description>
        Modes focused on code analysis and reporting
      </description>
      <characteristics>
        <characteristic>Read-heavy operations</characteristic>
        <characteristic>Limited or no edit permissions</characteristic>
        <characteristic>Comprehensive reporting outputs</characteristic>
      </characteristics>
      <example_template>
- slug: security-auditor
  name: 🔒 Security Auditor
  roleDefinition: &gt;-
    You are Roo Code, a security analysis specialist focused on:
    - Identifying security vulnerabilities
    - Analyzing authentication and authorization
    - Reviewing data validation and sanitization
    - Checking for common security anti-patterns
    - Evaluating dependency vulnerabilities
    - Assessing API security

    You provide detailed security reports with:
    - Vulnerability severity ratings
    - Specific remediation steps
    - Security best practice recommendations
  whenToUse: &gt;-
    Use this mode to perform security audits on codebases.
    This mode will analyze code for vulnerabilities, check
    dependencies, and provide actionable security recommendations.
  groups:
    - read
    - command
    - - edit
      - fileRegex: (SECURITY\.md|\.github/security/.*|docs/security/.*)$
        description: Security documentation files only
      </example_template>
    </type>

    <type name="creative_mode">
      <description>
        Modes for generating new content or features
      </description>
      <characteristics>
        <characteristic>Broad file creation permissions</characteristic>
        <characteristic>Template and boilerplate generation</characteristic>
        <characteristic>Interactive design process</characteristic>
      </characteristics>
      <example_template>
- slug: component-designer
  name: 🎨 Component Designer
  roleDefinition: &gt;-
    You are Roo Code, a UI component design specialist who creates:
    - Reusable React/Vue/Angular components
    - Component documentation and examples
    - Storybook stories
    - Unit tests for components
    - Accessibility-compliant interfaces

    You follow design system principles and ensure components are:
    - Highly reusable and composable
    - Well-documented with examples
    - Fully tested
    - Accessible (WCAG compliant)
    - Performance optimized
  whenToUse: &gt;-
    Use this mode when creating new UI components or refactoring
    existing ones. This mode helps design component APIs, implement
    the components, and create comprehensive documentation.
  groups:
    - read
    - - edit
      - fileRegex: (components/.*|stories/.*|__tests__/.*\.test\.(tsx?|jsx?))$
        description: Component files, stories, and component tests
    - browser
    - command
      </example_template>
    </type>
  </mode_types>

  <autonomy_configuration>
    <overview>Configuration patterns to keep modes focused, cohesive, and clearly scoped</overview>
    <defaults>
      <cohesion>Prefer a single source of truth for each rule; avoid duplicated instructions</cohesion>
      <scope>Prefer least privilege; keep file restrictions aligned with purpose</scope>
      <clarity>Define acceptance criteria and validation gates for typical tasks</clarity>
      <handoffs>Define explicit boundaries and handoff points to other modes</handoffs>
      <verbosity>Keep narrative brief; reserve detail for structured outputs and diffs</verbosity>
    </defaults>
    <per_mode_guidance>
      <mode type="specialist_mode">
        <notes>Tight scope, least privilege, clear boundaries; prefer small targeted changes</notes>
      </mode>
      <mode type="workflow_mode">
        <notes>Step-by-step process with validation gates; ask clarifying questions only when necessary</notes>
      </mode>
      <mode type="analysis_mode">
        <notes>Read-heavy; edits typically constrained to reporting or documentation outputs</notes>
      </mode>
      <mode type="creative_mode">
        <notes>Broader creation scope; ensure examples and tests are included when applicable</notes>
      </mode>
    </per_mode_guidance>
  </autonomy_configuration>

  <permission_patterns>
    <pattern name="documentation_only">
      <description>For modes that only work with documentation</description>
      <configuration>
groups:
  - read
  - - edit
    - fileRegex: \.(md|mdx|rst|txt)$
      description: Documentation files only
      </configuration>
    </pattern>

    <pattern name="test_focused">
      <description>For modes that work with test files</description>
      <configuration>
groups:
  - read
  - command
  - - edit
    - fileRegex: (__tests__/.*|__mocks__/.*|.*\.test\.(ts|tsx|js|jsx)$|.*\.spec\.(ts|tsx|js|jsx)$)
      description: Test files and mocks
      </configuration>
    </pattern>

    <pattern name="config_management">
      <description>For modes that manage configuration</description>
      <configuration>
groups:
  - read
  - - edit
    - fileRegex: (.*\.config\.(js|ts|json)|.*rc\.json|.*\.yaml|.*\.yml|\.env\.example)$
      description: Configuration files (not .env)
      </configuration>
    </pattern>

    <pattern name="full_stack">
      <description>For modes that need broad access</description>
      <configuration>
groups:
  - read
  - edit  # No restrictions
  - command
  - browser
  - mcp
      </configuration>
    </pattern>
  </permission_patterns>

  <naming_conventions>
    <convention category="slug">
      <rule>Use lowercase with hyphens</rule>
      <good>api-dev, test-writer, docs-manager</good>
      <bad>apiDev, test_writer, DocsManager</bad>
    </convention>

    <convention category="name">
      <rule>Use title case with descriptive emoji</rule>
      <good>🔧 API Developer, 📝 Documentation Writer</good>
      <bad>api developer, DOCUMENTATION WRITER</bad>
    </convention>

    <convention category="emoji_selection">
      <common_emojis>
        <emoji meaning="testing">🧪</emoji>
        <emoji meaning="documentation">📝</emoji>
        <emoji meaning="design">🎨</emoji>
        <emoji meaning="debugging">🪲</emoji>
        <emoji meaning="building">🏗️</emoji>
        <emoji meaning="security">🔒</emoji>
        <emoji meaning="api">🔌</emoji>
        <emoji meaning="database">🗄️</emoji>
        <emoji meaning="performance">⚡</emoji>
        <emoji meaning="configuration">⚙️</emoji>
      </common_emojis>
    </convention>
  </naming_conventions>

  <integration_guidelines>
    <guideline name="orchestrator_compatibility">
      <description>Ensure whenToUse/whenNotToUse are clear for Orchestrator mode</description>
      <checklist>
        <item>Specify concrete task types the mode handles</item>
        <item>Include trigger keywords or phrases</item>
        <item>Differentiate from similar modes</item>
        <item>Mention specific file types or areas</item>
        <item>Define whenNotToUse with negative triggers and explicit handoffs</item>
        <item>State stop/ask/handoff rules</item>
        <item>State default verbosity policy (low narrative; verbose diffs)</item>
      </checklist>
    </guideline>

    <guideline name="stop_and_handoff_rules">
      <description>Define explicit stop conditions, confirmation thresholds, and handoff/ask triggers</description>
      <checklist>
        <item>Done-ness: acceptance criteria and validation gates are defined</item>
        <item>Handoff rules to other modes or “ask a clarifying question” conditions are explicit</item>
        <item>Boundaries, risks, and validation gates are documented</item>
      </checklist>
    </guideline>

    <guideline name="verbosity_policy">
      <description>Set verbosity defaults to keep narrative short and code edits clear</description>
      <checklist>
        <item>Low narrative verbosity in status/progress text</item>
        <item>High detail only inside code/diffs and structured outputs</item>
        <item>Code clarity over cleverness; avoid code-golf and cryptic names</item>
      </checklist>
    </guideline>

    <guideline name="mode_boundaries">
      <description>Define clear boundaries between modes</description>
      <checklist>
        <item>Avoid overlapping responsibilities</item>
        <item>Make handoff points explicit</item>
        <item>Switch modes when appropriate (mechanism varies)</item>
        <item>Document mode interactions</item>
      </checklist>
    </guideline>
  </integration_guidelines>
</mode_configuration_patterns>