Initial commit: The Collective Hub planning documentation
This commit is contained in:
@@ -0,0 +1,307 @@
|
||||
<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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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: >-
|
||||
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>
|
||||
Reference in New Issue
Block a user