chore: clean up repo-facing mode rules (#11410)

.roo/rules-integration-tester/1_workflow.xml

@@ -1,198 +0,0 @@
-<workflow>
-  <step number="1">
-    <name>Understand Test Requirements</name>
-    <instructions>
-      Use ask_followup_question to determine what type of integration test is needed:
-      
-      <ask_followup_question>
-      <question>What type of integration test would you like me to create or work on?</question>
-      <follow_up>
-      <suggest>New E2E test for a specific feature or workflow</suggest>
-      <suggest>Fix or update an existing integration test</suggest>
-      <suggest>Create test utilities or helpers for common patterns</suggest>
-      <suggest>Debug failing integration tests</suggest>
-      </follow_up>
-      </ask_followup_question>
-    </instructions>
-  </step>
-
-  <step number="2">
-    <name>Gather Test Specifications</name>
-    <instructions>
-      Based on the test type, gather detailed requirements:
-      
-      For New E2E Tests:
-      - What specific user workflow or feature needs testing?
-      - What are the expected inputs and outputs?
-      - What edge cases or error scenarios should be covered?
-      - Are there specific API interactions to validate?
-      - What events should be monitored during the test?
-      
-      For Existing Test Issues:
-      - Which test file is failing or needs updates?
-      - What specific error messages or failures are occurring?
-      - What changes in the codebase might have affected the test?
-      
-      For Test Utilities:
-      - What common patterns are being repeated across tests?
-      - What helper functions would improve test maintainability?
-      
-      Use multiple ask_followup_question calls if needed to gather complete information.
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Explore Existing Test Patterns</name>
-    <instructions>
-      Use codebase_search FIRST to understand existing test patterns and similar functionality:
-      
-      For New Tests:
-      - Search for similar test scenarios in apps/vscode-e2e/src/suite/
-      - Find existing test utilities and helpers
-      - Identify patterns for the type of functionality being tested
-      
-      For Test Fixes:
-      - Search for the failing test file and related code
-      - Find similar working tests for comparison
-      - Look for recent changes that might have broken the test
-      
-      Example searches:
-      - "file creation test mocha" for file operation tests
-      - "task completion waitUntilCompleted" for task monitoring patterns
-      - "api message validation" for API interaction tests
-      
-      After codebase_search, use:
-      - read_file on relevant test files to understand structure
-      - list_code_definition_names on test directories
-      - search_files for specific test patterns or utilities
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Analyze Test Environment and Setup</name>
-    <instructions>
-      Examine the test environment configuration:
-      
-      1. Read the test runner configuration:
-         - apps/vscode-e2e/package.json for test scripts
-         - apps/vscode-e2e/src/runTest.ts for test setup
-         - Any test configuration files
-      
-      2. Understand the test workspace setup:
-         - How test workspaces are created
-         - What files are available during tests
-         - How the extension API is accessed
-      
-      3. Review existing test utilities:
-         - Helper functions for common operations
-         - Event listening patterns
-         - Assertion utilities
-         - Cleanup procedures
-      
-      Document findings including:
-      - Test environment structure
-      - Available utilities and helpers
-      - Common patterns and best practices
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Design Test Structure</name>
-    <instructions>
-      Plan the test implementation based on gathered information:
-      
-      For New Tests:
-      - Define test suite structure with suite/test blocks
-      - Plan setup and teardown procedures
-      - Identify required test data and fixtures
-      - Design event listeners and validation points
-      - Plan for both success and failure scenarios
-      
-      For Test Fixes:
-      - Identify the root cause of the failure
-      - Plan the minimal changes needed to fix the issue
-      - Consider if the test needs to be updated due to code changes
-      - Plan for improved error handling or debugging
-      
-      Create a detailed test plan including:
-      - Test file structure and organization
-      - Required setup and cleanup
-      - Specific assertions and validations
-      - Error handling and edge cases
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Implement Test Code</name>
-    <instructions>
-      Implement the test following established patterns:
-      
-      CRITICAL: Never write a test file with a single write_to_file call.
-      Always implement tests in parts:
-      
-      1. Start with the basic test structure (suite, setup, teardown)
-      2. Add individual test cases one by one
-      3. Implement helper functions separately
-      4. Add event listeners and validation logic incrementally
-      
-      Follow these implementation guidelines:
-      - Use suite() and test() blocks following Mocha TDD style
-      - Always use the global api object for extension interactions
-      - Implement proper async/await patterns with waitFor utility
-      - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
-      - Listen to and validate appropriate events (message, taskCompleted, etc.)
-      - Test both positive flows and error scenarios
-      - Validate message content using proper type assertions
-      - Create reusable test utilities when patterns emerge
-      - Use meaningful test descriptions that explain the scenario
-      - Always clean up tasks with cancelCurrentTask or clearCurrentTask
-      - Ensure tests are independent and can run in any order
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Run and Validate Tests</name>
-    <instructions>
-      Execute the tests to ensure they work correctly:
-      
-      ALWAYS use the correct working directory and commands:
-      - Working directory: apps/vscode-e2e
-      - Test command: npm run test:run
-      - For specific tests: TEST_FILE="filename.test" npm run test:run
-      - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
-      
-      Test execution process:
-      1. Run the specific test file first
-      2. Check for any failures or errors
-      3. Analyze test output and logs
-      4. Debug any issues found
-      5. Re-run tests after fixes
-      
-      If tests fail:
-      - Add console.log statements to track execution flow
-      - Log important events like task IDs, file paths, and AI responses
-      - Check test output carefully for error messages and stack traces
-      - Verify file creation in correct workspace directories
-      - Ensure proper event handling and timeouts
-    </instructions>
-  </step>
-
-  <step number="8">
-    <name>Document and Complete</name>
-    <instructions>
-      Finalize the test implementation:
-      
-      1. Add comprehensive comments explaining complex test logic
-      2. Document any new test utilities or patterns created
-      3. Ensure test descriptions clearly explain what is being tested
-      4. Verify all cleanup procedures are in place
-      5. Confirm tests can run independently and in any order
-      
-      Provide the user with:
-      - Summary of tests created or fixed
-      - Instructions for running the tests
-      - Any new patterns or utilities that can be reused
-      - Recommendations for future test improvements
-    </instructions>
-  </step>
-</workflow>

.roo/rules-integration-tester/2_test_patterns.xml

@@ -1,303 +0,0 @@
-<test_patterns>
-  <mocha_tdd_structure>
-    <description>Standard Mocha TDD structure for integration tests</description>
-    <pattern>
-      <name>Basic Test Suite Structure</name>
-      <example>
-        ```typescript
-        import { suite, test, suiteSetup, suiteTeardown } from 'mocha';
-        import * as assert from 'assert';
-        import * as vscode from 'vscode';
-        import { waitFor, waitUntilCompleted, waitUntilAborted } from '../utils/testUtils';
-
-        suite('Feature Name Tests', () => {
-          let testWorkspaceDir: string;
-          let testFiles: { [key: string]: string } = {};
-
-          suiteSetup(async () => {
-            // Setup test workspace and files
-            testWorkspaceDir = vscode.workspace.workspaceFolders![0].uri.fsPath;
-            // Create test files in workspace
-          });
-
-          suiteTeardown(async () => {
-            // Cleanup test files and tasks
-            await api.cancelCurrentTask();
-          });
-
-          test('should perform specific functionality', async () => {
-            // Test implementation
-          });
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Listening Pattern</name>
-      <example>
-        ```typescript
-        test('should handle task completion events', async () => {
-          const events: any[] = [];
-          
-          const messageListener = (message: any) => {
-            events.push({ type: 'message', data: message });
-          };
-          
-          const taskCompletedListener = (result: any) => {
-            events.push({ type: 'taskCompleted', data: result });
-          };
-
-          api.onDidReceiveMessage(messageListener);
-          api.onTaskCompleted(taskCompletedListener);
-
-          try {
-            // Perform test actions
-            await api.startTask('test prompt');
-            await waitUntilCompleted();
-            
-            // Validate events
-            assert(events.some(e => e.type === 'taskCompleted'));
-          } finally {
-            // Cleanup listeners
-            api.onDidReceiveMessage(() => {});
-            api.onTaskCompleted(() => {});
-          }
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>File Creation Test Pattern</name>
-      <example>
-        ```typescript
-        test('should create files in workspace', async () => {
-          const fileName = 'test-file.txt';
-          const expectedContent = 'test content';
-          
-          await api.startTask(`Create a file named ${fileName} with content: ${expectedContent}`);
-          await waitUntilCompleted();
-          
-          // Check multiple possible locations
-          const possiblePaths = [
-            path.join(testWorkspaceDir, fileName),
-            path.join(process.cwd(), fileName),
-            // Add other possible locations
-          ];
-          
-          let fileFound = false;
-          let actualContent = '';
-          
-          for (const filePath of possiblePaths) {
-            if (fs.existsSync(filePath)) {
-              actualContent = fs.readFileSync(filePath, 'utf8');
-              fileFound = true;
-              break;
-            }
-          }
-          
-          assert(fileFound, `File ${fileName} not found in any expected location`);
-          assert.strictEqual(actualContent.trim(), expectedContent);
-        });
-        ```
-      </example>
-    </pattern>
-  </mocha_tdd_structure>
-
-  <api_interaction_patterns>
-    <pattern>
-      <name>Basic Task Execution</name>
-      <example>
-        ```typescript
-        // Start a task and wait for completion
-        await api.startTask('Your prompt here');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Task with Auto-Approval Settings</name>
-      <example>
-        ```typescript
-        // Enable auto-approval for specific actions
-        await api.updateSettings({
-          alwaysAllowWrite: true,
-          alwaysAllowExecute: true
-        });
-        
-        await api.startTask('Create and execute a script');
-        await waitUntilCompleted();
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Message Validation</name>
-      <example>
-        ```typescript
-        const messages: any[] = [];
-        api.onDidReceiveMessage((message) => {
-          messages.push(message);
-        });
-
-        await api.startTask('test prompt');
-        await waitUntilCompleted();
-
-        // Validate specific message types
-        const toolMessages = messages.filter(m => 
-          m.type === 'say' && m.say === 'api_req_started'
-        );
-        assert(toolMessages.length > 0, 'Expected tool execution messages');
-        ```
-      </example>
-    </pattern>
-  </api_interaction_patterns>
-
-  <error_handling_patterns>
-    <pattern>
-      <name>Task Abortion Handling</name>
-      <example>
-        ```typescript
-        test('should handle task abortion', async () => {
-          await api.startTask('long running task');
-          
-          // Abort after short delay
-          setTimeout(() => api.abortTask(), 1000);
-          
-          await waitUntilAborted();
-          
-          // Verify task was properly aborted
-          const status = await api.getTaskStatus();
-          assert.strictEqual(status, 'aborted');
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Error Message Validation</name>
-      <example>
-        ```typescript
-        test('should handle invalid input gracefully', async () => {
-          const errorMessages: any[] = [];
-          
-          api.onDidReceiveMessage((message) => {
-            if (message.type === 'error' || message.text?.includes('error')) {
-              errorMessages.push(message);
-            }
-          });
-
-          await api.startTask('invalid prompt that should fail');
-          await waitFor(() => errorMessages.length > 0, 5000);
-          
-          assert(errorMessages.length > 0, 'Expected error messages');
-        });
-        ```
-      </example>
-    </pattern>
-  </error_handling_patterns>
-
-  <utility_patterns>
-    <pattern>
-      <name>File Location Helper</name>
-      <example>
-        ```typescript
-        function findFileInWorkspace(fileName: string, workspaceDir: string): string | null {
-          const possiblePaths = [
-            path.join(workspaceDir, fileName),
-            path.join(process.cwd(), fileName),
-            path.join(os.tmpdir(), fileName),
-            // Add other common locations
-          ];
-          
-          for (const filePath of possiblePaths) {
-            if (fs.existsSync(filePath)) {
-              return filePath;
-            }
-          }
-          
-          return null;
-        }
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>Event Collection Helper</name>
-      <example>
-        ```typescript
-        class EventCollector {
-          private events: any[] = [];
-          
-          constructor(private api: any) {
-            this.setupListeners();
-          }
-          
-          private setupListeners() {
-            this.api.onDidReceiveMessage((message: any) => {
-              this.events.push({ type: 'message', timestamp: Date.now(), data: message });
-            });
-            
-            this.api.onTaskCompleted((result: any) => {
-              this.events.push({ type: 'taskCompleted', timestamp: Date.now(), data: result });
-            });
-          }
-          
-          getEvents(type?: string) {
-            return type ? this.events.filter(e => e.type === type) : this.events;
-          }
-          
-          clear() {
-            this.events = [];
-          }
-        }
-        ```
-      </example>
-    </pattern>
-  </utility_patterns>
-
-  <debugging_patterns>
-    <pattern>
-      <name>Comprehensive Logging</name>
-      <example>
-        ```typescript
-        test('should log execution flow for debugging', async () => {
-          console.log('Starting test execution');
-          
-          const events: any[] = [];
-          api.onDidReceiveMessage((message) => {
-            console.log('Received message:', JSON.stringify(message, null, 2));
-            events.push(message);
-          });
-
-          console.log('Starting task with prompt');
-          await api.startTask('test prompt');
-          
-          console.log('Waiting for task completion');
-          await waitUntilCompleted();
-          
-          console.log('Task completed, events received:', events.length);
-          console.log('Final workspace state:', fs.readdirSync(testWorkspaceDir));
-        });
-        ```
-      </example>
-    </pattern>
-
-    <pattern>
-      <name>State Validation</name>
-      <example>
-        ```typescript
-        function validateTestState(description: string) {
-          console.log(`=== ${description} ===`);
-          console.log('Workspace files:', fs.readdirSync(testWorkspaceDir));
-          console.log('Current working directory:', process.cwd());
-          console.log('Task status:', api.getTaskStatus?.() || 'unknown');
-          console.log('========================');
-        }
-        ```
-      </example>
-    </pattern>
-  </debugging_patterns>
-</test_patterns>

.roo/rules-integration-tester/3_best_practices.xml

@@ -1,104 +0,0 @@
-<best_practices>
-  <test_structure>
-    - Always use suite() and test() blocks following Mocha TDD style
-    - Use descriptive test names that explain the scenario being tested
-    - Implement proper setup and teardown in suiteSetup() and suiteTeardown()
-    - Create test files in the VSCode workspace directory during suiteSetup()
-    - Store file paths in a test-scoped object for easy reference across tests
-    - Ensure tests are independent and can run in any order
-    - Clean up all test files and tasks in suiteTeardown() to avoid test pollution
-  </test_structure>
-
-  <api_interactions>
-    - Always use the global api object for extension interactions
-    - Implement proper async/await patterns with the waitFor utility
-    - Use waitUntilCompleted and waitUntilAborted helpers for task monitoring
-    - Set appropriate auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) for the functionality being tested
-    - Listen to and validate appropriate events (message, taskCompleted, taskAborted, etc.)
-    - Always clean up tasks with cancelCurrentTask or clearCurrentTask after tests
-    - Use meaningful timeouts that account for actual task execution time
-  </api_interactions>
-
-  <file_system_handling>
-    - Be aware that files may be created in the workspace directory (/tmp/roo-test-workspace-*) rather than expected locations
-    - Always check multiple possible file locations when verifying file creation
-    - Use flexible file location checking that searches workspace directories
-    - Verify files exist after creation to catch setup issues early
-    - Account for the fact that the workspace directory is created by runTest.ts
-    - The AI may use internal tools instead of the documented tools - verify outcomes rather than methods
-  </file_system_handling>
-
-  <event_handling>
-    - Add multiple event listeners (taskStarted, taskCompleted, taskAborted) for better debugging
-    - Don't rely on parsing AI messages to detect tool usage - the AI's message format may vary
-    - Use terminal shell execution events (onDidStartTerminalShellExecution, onDidEndTerminalShellExecution) for command tracking
-    - Tool executions are reported via api_req_started messages with type="say" and say="api_req_started"
-    - Focus on testing outcomes (files created, commands executed) rather than message parsing
-    - There is no "tool_result" message type - tool results appear in "completion_result" or "text" messages
-  </event_handling>
-
-  <error_scenarios>
-    - Test both positive flows and error scenarios
-    - Validate message content using proper type assertions
-    - Implement proper error handling and edge cases
-    - Use try-catch blocks around critical test operations
-    - Log important events like task IDs, file paths, and AI responses for debugging
-    - Check test output carefully for error messages and stack traces
-  </error_scenarios>
-
-  <test_reliability>
-    - Remove unnecessary waits for specific tool executions - wait for task completion instead
-    - Simplify message handlers to only capture essential error information
-    - Use the simplest possible test structure that verifies the outcome
-    - Avoid complex message parsing logic that depends on AI behavior
-    - Terminal events are more reliable than message parsing for command execution verification
-    - Keep prompts simple and direct - complex instructions may confuse the AI
-  </test_reliability>
-
-  <debugging_and_troubleshooting>
-    - Add console.log statements to track test execution flow
-    - Log important events like task IDs, file paths, and AI responses
-    - Use codebase_search first to find similar test patterns before writing new tests
-    - Create helper functions for common file location checks
-    - Use descriptive variable names for file paths and content
-    - Always log the expected vs actual locations when tests fail
-    - Add comprehensive comments explaining complex test logic
-  </debugging_and_troubleshooting>
-
-  <test_utilities>
-    - Create reusable test utilities when patterns emerge
-    - Implement helper functions for common operations like file finding
-    - Use event collection utilities for consistent event handling
-    - Create assertion helpers for common validation patterns
-    - Document any new test utilities or patterns created
-    - Share common utilities across test files to reduce duplication
-  </test_utilities>
-
-  <ai_interaction_considerations>
-    - Keep prompts simple and direct - complex instructions may lead to unexpected behavior
-    - Allow for variations in how the AI accomplishes tasks
-    - The AI may not always use the exact tool you specify in the prompt
-    - Be prepared to adapt tests based on actual AI behavior rather than expected behavior
-    - The AI may interpret instructions creatively - test results rather than implementation details
-    - The AI will not see the files in the workspace directory, you must tell it to assume they exist and proceed
-  </ai_interaction_considerations>
-
-  <test_execution>
-    - ALWAYS use the correct working directory: apps/vscode-e2e
-    - The test command is: npm run test:run
-    - To run specific tests use environment variable: TEST_FILE="filename.test" npm run test:run
-    - Example: cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run
-    - Never use npm test directly as it doesn't exist
-    - Always check available scripts with npm run if unsure
-    - Run tests incrementally during development to catch issues early
-  </test_execution>
-
-  <code_organization>
-    - Never write a test file with a single write_to_file tool call
-    - Always implement tests in parts: structure first, then individual test cases
-    - Group related tests in the same suite
-    - Use consistent naming conventions for test files and functions
-    - Separate test utilities into their own files when they become substantial
-    - Follow the existing project structure and conventions
-  </code_organization>
-</best_practices>

.roo/rules-integration-tester/4_common_mistakes.xml

@@ -1,109 +0,0 @@
-<common_mistakes_to_avoid>
-  <test_structure_mistakes>
-    - Writing a test file with a single write_to_file tool call instead of implementing in parts
-    - Not using proper Mocha TDD structure with suite() and test() blocks
-    - Forgetting to implement suiteSetup() and suiteTeardown() for proper cleanup
-    - Creating tests that depend on each other or specific execution order
-    - Not cleaning up tasks and files after test completion
-    - Using describe/it blocks instead of the required suite/test blocks
-  </test_structure_mistakes>
-
-  <api_interaction_mistakes>
-    - Not using the global api object for extension interactions
-    - Forgetting to set auto-approval settings (alwaysAllowWrite, alwaysAllowExecute) when testing functionality that requires user approval
-    - Not implementing proper async/await patterns with waitFor utilities
-    - Using incorrect timeout values that are too short for actual task execution
-    - Not properly cleaning up tasks with cancelCurrentTask or clearCurrentTask
-    - Assuming the AI will use specific tools instead of testing outcomes
-  </api_interaction_mistakes>
-
-  <file_system_mistakes>
-    - Assuming files will be created in the expected location without checking multiple paths
-    - Not accounting for the workspace directory being created by runTest.ts
-    - Creating test files in temporary directories instead of the VSCode workspace directory
-    - Not verifying files exist after creation during setup
-    - Forgetting that the AI may not see files in the workspace directory
-    - Not using flexible file location checking that searches workspace directories
-  </file_system_mistakes>
-
-  <event_handling_mistakes>
-    - Relying on parsing AI messages to detect tool usage instead of using proper event listeners
-    - Expecting tool results in "tool_result" message type (which doesn't exist)
-    - Not listening to terminal shell execution events for command tracking
-    - Depending on specific message formats that may vary
-    - Not implementing proper event cleanup after tests
-    - Parsing complex AI conversation messages instead of focusing on outcomes
-  </event_handling_mistakes>
-
-  <test_execution_mistakes>
-    - Using npm test instead of npm run test:run
-    - Not using the correct working directory (apps/vscode-e2e)
-    - Running tests from the wrong directory
-    - Not checking available scripts with npm run when unsure
-    - Forgetting to use TEST_FILE environment variable for specific tests
-    - Not running tests incrementally during development
-  </test_execution_mistakes>
-
-  <debugging_mistakes>
-    - Not adding sufficient logging to track test execution flow
-    - Not logging important events like task IDs, file paths, and AI responses
-    - Not using codebase_search to find similar test patterns before writing new tests
-    - Not checking test output carefully for error messages and stack traces
-    - Not validating test state at critical points
-    - Assuming test failures are due to code issues without checking test logic
-  </debugging_mistakes>
-
-  <ai_interaction_mistakes>
-    - Using complex instructions that may confuse the AI
-    - Expecting the AI to use exact tools specified in prompts
-    - Not allowing for variations in how the AI accomplishes tasks
-    - Testing implementation details instead of outcomes
-    - Not adapting tests based on actual AI behavior
-    - Forgetting to tell the AI to assume files exist in the workspace directory
-  </ai_interaction_mistakes>
-
-  <reliability_mistakes>
-    - Adding unnecessary waits for specific tool executions
-    - Using complex message parsing logic that depends on AI behavior
-    - Not using the simplest possible test structure
-    - Depending on specific AI message formats
-    - Not using terminal events for reliable command execution verification
-    - Making tests too brittle by depending on exact AI responses
-  </reliability_mistakes>
-
-  <workspace_mistakes>
-    - Not understanding that files may be created in /tmp/roo-test-workspace-* directories
-    - Assuming the AI can see files in the workspace directory
-    - Not checking multiple possible file locations when verifying creation
-    - Creating files outside the VSCode workspace during tests
-    - Not properly setting up the test workspace in suiteSetup()
-    - Forgetting to clean up workspace files in suiteTeardown()
-  </workspace_mistakes>
-
-  <message_handling_mistakes>
-    - Expecting specific message types for tool execution results
-    - Not understanding that ClineMessage types have specific values
-    - Trying to parse tool execution from AI conversation messages
-    - Not checking packages/types/src/message.ts for valid message types
-    - Depending on message parsing instead of outcome verification
-    - Not using api_req_started messages to verify tool execution
-  </message_handling_mistakes>
-
-  <timeout_and_timing_mistakes>
-    - Using timeouts that are too short for actual task execution
-    - Not accounting for AI processing time in test timeouts
-    - Waiting for specific tool executions instead of task completion
-    - Not implementing proper retry logic for flaky operations
-    - Using fixed delays instead of condition-based waiting
-    - Not considering that some operations may take longer in CI environments
-  </timeout_and_timing_mistakes>
-
-  <test_data_mistakes>
-    - Not creating test files in the correct workspace directory
-    - Using hardcoded paths that don't work across different environments
-    - Not storing file paths in test-scoped objects for easy reference
-    - Creating test data that conflicts with other tests
-    - Not cleaning up test data properly after tests complete
-    - Using test data that's too complex for the AI to handle reliably
-  </test_data_mistakes>
-</common_mistakes_to_avoid>

.roo/rules-integration-tester/5_test_environment.xml

@@ -1,209 +0,0 @@
-<test_environment_and_tools>
-  <test_framework>
-    <description>VSCode E2E testing framework using Mocha and VSCode Test</description>
-    <key_components>
-      - Mocha TDD framework for test structure
-      - VSCode Test framework for extension testing
-      - Custom test utilities and helpers
-      - Event-driven testing patterns
-      - Workspace-based test execution
-    </key_components>
-  </test_framework>
-
-  <directory_structure>
-    <test_files_location>apps/vscode-e2e/src/suite/</test_files_location>
-    <test_utilities>apps/vscode-e2e/src/utils/</test_utilities>
-    <test_runner>apps/vscode-e2e/src/runTest.ts</test_runner>
-    <package_config>apps/vscode-e2e/package.json</package_config>
-    <type_definitions>packages/types/</type_definitions>
-  </directory_structure>
-
-  <test_execution_commands>
-    <working_directory>apps/vscode-e2e</working_directory>
-    <commands>
-      <run_all_tests>npm run test:run</run_all_tests>
-      <run_specific_test>TEST_FILE="filename.test" npm run test:run</run_specific_test>
-      <example>cd apps/vscode-e2e && TEST_FILE="apply-diff.test" npm run test:run</example>
-      <check_scripts>npm run</check_scripts>
-    </commands>
-    <important_notes>
-      - Never use npm test directly as it doesn't exist
-      - Always use the correct working directory
-      - Use TEST_FILE environment variable for specific tests
-      - Check available scripts with npm run if unsure
-    </important_notes>
-  </test_execution_commands>
-
-  <api_object>
-    <description>Global api object for extension interactions</description>
-    <key_methods>
-      <task_management>
-        - api.startTask(prompt: string): Start a new task
-        - api.cancelCurrentTask(): Cancel the current task
-        - api.clearCurrentTask(): Clear the current task
-        - api.abortTask(): Abort the current task
-        - api.getTaskStatus(): Get current task status
-      </task_management>
-      <event_listeners>
-        - api.onDidReceiveMessage(callback): Listen to messages
-        - api.onTaskCompleted(callback): Listen to task completion
-        - api.onTaskAborted(callback): Listen to task abortion
-        - api.onTaskStarted(callback): Listen to task start
-        - api.onDidStartTerminalShellExecution(callback): Terminal start events
-        - api.onDidEndTerminalShellExecution(callback): Terminal end events
-      </event_listeners>
-      <settings>
-        - api.updateSettings(settings): Update extension settings
-        - api.getSettings(): Get current settings
-      </settings>
-    </key_methods>
-  </api_object>
-
-  <test_utilities>
-    <wait_functions>
-      <waitFor>
-        <description>Wait for a condition to be true</description>
-        <usage>await waitFor(() => condition, timeout)</usage>
-        <example>await waitFor(() => fs.existsSync(filePath), 5000)</example>
-      </waitFor>
-      <waitUntilCompleted>
-        <description>Wait until current task is completed</description>
-        <usage>await waitUntilCompleted()</usage>
-        <timeout>Default timeout for task completion</timeout>
-      </waitUntilCompleted>
-      <waitUntilAborted>
-        <description>Wait until current task is aborted</description>
-        <usage>await waitUntilAborted()</usage>
-        <timeout>Default timeout for task abortion</timeout>
-      </waitUntilAborted>
-    </wait_functions>
-    
-    <helper_patterns>
-      <file_location_helper>
-        <description>Helper to find files in multiple possible locations</description>
-        <usage>Use when files might be created in different workspace directories</usage>
-      </file_location_helper>
-      <event_collector>
-        <description>Utility to collect and analyze events during test execution</description>
-        <usage>Use for comprehensive event tracking and validation</usage>
-      </event_collector>
-      <assertion_helpers>
-        <description>Custom assertion functions for common test patterns</description>
-        <usage>Use for consistent validation across tests</usage>
-      </assertion_helpers>
-    </helper_patterns>
-  </test_utilities>
-
-  <workspace_management>
-    <workspace_creation>
-      <description>Test workspaces are created by runTest.ts</description>
-      <location>/tmp/roo-test-workspace-*</location>
-      <access>vscode.workspace.workspaceFolders![0].uri.fsPath</access>
-    </workspace_creation>
-    
-    <file_creation_strategy>
-      <setup_phase>Create all test files in suiteSetup() before any tests run</setup_phase>
-      <location>Always create files in the VSCode workspace directory</location>
-      <verification>Verify files exist after creation to catch setup issues early</verification>
-      <cleanup>Clean up all test files in suiteTeardown() to avoid test pollution</cleanup>
-      <storage>Store file paths in a test-scoped object for easy reference</storage>
-    </file_creation_strategy>
-
-    <ai_visibility>
-      <important_note>The AI will not see the files in the workspace directory</important_note>
-      <solution>Tell the AI to assume files exist and proceed as if they do</solution>
-      <verification>Always verify outcomes rather than relying on AI file visibility</verification>
-    </ai_visibility>
-  </workspace_management>
-
-  <message_types>
-    <description>Understanding message types for proper event handling</description>
-    <reference>Check packages/types/src/message.ts for valid message types</reference>
-    
-    <key_message_types>
-      <api_req_started>
-        <type>say</type>
-        <say>api_req_started</say>
-        <description>Indicates tool execution started</description>
-        <text_content>JSON with tool name and execution details</text_content>
-        <usage>Most reliable way to verify tool execution</usage>
-      </api_req_started>
-      
-      <completion_result>
-        <description>Contains tool execution results</description>
-        <usage>Tool results appear here, not in "tool_result" type</usage>
-      </completion_result>
-      
-      <text_messages>
-        <description>General AI conversation messages</description>
-        <caution>Format may vary, don't rely on parsing these for tool detection</caution>
-      </text_messages>
-    </key_message_types>
-  </message_types>
-
-  <auto_approval_settings>
-    <description>Settings to enable automatic approval of AI actions</description>
-    <critical_settings>
-      <alwaysAllowWrite>Enable for file creation/modification tests</alwaysAllowWrite>
-      <alwaysAllowExecute>Enable for command execution tests</alwaysAllowExecute>
-      <alwaysAllowBrowser>Enable for browser-related tests</alwaysAllowBrowser>
-    </critical_settings>
-    <usage>
-      ```typescript
-      await api.updateSettings({
-        alwaysAllowWrite: true,
-        alwaysAllowExecute: true
-      });
-      ```
-    </usage>
-    <importance>Without proper auto-approval settings, the AI won't be able to perform actions without user approval</importance>
-  </auto_approval_settings>
-
-  <debugging_tools>
-    <console_logging>
-      <description>Use console.log for tracking test execution flow</description>
-      <best_practices>
-        - Log test phase transitions
-        - Log important events and data
-        - Log file paths and workspace state
-        - Log expected vs actual outcomes
-      </best_practices>
-    </console_logging>
-    
-    <state_validation>
-      <description>Helper functions to validate test state at critical points</description>
-      <includes>
-        - Workspace file listing
-        - Current working directory
-        - Task status
-        - Event counts
-      </includes>
-    </state_validation>
-    
-    <error_analysis>
-      <description>Tools for analyzing test failures</description>
-      <techniques>
-        - Stack trace analysis
-        - Event timeline reconstruction
-        - File system state comparison
-        - Message flow analysis
-      </techniques>
-    </error_analysis>
-  </debugging_tools>
-
-  <performance_considerations>
-    <timeouts>
-      <description>Appropriate timeout values for different operations</description>
-      <task_completion>Use generous timeouts for task completion (30+ seconds)</task_completion>
-      <file_operations>Shorter timeouts for file system operations (5-10 seconds)</file_operations>
-      <event_waiting>Medium timeouts for event waiting (10-15 seconds)</event_waiting>
-    </timeouts>
-    
-    <resource_management>
-      <description>Proper cleanup to avoid resource leaks</description>
-      <event_listeners>Always clean up event listeners after tests</event_listeners>
-      <tasks>Cancel or clear tasks in teardown</tasks>
-      <files>Remove test files to avoid disk space issues</files>
-    </resource_management>
-  </performance_considerations>
-</test_environment_and_tools>

.roo/rules-issue-investigator/1_workflow.xml

@@ -70,7 +70,7 @@
         </step>
         <step>
             <title>Draft Comment</title>
-            <description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone.</description>
+            <description>Draft a comment for the GitHub issue that explains your findings and suggested solution in a conversational, human-like tone. Start the comment with "Hey @roomote-agent,".</description>
         </step>
       </steps>
     </phase>

.roo/rules-issue-investigator/2_best_practices.xml

@@ -52,6 +52,7 @@
     </category>
     <category name="communication">
       <item>Does the draft comment sound conversational and human?</item>
+      <item>Does the draft comment start with "Hey @roomote-agent,"?</item>
       <item>Have I avoided technical jargon where possible?</item>
       <item>Is the tone helpful and not condescending?</item>
     </category>

.roo/rules-issue-investigator/4_tool_usage.xml

@@ -23,10 +23,16 @@
         <practice>Use `gh issue view [URL] --json title,body,labels,comments` to fetch initial details.</practice>
         <practice>Use `gh issue comment [URL] --body "..."` to add comments, but only after explicit user approval.</practice>
         <practice>Always wrap the comment body in quotes to handle special characters.</practice>
+        <practice>When posting a comment, the body must start with "Hey @roomote-agent," exactly.</practice>
       </best_practices>
       <example><![CDATA[
 <execute_command>
 <command>gh issue view https://github.com/RooCodeInc/Roo-Code/issues/123 --json title,body</command>
+</execute_command>
+      ]]></example>
+      <example><![CDATA[
+<execute_command>
+<command>gh issue comment https://github.com/RooCodeInc/Roo-Code/issues/123 --body "Hey @roomote-agent, I've investigated and proposed a theoretical fix above."</command>
 </execute_command>
       ]]></example>
     </tool>

.roo/rules-issue-investigator/5_examples.xml

@@ -70,7 +70,7 @@
       <step number="6">
           <description>Formulate a solution and draft a comment.</description>
           <draft>
-"Hey, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
+"Hey @roomote-agent, I took a look at this issue and it seems like the problem is in the `handleLogin` function in `src/auth/login.ts`. There's an empty `try...catch` block that is likely catching the login error and preventing any message from being shown to the user.
 
 A good first step to fixing this would be to add some logging to the `catch` block to see what error is actually happening. Then, we should probably implement proper error feedback to the user on the login page. This should solve the issue of the silent failure."
           </draft>

.roo/rules-issue-investigator/6_communication.xml

@@ -2,18 +2,20 @@
   <tone_and_style>
     <principle>Be conversational and helpful, not robotic.</principle>
     <principle>Write comments as if you are a human developer collaborating on the project.</principle>
+    <principle>Always start any GitHub issue comment body with "Hey @roomote-agent,".</principle>
     <avoid>
       <phrase>Analysis complete.</phrase>
       <phrase>The investigation has yielded the following result.</phrase>
+      <phrase>Starting comments with "Hey," instead of "Hey @roomote-agent,".</phrase>
     </avoid>
     <prefer>
-      <phrase>Hey, I took a look at this and found something interesting...</phrase>
-      <phrase>I've been digging into this issue, and I think I've found a possible cause.</phrase>
+      <phrase>Hey @roomote-agent, I took a look at this and found something interesting...</phrase>
+      <phrase>Hey @roomote-agent, I've been digging into this issue, and I think I've found a possible cause.</phrase>
     </prefer>
   </tone_and_style>
 
   <comment_structure>
-      <element>Start with a friendly opening.</element>
+      <element>Start every GitHub issue comment with "Hey @roomote-agent,".</element>
       <element>State your main finding or hypothesis clearly but not definitively.</element>
       <element>Provide context, like file paths and function names.</element>
       <element>Propose a next step or a theoretical solution.</element>

.roo/rules-issue-writer/1_workflow.xml

@@ -1,1161 +1,391 @@
 <workflow>
+  <mode_overview>
+    This mode focuses solely on assembling a template-free GitHub issue prompt for an AI coding agent.
+    It integrates codebase exploration to ground the prompt in reality while keeping the output non-technical.
+    It also captures the user-facing value/impact (who is affected, how often, and why it matters) to support prioritization, all in plain language.
+  </mode_overview>
+
+  <iteration_policy>
+    <principles>
+      - Codebase exploration is iterative and may repeat as many times as needed based on user-agent back-and-forth.
+      - Early-stop and escalate-once apply per iteration; when new info arrives, start a fresh iteration.
+      - One-tool-per-message is respected; narrate succinct progress and update TODOs each iteration.
+    </principles>
+    <loop_triggers>
+      - New details from the user (environment, steps, screenshots, constraints)
+      - Clarifications that change scope or target component/feature
+      - Discrepancies found between user claims and code
+      - Reclassification between Bug and Enhancement
+    </loop_triggers>
+  </iteration_policy>
+
   <initialization>
+    <notes>
+      - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue.
+      - Begin immediately: initialize a focused TODO list and start repository detection before discovery.
+      - CLI submission via gh happens only after the user confirms during the merged review/submit step.
+    </notes>
+    <update_todo_list>
+      <todos>
+      [ ] Detect repository context (OWNER/REPO, monorepo, roots)
+      [ ] Perform targeted codebase discovery (iteration 1)
+      [ ] Clarify missing details (repro or desired outcome)
+      [ ] Classify type (Bug | Enhancement)
+      [ ] Assemble Issue Body
+      [ ] Review and submit (Submit now | Submit now and assign to me)
+      </todos>
+    </update_todo_list>
+  </initialization>
+
+  <steps>
     <step number="1">
-      <name>Initialize Issue Creation Process</name>
+      <name>Kickoff</name>
       <instructions>
-        IMPORTANT: This mode assumes the first user message is already a request to create an issue.
-        The user doesn't need to say "create an issue" or "make me an issue" - their first message
-        is treated as the issue description itself.
-        
-        When the session starts, immediately:
-        1. Treat the user's first message as the issue description
-        2. Initialize the workflow by using the update_todo_list tool
-        3. Begin the issue creation process without asking what they want to do
-        
-        <update_todo_list>
-        <todos>
-        [ ] Detect current repository information
-        [ ] Determine repository structure (monorepo/standard)
-        [ ] Perform initial codebase discovery
-        [ ] Analyze user request to determine issue type
-        [ ] Gather and verify additional information
-        [ ] Determine if user wants to contribute
-        [ ] Perform issue scoping (if contributing)
-        [ ] Draft issue content
-        [ ] Review and confirm with user
-        [ ] Create GitHub issue
-        </todos>
-        </update_todo_list>
+        Rephrase the user's goal and outline a brief plan, then proceed without delay.
+        Maintain low narrative verbosity; use structured outputs for details.
       </instructions>
     </step>
-  </initialization>
-
-  <step number="1">
-    <name>Detect current repository information</name>
-    <instructions>
-      CRITICAL FIRST STEP: Verify we're in a git repository and get repository information.
-      
-      1. Check if we're in a git repository:
-      <execute_command>
-      <command>git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo"</command>
-      </execute_command>
-      
-      If the output is "not-git-repo", immediately stop and inform the user:
-      
-      <attempt_completion>
-      <result>
-      This mode must be run from within a GitHub repository. Please navigate to a git repository and try again.
-      </result>
-      </attempt_completion>
-      
-      2. If in a git repository, get the repository information:
-      <execute_command>
-      <command>git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'</command>
-      </execute_command>
-      
-      Store this as REPO_FULL_NAME for use throughout the workflow.
-      
-      If no origin remote exists, stop with:
-      <attempt_completion>
-      <result>
-      No GitHub remote found. This mode requires a GitHub repository with an 'origin' remote configured.
-      </result>
-      </attempt_completion>
-      
-      Update todo after detecting repository:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [-] Determine repository structure (monorepo/standard)
-      [ ] Perform initial codebase discovery
-      [ ] Analyze user request to determine issue type
-      [ ] Gather and verify additional information
-      [ ] Determine if user wants to contribute
-      [ ] Perform issue scoping (if contributing)
-      [ ] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
 
-  <step number="2">
-    <name>Determine Repository Structure</name>
-    <instructions>
-      Check if this is a monorepo or standard repository by looking for common patterns.
-      
-      First, check for monorepo indicators:
-      1. Look for workspace configuration:
-         - package.json with "workspaces" field
-         - lerna.json
-         - pnpm-workspace.yaml
-         - rush.json
-      
-      2. Check for common monorepo directory patterns:
-      <list_files>
-      <path>.</path>
-      <recursive>false</recursive>
-      </list_files>
-      
-      Look for directories like:
-      - apps/ (application packages)
-      - packages/ (shared packages)
-      - services/ (service packages)
-      - libs/ (library packages)
-      - modules/ (module packages)
-      - src/ (main source if not using workspaces)
-      
-      If monorepo detected:
-        - Dynamically discover packages by looking for package.json files in detected directories
-        - Build a list of available packages with their paths
-      
-      Based on the user's description, try to identify which package they're referring to.
-      If unclear, ask for clarification:
-      
-      <ask_followup_question>
-      <question>I see this is a monorepo with multiple packages. Which specific package or application is your issue related to?</question>
-      <follow_up>
-      [Dynamically generated list of discovered packages]
-      <suggest>Let me describe which package: [specify]</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      If standard repository:
-        - Skip package selection
-        - Use repository root for all searches
-      
-      Store the repository context for all future codebase searches and explorations.
-      
-      Update todo after determining context:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [-] Perform initial codebase discovery
-      [ ] Analyze user request to determine issue type
-      [ ] Gather and verify additional information
-      [ ] Determine if user wants to contribute
-      [ ] Perform issue scoping (if contributing)
-      [ ] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
-
-  <step number="3">
-    <name>Perform Initial Codebase Discovery</name>
-    <instructions>
-      Now that we know the repository structure, immediately search the codebase to understand
-      what the user is talking about before determining the issue type.
-      
-      DISCOVERY ACTIVITIES:
-      
-      1. Extract keywords and concepts from the user's INITIAL MESSAGE (their issue description)
-      2. Search the codebase to verify these concepts exist
-      3. Build understanding of the actual implementation
-      4. Identify relevant files, components, and code patterns
-      
-      <codebase_search>
-      <query>[Keywords from user's initial message/description]</query>
-      <path>[Repository or package path from step 2]</path>
-      </codebase_search>
-      
-      Additional searches based on initial findings:
-      - If error mentioned: search for exact error strings
-      - If feature mentioned: search for related functionality
-      - If component mentioned: search for implementation details
-      
-      <search_files>
-      <path>[repository or package path]</path>
-      <regex>[specific patterns found in initial search]</regex>
-      </search_files>
-      
-      Document findings:
-      - Components/features found that match user's description
-      - Actual implementation details discovered
-      - Related code sections identified
-      - Any discrepancies between user description and code reality
-      
-      Update todos:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [-] Analyze user request to determine issue type
-      [ ] Gather and verify additional information
-      [ ] Determine if user wants to contribute
-      [ ] Perform issue scoping (if contributing)
-      [ ] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
-
-  <step number="4">
-    <name>Analyze Request to Determine Issue Type</name>
-    <instructions>
-      Using the codebase discoveries from step 2, analyze the user's request to determine
-      the appropriate issue type with informed context.
-      
-      CRITICAL GUIDANCE FOR ISSUE TYPE SELECTION:
-      For issues that affect user workflows or require behavior changes:
-      - PREFER the feature proposal template over bug report
-      - Focus on explaining WHO is affected and WHEN this happens
-      - Describe the user impact before diving into technical details
-      
-      Based on your findings, classify the issue:
-      
-      Bug indicators (verified against code):
-      - Error messages that match actual error handling in code
-      - Broken functionality in existing features found in codebase
-      - Regression from previous behavior documented in code/tests
-      - Code paths that don't work as documented
-      
-      Feature indicators (verified against code):
-      - New functionality not found in current codebase
-      - Enhancement to existing features found in code
-      - Missing capabilities compared to similar features
-      - Integration points that could be extended
-      - WORKFLOW IMPROVEMENTS: When existing behavior works but doesn't meet user needs
-      
-      IMPORTANT: Use your codebase findings to inform the question:
-      
-      <ask_followup_question>
-      <question>Based on your request about [specific feature/component found in code], what type of issue would you like to create?</question>
-      <follow_up>
-      [Order based on codebase findings and user description]
-      <suggest>Bug Report - [Specific component] is not working as expected</suggest>
-      <suggest>Feature Proposal - Add [specific capability] to [existing component]</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      Update todos:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [-] Gather and verify additional information
-      [ ] Determine if user wants to contribute
-      [ ] Perform issue scoping (if contributing)
-      [ ] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
-
-  <step number="5">
-    <name>Gather and Verify Additional Information</name>
-    <instructions>
-      Based on the issue type and initial codebase discovery, gather information while
-      continuously verifying against the actual code implementation.
-      
-      CRITICAL FOR FEATURE REQUESTS: Be fact-driven and challenge assumptions!
-      When users describe current behavior as problematic for a feature request, you MUST verify
-      their claims against the actual code. If their description doesn't match reality, this
-      might actually be a bug report, not a feature request.
-      
-      For Bug Reports:
-      1. When user describes steps to reproduce:
-         - Search for the UI components/commands mentioned
-         - Verify the code paths that would be executed
-         - Check for existing error handling or known issues
-         
-      2. When user provides error messages:
-         - Search for exact error strings in codebase
-         - Find where errors are thrown
-         - Understand the conditions that trigger them
-         
-      3. For version information:
-         - Check package.json for actual version
-         - Look for version-specific code or migrations
-      
-      Example verification searches:
-      <search_files>
-      <path>[repository or package path]</path>
-      <regex>[exact error message from user]</regex>
-      </search_files>
-      
-      <codebase_search>
-      <query>[feature or component name] implementation</query>
-      <path>[repository or package path]</path>
-      </codebase_search>
-      
-      For Feature Requests - AGGRESSIVE VERIFICATION WITH CONCRETE EXAMPLES:
-      1. When user claims current behavior is X:
-         - ALWAYS search for the actual implementation
-         - Read the relevant code to verify their claim
-         - Check CSS/styling files if UI-related
-         - Look at configuration files
-         - Examine test files to understand expected behavior
-         - TRACE THE DATA FLOW: Follow values from where they're calculated to where they're used
-         
-      2. CRITICAL: Look for existing variables/code that could be reused:
-         - Search for variables that are calculated but not used where expected
-         - Identify existing patterns that could be extended
-         - Find similar features that work correctly for comparison
-         
-      3. If discrepancy found between claim and code:
-         - Do NOT proceed without clarification
-         - Present CONCRETE before/after examples with actual values
-         - Show exactly what happens vs what should happen
-         - Ask if this might be a bug instead
-         
-      Example verification approach:
-      User says: "Feature X doesn't work properly"
-      
-      Your investigation should follow this pattern:
-      a) What is calculated: Search for where X is computed/defined
-      b) Where it's stored: Find variables/state holding the value
-      c) Where it's used: Trace all usages of that value
-      d) What's missing: Identify gaps in the flow
-      
-      Present findings with concrete examples:
-      
-      <ask_followup_question>
-      <question>I investigated the implementation and found something interesting:
-      
-      Current behavior:
-      - The value is calculated at [file:line]: `value = computeX()`
-      - It's stored in variable `calculatedValue` at [file:line]
-      - BUT it's only used for [purpose A] at [file:line]
-      - It's NOT used for [purpose B] where you expected it
-      
-      Concrete example:
-      - When you do [action], the system calculates [value]
-      - This value goes to [location A]
-      - But [location B] still uses [old/different value]
-      
-      Is this the issue you're experiencing? This seems like the calculated value isn't being used where it should be.</question>
-      <follow_up>
-      <suggest>Yes, exactly! The value is calculated but not used in the right place</suggest>
-      <suggest>No, the issue is that the calculation itself is wrong</suggest>
-      <suggest>Actually, I see now that [location B] should use a different value</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      4. Continue verification until facts are established:
-         - If user confirms it's a bug, switch to bug report workflow
-         - If user provides more specific context, search again
-         - Do not accept vague claims without code verification
-         
-      5. For genuine feature requests after verification:
-         - Document what the code currently does (with evidence and line numbers)
-         - Show the exact data flow: input → processing → output
-         - Confirm what the user wants changed with concrete examples
-         - Ensure the request is based on accurate understanding
-      
-      CRITICAL: For feature requests, if user's description doesn't match codebase reality:
-      - Challenge the assumption with code evidence AND concrete examples
-      - Show actual vs expected behavior with specific values
-      - Suggest it might be a bug if code shows different intent
-      - Ask for clarification repeatedly if needed
-      - Do NOT proceed until facts are established
-      
-      Only proceed when you have:
-      - Verified current behavior in code with line-by-line analysis
-      - Confirmed user's understanding matches reality
-      - Determined if it's truly a feature request or actually a bug
-      - Identified any existing code that could be reused for the fix
-      
-      Update todos after verification:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [-] Determine if user wants to contribute
-      [ ] Perform issue scoping (if contributing)
-      [ ] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
-
-  <step number="6">
-    <name>Determine Contribution Intent with Context</name>
-    <instructions>
-      Before asking about contribution, perform a quick technical assessment to provide context:
-      
-      1. Search for complexity indicators:
-         - Number of files that would need changes
-         - Existing tests that would need updates
-         - Dependencies and integration points
-         
-      2. Look for contribution helpers:
-         - CONTRIBUTING.md guidelines
-         - Existing similar implementations
-         - Test patterns to follow
-      
-      <codebase_search>
-      <query>CONTRIBUTING guide setup development</query>
-      </codebase_search>
-      
-      Based on findings, provide informed context in the question:
-      
-      <ask_followup_question>
-      <question>Based on my analysis, this [issue type] involves [brief complexity assessment from code exploration]. Are you interested in implementing this yourself, or are you reporting it for the project team to handle?</question>
-      <follow_up>
-      <suggest>Just reporting the problem - the project team can design the solution</suggest>
-      <suggest>I want to contribute and implement this myself</suggest>
-      <suggest>I'd like to provide issue scoping to help whoever implements it</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      Update todos based on response:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [If contributing: [-] Perform issue scoping (if contributing)]
-      [If not contributing: [-] Perform issue scoping (skipped - not contributing)]
-      [-] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
-
-  <step number="7">
-    <name>Issue Scoping for Contributors</name>
-    <instructions>
-      ONLY perform this step if the user wants to contribute or provide issue scoping.
-      
-      This step performs a comprehensive, aggressive investigation to create detailed technical
-      scoping that can guide implementation. The process involves multiple sub-phases:
-      
-      <sub_workflow name="comprehensive_issue_scoping">
-        <overview>
-          Perform an exhaustive investigation to produce a comprehensive technical solution
-          with extreme detail, suitable for automated fix workflows.
-        </overview>
-        
-        <phase number="1" name="Initialize Investigation">
-          <description>Expand the todo list to include detailed investigation steps</description>
-          <actions>
-            When starting the issue scoping phase, update the main todo list to include
-            the detailed investigation steps:
-            
-            <update_todo_list>
-            <todos>
-            [x] Detect current repository information
-            [x] Determine repository structure (monorepo/standard)
-            [x] Perform initial codebase discovery
-            [x] Analyze user request to determine issue type
-            [x] Gather and verify additional information
-            [x] Determine if user wants to contribute
-            [-] Perform issue scoping (if contributing)
-                [ ] Extract keywords from the issue description
-                [ ] Perform initial broad codebase search
-                [ ] Analyze search results and identify key components
-                [ ] Deep dive into relevant files and implementations
-                [ ] Form initial hypothesis about the issue/feature
-                [ ] Attempt to disprove hypothesis through further investigation
-                [ ] Identify all affected files and dependencies
-                [ ] Map out the complete implementation approach
-                [ ] Document technical risks and edge cases
-                [ ] Formulate comprehensive technical solution
-                [ ] Create detailed acceptance criteria
-                [ ] Prepare issue scoping summary
-            [ ] Draft issue content
-            [ ] Review and confirm with user
-            [ ] Create GitHub issue
-            </todos>
-            </update_todo_list>
-          </actions>
-        </phase>
-        
-        <phase number="2" name="Keyword Extraction">
-          <description>Extract all relevant keywords, concepts, and technical terms</description>
-          <actions>
-            - Identify primary technical concepts from user's description
-            - Extract error messages or specific symptoms
-            - Note any mentioned file paths or components
-            - List related features or functionality
-            - Include synonyms and related terms
-          </actions>
-          <update_progress>
-            Update the main todo list to mark "Extract keywords" as complete and move to next phase
-          </update_progress>
-        </phase>
-        
-        <phase number="3" name="Iterative Search">
-          <description>Perform multiple rounds of increasingly focused searches</description>
-          
-          <iteration name="Initial Broad Search">
-            Use codebase_search with all extracted keywords to get an overview of relevant code.
-            <codebase_search>
-            <query>[Combined keywords from extraction phase]</query>
-            <path>[Repository or package path]</path>
-            </codebase_search>
-          </iteration>
-          
-          <iteration name="Component Discovery">
-            Based on initial results, identify key components and search for:
-            - Related class/function definitions
-            - Import statements and dependencies
-            - Configuration files
-            - Test files that might reveal expected behavior
-          </iteration>
-          
-          <iteration name="Deep Implementation Search">
-            Search for specific implementation details:
-            - Error handling patterns
-            - State management
-            - API endpoints or routes
-            - Database queries or models
-            - UI components and their interactions
-          </iteration>
-          
-          <iteration name="Edge Case and Integration Search">
-            Look for:
-            - Edge cases in the code
-            - Integration points with other systems
-            - Configuration options that affect behavior
-            - Feature flags or conditional logic
-          </iteration>
-          
-          <update_progress>
-            After completing all search iterations, update the todo list to show progress
-          </update_progress>
-        </phase>
-        
-        <phase number="4" name="File Analysis">
-          <description>Thoroughly analyze all relevant files discovered</description>
-          <actions>
-            - Use list_code_definition_names to understand file structure
-            - Read complete files to understand full context
-            - Trace execution paths through the code
-            - Identify all dependencies and imports
-            - Map relationships between components
-          </actions>
-          <documentation>
-            Document findings including:
-            - File paths and their purposes
-            - Key functions and their responsibilities
-            - Data flow through the system
-            - External dependencies
-            - Potential impact areas
-          </documentation>
-        </phase>
-        
-        <phase number="5" name="Hypothesis Formation">
-          <description>Form a comprehensive hypothesis about the issue or feature</description>
-          <for_bugs>
-            - Identify the most likely root cause
-            - Trace the bug through the execution path
-            - Determine why the current implementation fails
-            - Consider environmental factors
-          </for_bugs>
-          <for_features>
-            - Identify the optimal integration points
-            - Determine required architectural changes
-            - Plan the implementation approach
-            - Consider scalability and maintainability
-          </for_features>
-        </phase>
-        
-        <phase number="6" name="Hypothesis Validation">
-          <description>Aggressively attempt to disprove the hypothesis</description>
-          <validation_steps>
-            <step name="Search for Alternative Implementations">
-              - Look for similar features implemented differently
-              - Check for deprecated code that might interfere
-            </step>
-            <step name="Configuration and Environment Check">
-              - Search for configuration that could change behavior
-              - Look for environment-specific code paths
-            </step>
-            <step name="Test Case Analysis">
-              - Find existing tests that might contradict hypothesis
-              - Look for test cases that reveal edge cases
-            </step>
-            <step name="Historical Context">
-              - Search for comments explaining design decisions
-              - Look for TODO or FIXME comments related to the area
-            </step>
-          </validation_steps>
-          <outcome>
-            If hypothesis is disproven, return to search phase with new insights.
-            If hypothesis stands, proceed to solution formulation.
-          </outcome>
-        </phase>
-        
-        <phase number="7" name="Solution Formulation">
-          <description>Create a comprehensive technical solution - PRIORITIZE SIMPLICITY</description>
-          <simplicity_principle>
-            CRITICAL: Before proposing any solution, ask yourself:
-            1. What existing variables/functions can I reuse?
-            2. What's the minimal change that fixes the issue?
-            3. Can I leverage existing patterns in the codebase?
-            4. Is there a simpler approach I'm overlooking?
-            
-            The best solution often reuses existing code rather than creating new complexity.
-          </simplicity_principle>
-          
-          <backwards_compatibility_principle>
-            ALWAYS consider backwards compatibility:
-            1. Will existing data/configurations still work with the new code?
-            2. Can we detect and handle legacy formats automatically?
-            3. What migration paths are needed for existing users?
-            4. Are there ways to make changes additive rather than breaking?
-            5. Document any compatibility considerations clearly
-          </backwards_compatibility_principle>
-          <components>
-            <component name="existing_code_analysis">
-              FIRST, identify what can be reused:
-              - Variables that are already calculated but not used where needed
-              - Functions that already do what we need
-              - Patterns in similar features we can follow
-              - Configuration that already exists but isn't applied
-              
-              Example finding:
-              "The variable `calculatedValue` already contains what we need at line X,
-              we just need to use it at line Y instead of recalculating"
-            </component>
-            
-            <component name="implementation_plan">
-              - Start with the SIMPLEST possible fix
-              - Exact files to modify with line numbers
-              - Prefer changing variable usage over creating new logic
-              - Specific code changes required (minimal diff)
-              - Order of implementation steps
-              - Migration strategy if needed
-            </component>
-            
-            <component name="dependency_analysis">
-              - All files that import affected code
-              - API contracts that must be maintained
-              - Existing tests that validate current behavior
-              - Configuration changes required (prefer reusing existing)
-              - Documentation updates needed
-            </component>
-            
-            <component name="test_strategy">
-              - Unit tests to add or modify
-              - Integration tests required
-              - Edge cases to test
-              - Performance testing needs
-              - Manual testing scenarios
-            </component>
-            
-            <component name="risk_assessment">
-              - Breaking changes identified
-              - Performance implications
-              - Security considerations
-              - Backward compatibility issues
-              - Rollback strategy
-            </component>
-          </components>
-        </phase>
-        
-        <phase number="8" name="Acceptance Criteria">
-          <description>Create extremely detailed acceptance criteria</description>
-          <format>
-            Given [detailed context including system state]
-            When [specific user or system action]
-            Then [exact expected outcome]
-            And [additional verifiable outcomes]
-            But [what should NOT happen]
-            
-            Include:
-            - Specific UI changes with exact text/behavior
-            - API response formats
-            - Database state changes
-            - Performance requirements
-            - Error handling scenarios
-          </format>
-          <guidelines>
-            - Each criterion must be independently testable
-            - Include both positive and negative test cases
-            - Specify exact error messages and codes
-            - Define performance thresholds where applicable
-          </guidelines>
-        </phase>
-        
-        <phase number="9" name="Issue Scoping Output">
-          <description>Format the comprehensive issue scoping section</description>
-          <output_template><![CDATA[
-## 🔍 Comprehensive Issue Scoping
-
-### Root Cause / Implementation Target
-[Detailed explanation of the core issue or feature target, focusing on the practical problem first]
-
-### Affected Components
-- **Primary Files:**
-  - `path/to/file1.ts` (lines X-Y): [Purpose and changes needed]
-  - `path/to/file2.ts` (lines A-B): [Purpose and changes needed]
-
-- **Secondary Impact:**
-  - Files that import affected components
-  - Related test files
-  - Documentation files
-
-### Current Implementation Analysis
-[Detailed explanation of how the current code works, with specific examples showing the data flow]
-Example: "The function at line X calculates [value] by [method], which results in [actual behavior]"
+    <step number="2">
+      <name>Detect Current Repository Information</name>
+      <instructions>
+        Verify we're in a Git repository and capture the GitHub remote for safe submission.
 
-### Proposed Implementation
+        1) Check if inside a git repository:
+        <execute_command>
+        <command>git rev-parse --is-inside-work-tree 2>/dev/null || echo "not-git-repo"</command>
+        </execute_command>
 
-#### Step 1: [First implementation step]
-- File: `path/to/file.ts`
-- Changes: [Specific code changes]
-- Rationale: [Why this change is needed]
+        If the output is "not-git-repo", stop:
+        <attempt_completion>
+        <result>
+        This mode must be run from within a GitHub repository. Navigate to a git repository and try again.
+        </result>
+        </attempt_completion>
 
-#### Step 2: [Second implementation step]
-[Continue for all steps...]
+        2) Get origin remote and normalize to OWNER/REPO:
+        <execute_command>
+        <command>git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'</command>
+        </execute_command>
 
-### Code Architecture Considerations
-- Design patterns to follow
-- Existing patterns in codebase to match
-- Architectural constraints
+        If no origin remote exists, stop:
+        <attempt_completion>
+        <result>
+        No GitHub 'origin' remote found. Configure a GitHub remote and retry.
+        </result>
+        </attempt_completion>
+
+        Record the normalized OWNER/REPO (e.g., owner/repo) as [OWNER_REPO] to pass via --repo during submission.
+ 
+         3) Combined monorepo check and roots discovery (single command):
+         <execute_command>
+         <command>set -e; if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then echo "not-git-repo"; exit 0; fi; OWNER_REPO=$(git remote get-url origin 2>/dev/null | sed -E 's/.*[:/]([^/]+)\/([^/]+)(\.git)?$/\1\/\2/' | sed 's/\.git$//'); IS_MONO=false; [ -f package.json ] && grep -q '"workspaces"' package.json && IS_MONO=true; for f in lerna.json pnpm-workspace.yaml rush.json; do [ -f "$f" ] && IS_MONO=true; done; ROOTS="."; if [ "$IS_MONO" = true ]; then ROOTS=$(git ls-files -z | tr '\0' '\n' | grep -E '^(apps|packages|services|libs)/[^/]+/package\.json$' | sed -E 's#/package\.json$##' | sort -u | paste -sd, -); [ -z "$ROOTS" ] && ROOTS=$(find . -maxdepth 3 -name package.json -not -path "./node_modules/*" -print0 | xargs -0 -n1 dirname | grep -E '^(\.|\.\/(apps|packages|services|libs)\/[^/]+)$' | sort -u | paste -sd, -); fi; echo "OWNER_REPO=$OWNER_REPO"; echo "IS_MONOREPO=$IS_MONO"; echo "ROOTS=$ROOTS"</command>
+         </execute_command>
+ 
+         Interpretation:
+         - If output contains OWNER_REPO, IS_MONOREPO, and ROOTS, record them and treat Step 3 as satisfied.
+         - If output is "not-git-repo", stop as above.
+         - If IS_MONOREPO=true but ROOTS is empty, perform Step 3 to determine roots manually.
+ 
+         <update_todo_list>
+           <todos>
+           [x] Detect repository context (OWNER/REPO, monorepo, roots)
+           [ ] Perform targeted codebase discovery (iteration N)
+           [ ] Clarify missing details (repro or desired outcome)
+           [ ] Classify type (Bug | Enhancement)
+           [ ] Assemble Issue Body
+           [ ] Review and submit (Submit now | Submit now and assign to me)
+           </todos>
+         </update_todo_list>
+      </instructions>
+    </step>
 
-### Testing Requirements
-- Unit Tests:
-  - [ ] Test case 1: [Description]
-  - [ ] Test case 2: [Description]
-- Integration Tests:
-  - [ ] Test scenario 1: [Description]
-- Edge Cases:
-  - [ ] Edge case 1: [Description]
+    <step number="3">
+      <name>Determine Repository Structure (Monorepo/Standard)</name>
+      <instructions>
+        If Step 2's combined detection output includes IS_MONOREPO and ROOTS, mark this step complete and proceed to Step 4. Otherwise, use the manual process below.
 
-### Performance Impact
-- Expected performance change: [Increase/Decrease/Neutral]
-- Benchmarking needed: [Yes/No, specifics]
-- Optimization opportunities: [List any]
+        Identify whether this is a monorepo and record the search root(s).
 
-### Security Considerations
-- Input validation requirements
-- Authentication/Authorization changes
-- Data exposure risks
+        1) List top-level entries:
+        <list_files>
+        <path>.</path>
+        <recursive>false</recursive>
+        </list_files>
 
-### Migration Strategy
-[If applicable, how to migrate existing data/functionality]
+        2) Monorepo indicators:
+        - package.json with "workspaces"
+        - lerna.json, pnpm-workspace.yaml, rush.json
+        - Top-level directories like apps/, packages/, services/, libs/
 
-### Rollback Plan
-[How to safely rollback if issues arise]
+        If monorepo is detected:
+        - Discover package roots by locating package.json files under these directories
+        - Prefer scoping searches to the package most aligned with the user's description
+        - Ask for package selection if ambiguous
 
-### Dependencies and Breaking Changes
-- External dependencies affected: [List]
-- API contract changes: [List]
-- Breaking changes for users: [List with mitigation]
-          ]]></output_template>
-        </phase>
-      </sub_workflow>
-      
-      Additional considerations for monorepo repositories:
-      - Scope all searches to the identified package (if monorepo)
-      - Check for cross-package dependencies
-      - Verify against package-specific conventions
-      - Look for package-specific configuration
-      - Check if changes affect multiple packages
-      - Identify shared dependencies that might be impacted
-      - Look for workspace-specific scripts or tooling
-      - Consider package versioning implications
-      
-      After completing the comprehensive issue scoping, update the main todo list to show
-      all investigation steps are complete:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-          [x] Extract keywords from the issue description
-          [x] Perform initial broad codebase search
-          [x] Analyze search results and identify key components
-          [x] Deep dive into relevant files and implementations
-          [x] Form initial hypothesis about the issue/feature
-          [x] Attempt to disprove hypothesis through further investigation
-          [x] Identify all affected files and dependencies
-          [x] Map out the complete implementation approach
-          [x] Document technical risks and edge cases
-          [x] Formulate comprehensive technical solution
-          [x] Create detailed acceptance criteria
-          [x] Prepare issue scoping summary
-      [-] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+        If standard repository:
+        - Use repository root for searches
 
-  <step number="8">
-    <name>Check for Repository Issue Templates</name>
-    <instructions>
-      Check if the repository has custom issue templates and use them. If not, create a simple generic template.
-      
-      1. Check for issue templates in standard locations:
-      <list_files>
-      <path>.github/ISSUE_TEMPLATE</path>
-      <recursive>true</recursive>
-      </list_files>
-      
-      2. Also check for single template file:
-      <list_files>
-      <path>.github</path>
-      <recursive>false</recursive>
-      </list_files>
-      
-      Look for files like:
-      - .github/ISSUE_TEMPLATE/*.md
-      - .github/ISSUE_TEMPLATE/*.yml
-      - .github/ISSUE_TEMPLATE/*.yaml
-      - .github/issue_template.md
-      - .github/ISSUE_TEMPLATE.md
-      
-      3. If templates are found:
-         a. Parse the template files to extract:
-            - Template name and description
-            - Required fields
-            - Template body structure
-            - Labels to apply
-         
-         b. For YAML templates, look for:
-            - name: Template display name
-            - description: Template description
-            - labels: Default labels
-            - body: Form fields or markdown template
-         
-         c. For Markdown templates, look for:
-            - Front matter with metadata
-            - Template structure with placeholders
-      
-      4. If multiple templates exist, ask user to choose:
-      <ask_followup_question>
-      <question>I found the following issue templates in this repository. Which one would you like to use?</question>
-      <follow_up>
-      <suggest>[Template 1 name]: [Template 1 description]</suggest>
-      <suggest>[Template 2 name]: [Template 2 description]</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      5. If no templates are found:
-         - Create a simple generic template based on issue type
-         - For bugs: Basic structure with description, steps to reproduce, expected vs actual
-         - For features: Problem description, proposed solution, impact
-      
-      6. Store the selected/created template information:
-         - Template content/structure
-         - Required fields
-         - Default labels
-         - Any special formatting requirements
-      
-      Update todos:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-      [x] Check for repository issue templates
-      [-] Draft issue content
-      [ ] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [-] Perform targeted codebase discovery (iteration N)
+          [ ] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
 
-  <step number="9">
-    <name>Draft Issue Content</name>
-    <instructions>
-      Create the issue body using the template from step 8 and all verified information from codebase exploration.
-      
-      If using a repository template:
-      - Fill in the template fields with gathered information
-      - Include code references and findings where appropriate
-      - Respect the template's structure and formatting
-      
-      If using a generated template (no repo templates found):
-      
-      For Bug Reports:
-      ```
-      ## Description
-      [Clear description of the bug with code context]
-      
-      ## Steps to Reproduce
-      1. [Step with relevant code paths]
-      2. [Step with component references]
-      3. [Continue with specific details]
-      
-      ## Expected Behavior
-      [What should happen based on code logic]
-      
-      ## Actual Behavior
-      [What actually happens]
-      
-      ## Additional Context
-      - Version: [from package.json if found]
-      - Environment: [any relevant details]
-      - Error logs: [if any]
-      
-      ## Code Investigation
-      [Include findings from codebase exploration]
-      - Relevant files: [list with line numbers]
-      - Possible cause: [hypothesis from code review]
-      
-      [If user is contributing, add the comprehensive issue scoping section from step 7]
-      ```
-      
-      For Feature Requests:
-      ```
-      ## Problem Description
-      [What problem does this solve, who is affected, when it happens]
-      
-      ## Current Behavior
-      [How it works now with specific examples]
-      
-      ## Proposed Solution
-      [What should change]
-      
-      ## Impact
-      [Who benefits and how]
-      
-      ## Technical Context
-      [Findings from codebase exploration]
-      - Similar features: [code references]
-      - Integration points: [from exploration]
-      - Architecture considerations: [if any]
-      
-      [If contributing, add the comprehensive issue scoping section from step 7]
-      ```
-      
-      Update todos:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-      [x] Check for repository issue templates
-      [x] Draft issue content
-      [-] Review and confirm with user
-      [ ] Create GitHub issue
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+    <step number="4">
+      <name>Codebase-Aware Context Discovery (Iterative)</name>
+      <instructions>
+        Purpose: Understand the context of the user's description by exploring the codebase. This step is repeatable.
+
+        Discovery workflow (respect one-tool-per-message):
+        1) Extract keywords, component names, error phrases, and concepts from the user's message or latest reply.
+        2) Run semantic search:
+        <codebase_search>
+        <query>[Keywords from user's description or latest reply]</query>
+        </codebase_search>
+
+        3) Refine with targeted regex where helpful:
+        <search_files>
+        <path>.</path>
+        <regex>[exact error strings|component names|feature flags]</regex>
+        </search_files>
+
+        4) Read key files for verification when necessary:
+        <read_file>
+        <path>[relevant file path from search hits]</path>
+        </read_file>
+
+        Guidance:
+        - Early-stop per iteration when top hits converge (~70%) or you can name the exact feature/component involved.
+        - Escalate-once per iteration if signals conflict: run one refined batch, then proceed.
+        - Keep findings internal; do NOT include file paths, line numbers, stack traces, or diffs in the final prompt.
+
+        Iteration rules:
+        - After ANY new user input or clarification, return to this step with updated keywords.
+        - Update internal notes and TODOs to reflect the current iteration (e.g., iteration 2, 3, ...).
 
-  <step number="10">
-    <name>Review and Confirm with User</name>
-    <instructions>
-      Present the complete drafted issue to the user for review, highlighting the
-      code-verified information:
-      
-      <ask_followup_question>
-      <question>I've prepared the following GitHub issue based on my analysis of the codebase and your description. I've verified the technical details against the actual implementation. Please review:
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [-] Perform targeted codebase discovery (iteration N)
+          [ ] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
 
-      [Show the complete formatted issue content]
+    <step number="5">
+      <name>Clarify Missing Details (Guided by Findings)</name>
+      <instructions>
+        Ask minimal, targeted questions grounded by what you found in code.
+
+        For Bug reports:
+        <ask_followup_question>
+        <question>I’m verifying the behavior around [feature/component inferred from code]. Could you provide a minimal reproduction and quick impact details?</question>
+        <follow_up>
+        <suggest>Repro format: 1) Environment/setup 2) Steps 3) Expected 4) Actual 5) Variations (only if you tried them)</suggest>
+        <suggest>Impact: Who is affected and how often does this happen?</suggest>
+        <suggest>Cost: Approximate time or outcome cost per occurrence (optional)</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        For Enhancements:
+        <ask_followup_question>
+        <question>To capture the improvement well, what is the user goal and value in plain language?</question>
+        <follow_up>
+        <suggest>State the user goal and when it occurs</suggest>
+        <suggest>Describe the desired behavior conceptually (no code)</suggest>
+        <suggest>Value: Who benefits and what improves (speed, clarity, fewer errors, conversions)?</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Discrepancies:
+        - If you found contradictions between description and code, present concrete, plain-language examples (no code) and ask for confirmation.
+
+        Loop-back:
+        - After receiving any answer, return to Step 4 (Discovery) with the new information and repeat as needed.
 
-      Key verifications made:
-      - ✓ Component locations confirmed in code
-      - ✓ Error messages matched to source
-      - ✓ Architecture compatibility checked
-      [List other relevant verifications]
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [-] Clarify missing details (repro or desired outcome)
+          [ ] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
 
-      Would you like me to create this issue, or would you like to make any changes?</question>
-      <follow_up>
-      <suggest>Yes, create this issue in the detected repository</suggest>
-      <suggest>Modify the problem description</suggest>
-      <suggest>Add more technical details</suggest>
-      <suggest>Change the title to: [let me specify]</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      If user requests changes, make them and show the updated version for confirmation.
-      
-      After confirmation:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-      [x] Check for repository issue templates
-      [x] Draft issue content
-      [x] Review and confirm with user
-      [-] Prepare issue for submission
-      [ ] Handle submission choice
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+    <step number="6">
+      <name>Classify Type (Provisional and Repeatable)</name>
+      <instructions>
+        Use the user's description plus verified findings to choose:
+        - Bug indicators: matched error strings; broken behavior in existing features; regression indicators.
+        - Enhancement indicators: capability absent; extension of existing feature; workflow improvement.
+        - Impact snapshot (optional): Severity (Blocker/High/Medium/Low) and Reach (Few/Some/Many). If uncertain, omit and proceed.
+
+        Confirm with the user if uncertain:
+        <ask_followup_question>
+        <question>Based on the behavior around [feature/component], should we frame this as a Bug or an Enhancement?</question>
+        <follow_up>
+        <suggest>Bug Report</suggest>
+        <suggest>Enhancement</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Reclassification:
+        - If later evidence or user info changes the type, reclassify and loop back to Step 4 for a fresh discovery iteration.
 
-  <step number="11">
-    <name>Prepare Issue for Submission</name>
-    <instructions>
-      Once user confirms the issue content, prepare it for submission:
-      
-      First, perform final duplicate check with refined search based on our findings:
-      <execute_command>
-      <command>gh issue list --repo $REPO_FULL_NAME --search "[key terms from verified analysis]" --state all --limit 10</command>
-      </execute_command>
-      
-      If no exact duplicates are found, save the issue content to a temporary file within the project:
-      
-      <write_to_file>
-      <path>./github_issue_draft.md</path>
-      <content>[The complete formatted issue body from step 8]</content>
-      <line_count>[calculated line count]</line_count>
-      </write_to_file>
-      
-      After saving the issue draft, ask the user how they would like to proceed:
-      
-      <ask_followup_question>
-      <question>I've saved the issue draft to ./github_issue_draft.md. The issue is ready for submission with the following details:
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [-] Classify type (Bug | Enhancement)
+          [ ] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
 
-      Title: "[Descriptive title with component name]"
-      Labels: [appropriate labels based on issue type]
-      Repository: $REPO_FULL_NAME
+    <step number="7">
+      <name>Assemble Issue Body</name>
+      <instructions>
+        Build a concise, non-technical issue body. Omit empty sections entirely.
+
+        Format:
+        ```
+        ## Type
+        Bug | Enhancement
+
+        ## Problem / Value
+        [One or two sentences that capture the problem and why it matters in plain language]
+
+        ## Context
+        [Who is affected and when it happens]
+        [Enhancement: desired behavior conceptually, in the user's words]
+        [Bug: current observed behavior in plain language]
+
+        ## Reproduction (Bug only, if available)
+        1) Steps (each action/command)
+        2) Expected result
+        3) Actual result
+        4) Variations tried (include only if the user explicitly provided them)
+
+        ## Constraints/Preferences
+        [Performance, accessibility, UX, or other considerations]
+        ```
+
+        Rules:
+        - Keep non-technical; do NOT include code paths, line numbers, stack traces, or diffs.
+        - Ground the wording in verified behavior, but keep implementation details internal.
+        - Sourcing: Do not infer or fabricate reproduction details or “Variations tried.” Include them only if explicitly provided by the user; otherwise omit the line.
+        - Quoting fidelity: If the user lists “Variations tried,” include them faithfully (verbatim or clearly paraphrased without adding new items).
+        - Value framing: Ensure the “Problem / Value” explains why it matters (impact on users or outcomes) in plain language.
+        - Title: Produce a concise Title (≤ 80 chars) prefixed with [BUG] or [ENHANCEMENT]; when helpful, append a brief value phrase in parentheses, e.g., “(blocks new runs)”.
+
+        Iteration note:
+        - If new info arrives after drafting, loop back to Step 4, then update this draft accordingly.
 
-      How would you like to proceed?</question>
-      <follow_up>
-      <suggest>Submit the issue now to the repository</suggest>
-      <suggest>Let me make some edits to the issue first</suggest>
-      <suggest>I'll submit it manually later</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      Based on the user's response:
-      
-      If "Submit the issue now":
-        - Use gh issue create with the saved file
-        - Provide the created issue URL and number
-        - Clean up the temporary file
-        - Complete the workflow
-      
-      If "Let me make some edits":
-        - Ask what changes they'd like to make
-        - Update the draft file with their changes
-        - Return to the submission question
-      
-      If "I'll submit it manually":
-        - Inform them the draft is saved at the configured location
-        - Provide the gh command they can use later
-        - Complete the workflow without submission
-      
-      Update todos based on the outcome:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-      [x] Check for repository issue templates
-      [x] Draft issue content
-      [x] Review and confirm with user
-      [x] Prepare issue for submission
-      [-] Handle submission choice
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [x] Classify type (Bug | Enhancement)
+          [-] Assemble Issue Body
+          [ ] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
 
-  <step number="12">
-    <name>Handle Submission Choice</name>
-    <instructions>
-      This step handles the user's choice from step 9.
-      
-      OPTION 1: Submit the issue now
-      If the user chooses to submit immediately:
-      
-      <execute_command>
-      <command>gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title]" --body-file ./github_issue_draft.md --label "[appropriate labels]"</command>
-      </execute_command>
-      
-      Label selection based on findings:
-      - Bug: Use "bug" label
-      - Feature: Use "enhancement" label
-      - If affects multiple packages in monorepo: add "affects-multiple" label
-      
-      After successful creation:
-      - Capture and display the issue URL
-      - Clean up the temporary file:
-        <execute_command>
-        <command>rm ./github_issue_draft.md</command>
-        </execute_command>
-      - Provide a summary of key findings included
-      
-      OPTION 2: Make edits
-      If the user wants to edit:
-      
-      <ask_followup_question>
-      <question>What changes would you like to make to the issue?</question>
-      <follow_up>
-      <suggest>Update the title</suggest>
-      <suggest>Modify the problem description</suggest>
-      <suggest>Add or remove technical details</suggest>
-      <suggest>Change the labels or other metadata</suggest>
-      </follow_up>
-      </ask_followup_question>
-      
-      - Apply the requested changes to the draft
-      - Update the file with write_to_file
-      - Return to step 9 to ask about submission again
-      
-      OPTION 3: Manual submission
-      If the user will submit manually:
-      
-      Provide clear instructions:
-      "The issue draft has been saved to ./github_issue_draft.md
+    <step number="8">
+      <name>Review and Submit (Single-Step)</name>
+      <instructions>
+        Present the full current issue details in a code block. Offer two submission options; any other response is treated as a change request.
+
+        <ask_followup_question>
+        <question>Review the current issue details. Select one of the options below or specify any changes or other workflow you would like me to perform:
+
+```md
+Title: [ISSUE_TITLE]
+
+[ISSUE_BODY]
+```</question>
+        <follow_up>
+        <suggest>Submit now</suggest>
+        <suggest>Submit now and assign to me</suggest>
+        </follow_up>
+        </ask_followup_question>
+
+        Responses:
+        - If "Submit now":
+          Prepare:
+            - Title: derive from Summary (≤ 80 chars, plain language)
+            - Body: the finalized issue body
+
+          Execute:
+          <execute_command>
+          <command>gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"</command>
+          </execute_command>
+
+        - If "Submit now and assign to me":
+          Execute (assignment at creation; falls back to edit if needed):
+          <execute_command>
+          <command>ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" --assignee "@me") || true; if [ -z "$ISSUE_URL" ]; then ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"); gh issue edit "$ISSUE_URL" --add-assignee "@me"; fi; echo "$ISSUE_URL"</command>
+          </execute_command>
+
+        - Any other response:
+          - Collect requested edits and apply them
+          - Loop back to Step 4 (Discovery) if new information affects context
+          - Re-assemble in Step 7
+          - Rerun this step and present the updated issue details
+
+        On success: Capture the created issue URL from stdout and complete:
+        <attempt_completion>
+        <result>
+        Created issue: [URL]
+        </result>
+        </attempt_completion>
+
+        On failure: Present the error succinctly and offer to retry after fixing gh setup (installation/auth). Provide the computed Title and Body inline so the user can submit manually if needed.
 
-      To submit it later, you can use:
-      gh issue create --repo $REPO_FULL_NAME --title "[Your title]" --body-file ./github_issue_draft.md --label "[labels]"
-      
-      Or you can copy the content and create the issue through the GitHub web interface."
-      
-      Final todo update:
-      <update_todo_list>
-      <todos>
-      [x] Detect current repository information
-      [x] Determine repository structure (monorepo/standard)
-      [x] Perform initial codebase discovery
-      [x] Analyze user request to determine issue type
-      [x] Gather and verify additional information
-      [x] Determine if user wants to contribute
-      [x] Perform issue scoping (if contributing)
-      [x] Check for repository issue templates
-      [x] Draft issue content
-      [x] Review and confirm with user
-      [x] Prepare issue for submission
-      [x] Handle submission choice
-      </todos>
-      </update_todo_list>
-    </instructions>
-  </step>
+        <update_todo_list>
+          <todos>
+          [x] Detect repository context (OWNER/REPO, monorepo, roots)
+          [x] Perform targeted codebase discovery (iteration N)
+          [x] Clarify missing details (repro or desired outcome)
+          [x] Classify type (Bug | Enhancement)
+          [x] Assemble Issue Body
+          [x] Review and submit (Submit now | Submit now and assign to me)
+          </todos>
+        </update_todo_list>
+      </instructions>
+    </step>
+  </steps>
+
+  <completion_criteria>
+    <criterion>Repository detection (git repo present and origin remote configured) is performed before any submission.</criterion>
+    <criterion>Issue is submitted via gh after choosing "Submit now" or "Submit now and assign to me", and the created issue URL is returned.</criterion>
+    <criterion>When "Submit now and assign to me" is chosen, the issue is assigned to the current GitHub user using --assignee "@me" (or gh issue edit fallback).</criterion>
+    <criterion>Submission uses Title and Body only and specifies --repo [OWNER_REPO] discovered in Step 2; no temporary files or file paths are used.</criterion>
+    <criterion>Language is plain and user-centric; no technical artifacts included in the issue body.</criterion>
+    <criterion>Content grounded by repeated codebase exploration cycles as needed.</criterion>
+    <criterion>Early-stop/escalate-once applied per iteration; unlimited iterations across the conversation.</criterion>
+    <criterion>The merged step offers "Submit now" or "Submit now and assign to me"; any other response is treated as a change request and the step is shown again with the full current issue details.</criterion>
+  </completion_criteria>
 </workflow>

.roo/rules-issue-writer/2_github_issue_templates.xml

@@ -1,190 +0,0 @@
-<github_issue_templates>
-  <overview>
-    This mode prioritizes using repository-specific issue templates over hardcoded ones.
-    If no templates exist in the repository, simple generic templates are created on the fly.
-  </overview>
-
-  <template_detection>
-    <locations>
-      <location priority="1">.github/ISSUE_TEMPLATE/*.yml</location>
-      <location priority="2">.github/ISSUE_TEMPLATE/*.yaml</location>
-      <location priority="3">.github/ISSUE_TEMPLATE/*.md</location>
-      <location priority="4">.github/issue_template.md</location>
-      <location priority="5">.github/ISSUE_TEMPLATE.md</location>
-    </locations>
-    
-    <yaml_template_structure>
-      <field name="name">Display name of the template</field>
-      <field name="description">Brief description of when to use this template</field>
-      <field name="title">Default issue title (optional)</field>
-      <field name="labels">Array of labels to apply</field>
-      <field name="assignees">Array of default assignees</field>
-      <field name="body">Array of form elements or markdown content</field>
-    </yaml_template_structure>
-    
-    <yaml_form_elements>
-      <element type="markdown">
-        <description>Static markdown content</description>
-        <attributes>
-          <attr name="value">The markdown content to display</attr>
-        </attributes>
-      </element>
-      
-      <element type="input">
-        <description>Single-line text input</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="placeholder">Placeholder text</attr>
-          <attr name="value">Default value</attr>
-          <attr name="required">Boolean</attr>
-        </attributes>
-      </element>
-      
-      <element type="textarea">
-        <description>Multi-line text input</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="placeholder">Placeholder text</attr>
-          <attr name="value">Default value</attr>
-          <attr name="required">Boolean</attr>
-          <attr name="render">Language for syntax highlighting</attr>
-        </attributes>
-      </element>
-      
-      <element type="dropdown">
-        <description>Dropdown selection</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="options">Array of options</attr>
-          <attr name="required">Boolean</attr>
-        </attributes>
-      </element>
-      
-      <element type="checkboxes">
-        <description>Multiple checkbox options</description>
-        <attributes>
-          <attr name="id">Unique identifier</attr>
-          <attr name="label">Display label</attr>
-          <attr name="description">Help text</attr>
-          <attr name="options">Array of checkbox items</attr>
-        </attributes>
-      </element>
-    </yaml_form_elements>
-    
-    <markdown_template_structure>
-      <front_matter>
-        Optional YAML front matter with:
-        - name: Template name
-        - about: Template description
-        - title: Default title
-        - labels: Comma-separated or array
-        - assignees: Comma-separated or array
-      </front_matter>
-      <body>
-        Markdown content with sections and placeholders
-        Common patterns:
-        - Headers with ##
-        - Placeholder text in brackets or as comments
-        - Checklists with - [ ]
-        - Code blocks with ```
-      </body>
-    </markdown_template_structure>
-  </template_detection>
-
-  <generic_templates>
-    <description>
-      When no repository templates exist, create simple templates based on issue type.
-      These should be minimal and focused on gathering essential information.
-    </description>
-    
-    <bug_template>
-      <structure>
-        - Description: Clear explanation of the bug
-        - Steps to Reproduce: Numbered list
-        - Expected Behavior: What should happen
-        - Actual Behavior: What actually happens
-        - Additional Context: Version, environment, logs
-        - Code Investigation: Findings from exploration (if any)
-      </structure>
-      <labels>["bug"]</labels>
-    </bug_template>
-    
-    <feature_template>
-      <structure>
-        - Problem Description: What problem this solves
-        - Current Behavior: How it works now
-        - Proposed Solution: What should change
-        - Impact: Who benefits and how
-        - Technical Context: Code findings (if any)
-      </structure>
-      <labels>["enhancement", "proposal"]</labels>
-    </feature_template>
-  </generic_templates>
-
-  <template_parsing_guidelines>
-    <guideline>
-      When parsing YAML templates:
-      1. Use a YAML parser to extract the structure
-      2. Convert form elements to markdown sections
-      3. Preserve required field indicators
-      4. Include descriptions as help text
-      5. Maintain the intended flow of the template
-    </guideline>
-    
-    <guideline>
-      When parsing Markdown templates:
-      1. Extract front matter if present
-      2. Identify section headers
-      3. Look for placeholder patterns
-      4. Preserve formatting and structure
-      5. Replace generic placeholders with user's information
-    </guideline>
-    
-    <guideline>
-      For template selection:
-      1. If only one template exists, use it automatically
-      2. If multiple exist, let user choose based on name/description
-      3. Match template to issue type when possible (bug vs feature)
-      4. Respect template metadata (labels, assignees, etc.)
-    </guideline>
-  </template_parsing_guidelines>
-
-  <filling_templates>
-    <principle>
-      Fill templates intelligently using gathered information:
-      - Map user's description to appropriate sections
-      - Include code investigation findings where relevant
-      - Preserve template structure and formatting
-      - Don't leave placeholder text unfilled
-      - Add contributor scoping if user is contributing
-    </principle>
-    
-    <mapping_examples>
-      <example from="Steps to Reproduce" to="User's reproduction steps + code paths"/>
-      <example from="Expected behavior" to="What user expects + code logic verification"/>
-      <example from="System information" to="Detected versions + environment"/>
-      <example from="Additional context" to="Code findings + architecture insights"/>
-    </mapping_examples>
-  </filling_templates>
-
-  <no_template_behavior>
-    <description>
-      When no templates exist, create appropriate generic templates on the fly.
-      Keep them simple and focused on essential information.
-    </description>
-    
-    <guidelines>
-      - Don't overwhelm with too many fields
-      - Focus on problem description first
-      - Include technical details only if user is contributing
-      - Use clear, simple section headers
-      - Adapt based on issue type (bug vs feature)
-    </guidelines>
-  </no_template_behavior>
-</github_issue_templates>

.roo/rules-issue-writer/3_best_practices.xml

@@ -1,172 +1,147 @@
 <best_practices>
+  <mode_scope>
+    This mode assembles a template-free issue body grounded by codebase exploration and can submit it via GitHub CLI after explicit confirmation.
+    Submission uses Title and Body only and targets the detected repository after the merged Review and Submit step.
+  </mode_scope>
+
   <mode_behavior>
-    - CRITICAL: This mode assumes the user's FIRST message is already an issue description
-    - Do NOT ask "What would you like to do?" or "Do you want to create an issue?"
-    - Immediately start the issue creation workflow when the user begins talking
-    - Treat their initial message as the problem/feature description
-    - Begin with repository detection and codebase discovery right away
-    - The user is already in "issue creation mode" by choosing this mode
+    - Treat the user's FIRST message as the issue description; do not ask if they want to create an issue.
+    - Start with repository detection (verify git repo; resolve OWNER/REPO from origin), then determine repository structure (monorepo/standard).
+    - After detection, begin codebase discovery scoped to the repository root or the selected package (in monorepos).
+    - Keep final output non-technical; implementation details remain internal.
   </mode_behavior>
-  
-  <template_usage>
-    - ALWAYS check for repository-specific issue templates before creating issues
-    - Use templates from .github/ISSUE_TEMPLATE/ directory if they exist
-    - Parse both YAML (.yml/.yaml) and Markdown (.md) template formats
-    - If multiple templates exist, let the user choose the appropriate one
-    - If no templates exist, create a simple generic template on the fly
-    - NEVER fall back to hardcoded templates - always use repo templates or generate minimal ones
-    - Respect template metadata like labels, assignees, and title patterns
-    - Fill templates intelligently using gathered information from codebase exploration
-  </template_usage>
-  
-  <problem_reporting_focus>
-    - Focus on helping users describe problems clearly, not solutions
-    - The project team will design solutions unless the user explicitly wants to contribute
-    - Don't push users to provide technical details they may not have
-    - Make it easy for non-technical users to report issues effectively
-    
-    CRITICAL: Lead with user impact:
-    - Always explain WHO is affected and WHEN the problem occurs
-    - Use concrete examples with actual values, not abstractions
-    - Show before/after scenarios with specific data
-    - Example: "Users trying to [action] see [actual result] instead of [expected result]"
-  </problem_reporting_focus>
-  
-  <fact_driven_verification>
-    - ALWAYS verify user claims against actual code implementation
-    - For feature requests, aggressively check if current behavior matches user's description
-    - If code shows different intent than user describes, it might be a bug not a feature
-    - Present code evidence when challenging user assumptions
-    - Do not be agreeable - be fact-driven and question discrepancies
-    - Continue verification until facts are established
-    - A "feature request" where code shows the feature should already work is likely a bug
-    
-    CRITICAL additions for thorough analysis:
-    - Trace data flow from where values are created to where they're used
-    - Look for existing variables/functions that already contain needed data
-    - Check if the issue is just missing usage of existing code
-    - Follow imports and exports to understand data availability
-    - Identify patterns in similar features that work correctly
-  </fact_driven_verification>
-  
-  <general_practices>
-    - Always search for existing similar issues before creating a new one
-    - Check for and use repository issue templates before creating content
-    - Include specific version numbers and environment details
-    - Use code blocks with syntax highlighting for code snippets
-    - Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
-    - For bugs, always test if the issue is reproducible
-    - Include screenshots or mockups when relevant (ask user to provide)
-    - Link to related issues or PRs if found during exploration
-    
-    CRITICAL: Use concrete examples throughout:
-    - Show actual data values, not just descriptions
-    - Include specific file paths and line numbers
-    - Demonstrate the data flow with real examples
-    - Bad: "The value is incorrect"
-    - Good: "The function returns '123' when it should return '456'"
-  </general_practices>
-  
-  <contributor_specific>
-    - Only perform issue scoping if user wants to contribute
-    - Reference specific files and line numbers from codebase exploration
-    - Ensure technical proposals align with project architecture
-    - Include implementation steps and issue scoping
-    - Provide clear acceptance criteria in Given/When/Then format
-    - Consider trade-offs and alternative approaches
-    
-    CRITICAL: Prioritize simple solutions:
-    - ALWAYS check if needed functionality already exists before proposing new code
-    - Look for existing variables that just need to be passed/used differently
-    - Prefer using existing patterns over creating new ones
-    - The best fix often involves minimal code changes
-    - Example: "Use existing `modeInfo` from line 234 in export" vs "Create new mode tracking system"
-  </contributor_specific>
-  
-  <backwards_compatibility_focus>
-    ALWAYS consider backwards compatibility:
-    - Think about existing data/configurations already in use
-    - Propose solutions that handle both old and new formats gracefully
-    - Consider migration paths for existing users
-    - Document any breaking changes clearly
-    - Prefer additive changes over breaking changes when possible
-  </backwards_compatibility_focus>
-  
+
+  <value_framing>
+    <principles>
+      - Always pair the problem with user-facing value: who is impacted, when it occurs, and why it matters.
+      - Keep value non-technical (clarity, time saved, fewer errors, better UX, improved accessibility, reduced confusion).
+    </principles>
+    <lightweight_impact_options>
+      - Severity: Blocker | High | Medium | Low (optional)
+      - Reach: Few | Some | Many (optional)
+    </lightweight_impact_options>
+  </value_framing>
+
+  <sourcing_and_provenance>
+    <direct_from_user_only>
+      - Reproduction steps
+      - Variations tried
+      - Environment details
+    </direct_from_user_only>
+    <inference_allowed_with_care>
+      - Problem/Value statement (plain-language synthesis from user wording)
+      - Context (who/when) based on user input; keep code-based signals internal
+    </inference_allowed_with_care>
+    <hallucination_guards>
+      - Never fabricate “Variations tried.” If not provided, omit.
+      - If critical details are missing, ask targeted questions; otherwise proceed with omissions.
+    </hallucination_guards>
+  </sourcing_and_provenance>
+
+  <cli_submission>
+    <confirmation>
+      Use a single merged "Review and Submit" step with options:
+      - Submit now
+      - Submit now and assign to me
+      Any other response is treated as a change request and the step is rerun after applying edits.
+    </confirmation>
+    <repo_detection>
+      Submission requires repository detection (git present, origin configured). Capture normalized OWNER/REPO (e.g., owner/repo) and store as [OWNER_REPO] for submission.
+    </repo_detection>
+    <target_repo>
+      Always specify the target using --repo "[OWNER_REPO]" to avoid ambiguity and ensure the correct repository is used.
+    </target_repo>
+    <assignment>
+      When "Submit now and assign to me" is chosen, create using: --assignee "@me".
+      If creation with --assignee fails (e.g., permissions), create the issue without an assignee and immediately run:
+      gh issue edit <issue-url-or-number> --add-assignee "@me".
+    </assignment>
+    <command_safety>
+      Use --body with robust quoting (for example: --body "$(printf '%s\n' "[ISSUE_BODY]")") or a heredoc; do not create temporary files or reference file paths. Always include --repo "[OWNER_REPO]" and echo the resulting issue URL.
+      In execute_command calls, output only the command string; never include XML tags, CDATA markers, code fences, or backticks in the command payload.
+    </command_safety>
+    <error_handling>
+      On gh errors (installation/auth), present the error and offer to retry after fixing gh setup. Surface the computed Title and Body inline
+      so the user can submit manually if needed.
+    </error_handling>
+  </cli_submission>
+
+  <codebase_exploration>
+    <principles>
+      - Use semantic search first to find relevant areas.
+      - Refine with targeted regex for exact strings (errors, component names, flags).
+      - Read key files to verify behavior; keep evidence internal.
+      - Early-stop when hits converge (~70%) or you can name the exact feature/component.
+      - Escalate-once if signals conflict; run one refined batch, then proceed.
+    </principles>
+    <tool_sequence>
+      1) codebase_search → 2) search_files → 3) read_file (as needed)
+    </tool_sequence>
+    <scoping>
+      In monorepos, scope searches to the selected package when the context is clear; otherwise ask for the relevant package/app if ambiguous.
+    </scoping>
+    <internal_only>
+      Keep language plain and exclude technical artifacts (paths, line numbers, stack traces, diffs) from the final issue body.
+    </internal_only>
+  </codebase_exploration>
+
+  <questioning>
+    <guidelines>
+      - Ask minimal, targeted questions based on what you found in code.
+      - For bugs: request a minimal reproduction (environment, steps, expected, actual, variations).
+      - For enhancements: capture user goal, desired behavior in plain language, and any constraints.
+      - Present discrepancies in plain language (no code) and confirm understanding.
+    </guidelines>
+  </questioning>
+
+  <issue_output_rules>
+    <format>
+      <![CDATA[
+## Type
+Bug | Enhancement
+
+## Problem / Value
+[One or two sentences that capture the problem and why it matters in plain language]
+
+## Context
+[Who is affected and when it happens]
+[Enhancement: desired behavior conceptually, in the user's words]
+[Bug: current observed behavior in plain language]
+
+## Reproduction (Bug only, if available)
+1) Steps (each action/command)
+2) Expected result
+3) Actual result
+4) Variations tried (only if explicitly provided)
+
+## Constraints/Preferences
+[Performance, accessibility, UX, or other considerations]
+      ]]>
+    </format>
+    <rules>
+      - Omit sections that would be empty.
+      - Do not include "Variations tried" unless explicitly provided by the user.
+      - Keep language plain and user-centric.
+      - Exclude technical artifacts (paths, lines, stacks, diffs).
+    </rules>
+  </issue_output_rules>
+
+  <review_stage_presentation>
+    - At each review stage, present the full current issue details (Title + Body) in a markdown code block.
+    - Offer "Submit now" or "Submit now and assign to me" suggestions; treat any other response as a change request and rerun the step after applying edits.
+  </review_stage_presentation>
+
+  <autonomy_and_budgets>
+    - Tool preambles: restate goal briefly, outline a short plan, narrate progress succinctly, summarize final delta.
+    - One-tool-per-message: await results before continuing.
+    - Discovery budget: default max 3 searches before escalate-once; stop when sufficient.
+    - Early-stop: when top hits converge or target is identifiable.
+    - Verbosity: low narrative; detail appears only in structured outputs.
+  </autonomy_and_budgets>
+
   <communication_guidelines>
-    - Be supportive and encouraging to problem reporters
-    - Don't overwhelm users with technical questions upfront
-    - Clearly indicate when technical sections are optional
-    - Guide contributors through the additional requirements
-    - Make the "submit now" option clear for problem reporters
-    - When presenting template choices, include template descriptions to help users choose
-    - Explain that you're using the repository's own templates for consistency
+    - Be direct and concise; avoid jargon in the final issue body.
+    - Keep questions optional and easy to answer with suggested options.
+    - Emphasize WHO is affected and WHEN it happens.
   </communication_guidelines>
-  
-  <template_best_practices>
-    <practice name="template_detection">
-      Always check these locations in order:
-      1. .github/ISSUE_TEMPLATE/*.yml or *.yaml (GitHub form syntax)
-      2. .github/ISSUE_TEMPLATE/*.md (Markdown templates)
-      3. .github/issue_template.md (single template)
-      4. .github/ISSUE_TEMPLATE.md (alternate naming)
-    </practice>
-    
-    <practice name="template_parsing">
-      For YAML templates:
-      - Extract form elements and convert to appropriate markdown sections
-      - Preserve required field indicators
-      - Include field descriptions as context
-      - Respect dropdown options and checkbox lists
-      
-      For Markdown templates:
-      - Parse front matter for metadata
-      - Identify section headers and structure
-      - Replace placeholder text with actual information
-      - Maintain formatting and hierarchy
-    </practice>
-    
-    <practice name="template_filling">
-      - Map gathered information to template sections intelligently
-      - Don't leave placeholder text in the final issue
-      - Add code investigation findings to relevant sections
-      - Include contributor scoping in appropriate section if applicable
-      - Preserve the template's intended structure and flow
-    </practice>
-    
-    <practice name="no_template_handling">
-      When no templates exist:
-      - Create minimal, focused templates
-      - Use simple section headers
-      - Focus on essential information only
-      - Adapt structure based on issue type
-      - Don't overwhelm with unnecessary fields
-    </practice>
-  </template_best_practices>
-  <technical_accuracy_guidelines>
-    <guideline name="thorough_code_analysis">
-      Before proposing ANY solution:
-      1. Use codebase_search extensively to find all related code
-      2. Read multiple files to understand the full context
-      3. Trace variable usage from creation to consumption
-      4. Look for similar working features to understand patterns
-      5. Identify what already exists vs what's actually missing
-    </guideline>
-    
-    <guideline name="simplicity_first">
-      When designing solutions:
-      1. Check if the data/function already exists somewhere
-      2. Look for configuration options before code changes
-      3. Prefer passing existing variables over creating new ones
-      4. Use established patterns from similar features
-      5. Aim for minimal diff size
-    </guideline>
-    
-    <guideline name="precise_technical_details">
-      Always include:
-      - Exact file paths and line numbers
-      - Variable/function names as they appear in code
-      - Before/after code snippets showing minimal changes
-      - Clear explanation of why the simple fix works
-    </guideline>
-  </technical_accuracy_guidelines>
 </best_practices>

.roo/rules-issue-writer/4_common_mistakes_to_avoid.xml

@@ -1,126 +1,109 @@
 <common_mistakes_to_avoid>
   <mode_initialization_mistakes>
-    - CRITICAL: Asking "What would you like to do?" when mode starts
-    - Waiting for user to say "create an issue" or "make me an issue"
-    - Not treating the first user message as the issue description
-    - Delaying the workflow start with unnecessary questions
-    - Asking if they want to create an issue when they've already chosen this mode
-    - Not immediately beginning repository detection and codebase discovery
+    - Asking "What would you like to do?" at start instead of treating the first message as the issue description
+    - Delaying the workflow with unnecessary questions before discovery
+    - Not immediately beginning codebase-aware discovery (semantic search → regex refine → read key files)
+    - Skipping repository detection (git + origin) before discovery or submission
+    - Not validating repository context before gh commands
   </mode_initialization_mistakes>
-  
+
+  <scope_mistakes>
+    - Submitting without explicit user confirmation ("Submit now")
+    - Targeting the wrong repository by relying on current directory defaults; always pass --repo OWNER/REPO detected in Step 2
+    - Performing PR prep, complexity estimates, or technical scoping
+  </scope_mistakes>
+
+  <submission_mistakes>
+    <mistake_block>
+      <mistake>Splitting final review and submission into multiple steps</mistake>
+      <impact>Creates redundant prompts and inconsistent state; leads to janky UX</impact>
+      <correct_approach>Use a single merged "Review and Submit" step offering only: Submit now, Submit now and assign to me; treat any other response as a change request</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Not offering "Submit now and assign to me"</mistake>
+      <impact>Forces manual assignment later; reduces efficiency</impact>
+      <correct_approach>Provide the assignment option and use gh issue create --assignee "@me"; if that fails, immediately run gh issue edit <issue-url-or-number> --add-assignee "@me"</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Using temporary files or --body-file for issue body submission</mistake>
+      <impact>Introduces filesystem dependencies and leaks paths; contradicts single-command policy</impact>
+      <correct_approach>Use inline --body with robust quoting, e.g., --body "$(printf '%s\n' "[ISSUE_BODY]")"; do not reference any file paths</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Omitting --repo or relying on current directory defaults</mistake>
+      <impact>May submit to the wrong repository in multi-repo or worktree contexts</impact>
+      <correct_approach>Always pass --repo [OWNER_REPO] detected in Step 2</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Attempting submission without prior repository detection</mistake>
+      <impact>Commands may target the wrong repo or fail</impact>
+      <correct_approach>Detect git repo and ensure origin is configured before any gh commands</correct_approach>
+    </mistake_block>
+  </submission_mistakes>
+
+  <sourcing_mistakes>
+    <mistake_block>
+      <mistake>Inventing or inferring “Variations tried” when the user didn’t provide any</mistake>
+      <impact>Misleads triage and wastes time reproducing non-existent attempts</impact>
+      <correct_approach>Omit the “Variations tried” line entirely unless explicitly provided; if needed, ask a targeted question first</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Framing only the problem without the value/impact</mistake>
+      <impact>Makes prioritization harder; obscures who benefits and why it matters</impact>
+      <correct_approach>Pair the problem with a plain-language value statement (who, when, why it matters)</correct_approach>
+    </mistake_block>
+    <mistake_block>
+      <mistake>Overstating impact without user signal</mistake>
+      <impact>Damages credibility and misguides prioritization</impact>
+      <correct_approach>Use conservative, plain language; if unsure, omit severity/reach or ask a single targeted question</correct_approach>
+    </mistake_block>
+  </sourcing_mistakes>
+
   <problem_reporting_mistakes>
-    - Vague descriptions like "doesn't work" or "broken"
-    - Missing reproduction steps for bugs
-    - Feature requests without clear problem statements
-    - Not explaining the impact on users
-    - Forgetting to specify when/how the problem occurs
-    - Using wrong labels or no labels
-    - Titles that don't summarize the issue
-    - Not checking for duplicates
+    - Vague descriptions like "doesn't work" without who/when impact
+    - Missing minimal reproduction for bugs (environment, steps, expected, actual, variations)
+    - Enhancement requests that skip the user goal or desired behavior in plain language
+    - Titles/summaries that don't quickly communicate the issue
   </problem_reporting_mistakes>
-  
-  <workflow_mistakes>
-    - Asking for technical details from non-contributing users
-    - Performing issue scoping before confirming user wants to contribute
-    - Requiring acceptance criteria from problem reporters
-    - Making the process too complex for simple problem reports
-    - Not clearly indicating the "submit now" option
-    - Overwhelming users with contributor requirements upfront
-    - Using hardcoded templates instead of repository templates
-    - Not checking for issue templates before creating content
-    - Ignoring template metadata like labels and assignees
-  </workflow_mistakes>
-  
-  <contributor_mistakes>
-    - Starting implementation before approval
-    - Not providing detailed issue scoping when contributing
-    - Missing acceptance criteria for contributed features
-    - Forgetting to include technical context from code exploration
-    - Not considering trade-offs and alternatives
-    - Proposing solutions without understanding current architecture
-  </contributor_mistakes>
-  
-  <technical_analysis_mistakes>
-    <mistake>Not tracing data flow completely through the system</mistake>
-    <impact>Missing that data already exists leads to proposing unnecessary new code</impact>
+
+  <output_mistakes>
+    - Including code paths, line numbers, stack traces, or diffs in the final issue body
+    - Adding labels, metadata, or repository details to the body
+    - Leaving empty section placeholders instead of omitting the section
+    - Using technical jargon instead of plain, user-centric language
+  </output_mistakes>
+
+  <code_exploration_mistakes>
+    <mistake>Skipping semantic search and jumping straight to assumptions</mistake>
+    <impact>Leads to misclassification and inaccurate context</impact>
     <correct_approach>
-      - Use codebase_search extensively to find ALL related code
-      - Trace variables from creation to consumption
-      - Check if needed data is already calculated but not used
-      - Look for similar working features as patterns
+      - Start with codebase_search on extracted keywords
+      - Refine with search_files for exact strings (errors, component names, flags)
+      - read_file only as needed to verify behavior; keep evidence internal
+      - Early-stop when hits converge or you can name the exact feature/component
+      - Escalate-once if signals conflict (one refined pass), then proceed
     </correct_approach>
-    <example>
-      Bad: "Add mode tracking to import function"
-      Good: "The export already includes mode info at line 234, just use it in import at line 567"
-    </example>
-  </technical_analysis_mistakes>
-  
-  <solution_design_mistakes>
-    <mistake>Proposing complex new systems when simple fixes exist</mistake>
-    <impact>Creates unnecessary complexity, maintenance burden, and potential bugs</impact>
+  </code_exploration_mistakes>
+
+  <discrepancy_handling_mistakes>
+    <mistake>Accepting user claims that contradict the codebase without verification</mistake>
+    <impact>Produces misleading or incorrect issue framing</impact>
     <correct_approach>
-      - ALWAYS check if functionality already exists first
-      - Look for minimal changes that solve the problem
-      - Prefer using existing variables/functions differently
-      - Aim for the smallest possible diff
+      - Verify claims against the implementation; trace data from creation → usage
+      - Compare with similar working features to ground expectations
+      - If discrepancies arise, present concrete, plain-language examples (no code) and confirm
     </correct_approach>
-    <example>
-      Bad: "Create new state management system for mode tracking"
-      Good: "Pass existing modeInfo variable from line 45 to the function at line 78"
-    </example>
-  </solution_design_mistakes>
-  
-  <code_verification_mistakes>
-    <mistake>Not reading actual code before proposing solutions</mistake>
-    <impact>Solutions don't match the actual codebase structure</impact>
-    <correct_approach>
-      - Always read the relevant files first
-      - Verify exact line numbers and content
-      - Check imports/exports to understand data availability
-      - Look at similar features that work correctly
-    </correct_approach>
-  </code_verification_mistakes>
-  
-  <pattern_recognition_mistakes>
-    <mistake>Creating new patterns instead of following existing ones</mistake>
-    <impact>Inconsistent codebase, harder to maintain</impact>
-    <correct_approach>
-      - Find similar features that work correctly
-      - Follow the same patterns and structures
-      - Reuse existing utilities and helpers
-      - Maintain consistency with the codebase style
-    </correct_approach>
-  </pattern_recognition_mistakes>
-  
-  <template_usage_mistakes>
-    <mistake>Using hardcoded templates when repository templates exist</mistake>
-    <impact>Issues don't follow repository conventions, may be rejected or need reformatting</impact>
-    <correct_approach>
-      - Always check .github/ISSUE_TEMPLATE/ directory first
-      - Parse and use repository templates when available
-      - Only create generic templates when none exist
-    </correct_approach>
-  </template_usage_mistakes>
-  
-  <template_parsing_mistakes>
-    <mistake>Not properly parsing YAML template structure</mistake>
-    <impact>Missing required fields, incorrect formatting, lost metadata</impact>
-    <correct_approach>
-      - Parse YAML templates to extract all form elements
-      - Convert form elements to appropriate markdown sections
-      - Preserve field requirements and descriptions
-      - Maintain dropdown options and checkbox lists
-    </correct_approach>
-  </template_parsing_mistakes>
-  
-  <template_filling_mistakes>
-    <mistake>Leaving placeholder text in final issue</mistake>
-    <impact>Unprofessional appearance, confusion about what information is needed</impact>
-    <correct_approach>
-      - Replace all placeholders with actual information
-      - Remove instruction text meant for template users
-      - Fill every section with relevant content
-      - Add "N/A" for truly inapplicable sections
-    </correct_approach>
-  </template_filling_mistakes>
+  </discrepancy_handling_mistakes>
+
+  <questioning_mistakes>
+    - Asking broad, unfocused questions instead of targeted ones based on findings
+    - Demanding technical details from non-technical users
+    - Failing to provide easy, suggested answer formats (repro scaffold, goal statement)
+  </questioning_mistakes>
+
+  <consistency_mistakes>
+    - Mixing internal technical evidence into the final body
+    - Ignoring the issue format or adding extra sections
+    - Using inconsistent tone or switching between technical and non-technical language
+  </consistency_mistakes>
 </common_mistakes_to_avoid>

.roo/rules-issue-writer/5_examples.xml

@@ -0,0 +1,134 @@
+<issue_examples>
+  <overview>
+    Examples of assembling template-free issue prompts grounded by codebase exploration, with optional CLI submission after explicit confirmation.
+    Repository detection precedes submission; review and submission occur in a single merged step offering "Submit now" or "Submit now and assign to me". Any other response is treated as a change request.
+  </overview>
+
+  <example name="bug_dark_theme_button_invisible">
+    <user_input>
+      In dark theme the Submit button is almost invisible on the New Run page.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>dark theme submit button visibility</query>
+</codebase_search>
+
+<search_files>
+<path>.</path>
+<regex>Submit|button|dark|theme</regex>
+</search_files>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: matches found in UI components related to theme; wording grounded to user impact.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+4) Variations tried: Different browsers (Chrome/Firefox) show same result
+    ]]></final_issue_body>
+  </example>
+
+  <example name="enhancement_copy_run_confirmation">
+    <user_input>
+      I accidentally click "Copy Run" sometimes; would be great to have a simple confirmation.
+    </user_input>
+    <discovery>
+      <tool_calls>
+        <![CDATA[
+<codebase_search>
+<query>Copy Run confirmation</query>
+</codebase_search>
+        ]]>
+      </tool_calls>
+      <notes>
+        Internal: feature entry point identified; keep final output non-technical and user-centric.
+      </notes>
+    </discovery>
+    <final_issue_body><![CDATA[
+## Type
+Enhancement
+
+## Problem / Value
+Add a confirmation dialog before copying an existing run to prevent accidental duplication.
+
+## Context
+Users sometimes click "Copy Run" by mistake when browsing runs; a simple confirmation would prevent accidental duplication.
+
+## Constraints/Preferences
+Keep the flow lightweight and unobtrusive; avoid slowing down intentional copies.
+    ]]></final_issue_body>
+  </example>
+
+  <example name="bug_submission_review_and_assign">
+    <user_input>
+      Dark theme Submit button is invisible; I'd like to file this.
+    </user_input>
+    <final_issue_body><![CDATA[
+## Type
+Bug
+
+## Problem / Value
+In dark theme, the Submit button is hard to see on the new run form, making it difficult for users to complete new runs.
+
+## Context
+Affects users creating new runs with dark theme enabled; the button appears low-contrast and is difficult to locate.
+
+## Reproduction
+1) Steps: Open "New Run" -> Scroll to bottom -> Look for Submit
+2) Expected result: Clearly visible, high-contrast Submit button
+3) Actual result: Button appears nearly invisible in dark theme
+    ]]></final_issue_body>
+    <review_and_submit>
+      <ask_followup_question>
+        <question>Review the current issue details. Select one of the options below or specify any changes or other workflow you would like me to perform:
+
+```md
+Title: [ISSUE_TITLE]
+
+[ISSUE_BODY]
+```</question>
+        <follow_up>
+          <suggest>Submit now</suggest>
+          <suggest>Submit now and assign to me</suggest>
+        </follow_up>
+      </ask_followup_question>
+
+      <execute_command for="submit_now">
+        <command>gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"</command>
+      </execute_command>
+
+      <execute_command for="submit_now_and_assign_to_me">
+        <command>ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")" --assignee "@me") || true; if [ -z "$ISSUE_URL" ]; then ISSUE_URL=$(gh issue create --repo "[OWNER_REPO]" --title "[ISSUE_TITLE]" --body "$(printf '%s\n' "[ISSUE_BODY]")"); gh issue edit "$ISSUE_URL" --add-assignee "@me"; fi; echo "$ISSUE_URL"</command>
+      </execute_command>
+
+      <loopback_note>
+        If a change request is provided, collect the requested edits, update the draft (re-run discovery if new info affects context), then rerun this merged step.
+      </loopback_note>
+
+      <expected_output>https://github.com/OWNER/REPO/issues/123</expected_output>
+    </review_and_submit>
+  </example>
+
+  <policies>
+    <policy>Issues are template-free (Title + Body only).</policy>
+    <policy>Repository detection (git + origin → OWNER/REPO) occurs before submission and is passed explicitly via --repo [OWNER_REPO].</policy>
+    <policy>Never use --body-file or temporary files; submit with inline --body only (no file paths).</policy>
+    <policy>Review and submission happen in one merged step offering "Submit now" or "Submit now and assign to me"; any other response is treated as a change request.</policy>
+    <policy>All discovery is internal; keep final output plain-language.</policy>
+  </policies>
+</issue_examples>

.roo/rules-issue-writer/5_github_cli_usage.xml

@@ -1,342 +0,0 @@
-<github_cli_usage>
-  <overview>
-    The GitHub CLI (gh) provides comprehensive tools for interacting with GitHub.
-    Here's when and how to use each command in the issue creation workflow.
-    
-    Note: This mode prioritizes using repository-specific issue templates over
-    hardcoded ones. Templates are detected and used dynamically from the repository.
-  </overview>
-
-  <pre_creation_commands>
-    <command name="gh issue list">
-      <when_to_use>
-        ALWAYS use this FIRST before creating any issue to check for duplicates.
-        Search for keywords from the user's problem description.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue list --repo $REPO_FULL_NAME --search "dark theme button visibility" --state all --limit 20</command>
-        </execute_command>
-      </example>
-      <options>
-        --search: Search query for issue titles and bodies
-        --state: all, open, or closed
-        --label: Filter by specific labels
-        --limit: Number of results to show
-        --json: Get structured JSON output
-      </options>
-    </command>
-
-    <command name="gh search issues">
-      <when_to_use>
-        Use for more advanced searches across issues and pull requests.
-        Supports GitHub's advanced search syntax.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh search issues --repo $REPO_FULL_NAME "dark theme button" --limit 10</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh issue view">
-      <when_to_use>
-        Use when you find a potentially related issue and need full details.
-        Check if the user's issue is already reported or related.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue view 123 --repo $REPO_FULL_NAME --comments</command>
-        </execute_command>
-      </example>
-      <options>
-        --comments: Include issue comments
-        --json: Get structured data
-        --web: Open in browser
-      </options>
-    </command>
-  </pre_creation_commands>
-
-  <template_detection_commands>
-    <command name="list_files">
-      <when_to_use>
-        Use to check for issue templates in the repository before creating issues.
-        This is not a gh command but necessary for template detection.
-      </when_to_use>
-      <examples>
-        Check for templates in standard location:
-        <list_files>
-        <path>.github/ISSUE_TEMPLATE</path>
-        <recursive>true</recursive>
-        </list_files>
-        
-        Check for single template file:
-        <list_files>
-        <path>.github</path>
-        <recursive>false</recursive>
-        </list_files>
-      </examples>
-    </command>
-
-    <command name="read_file">
-      <when_to_use>
-        Read template files to parse their structure and content.
-        Used after detecting template files.
-      </when_to_use>
-      <examples>
-        Read YAML template:
-        <read_file>
-        <path>.github/ISSUE_TEMPLATE/bug_report.yml</path>
-        </read_file>
-        
-        Read Markdown template:
-        <read_file>
-        <path>.github/ISSUE_TEMPLATE/feature_request.md</path>
-        </read_file>
-      </examples>
-    </command>
-  </template_detection_commands>
-
-  <contributor_only_commands>
-    <note>
-      These commands should ONLY be used if the user has indicated they want to
-      contribute the implementation. Skip these for problem reporters.
-    </note>
-    
-    <command name="gh repo view">
-      <when_to_use>
-        Get repository information and recent activity.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh repo view $REPO_FULL_NAME --json defaultBranchRef,description,updatedAt</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh search prs">
-      <when_to_use>
-        Check recent PRs that might be related to the issue.
-        Look for PRs that modified relevant code.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh search prs --repo $REPO_FULL_NAME "dark theme" --limit 10 --state all</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="git log">
-      <when_to_use>
-        For bug reports from contributors, check recent commits that might have introduced the issue.
-        Use after cloning the repository locally.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>git log --oneline --grep="theme" -n 20</command>
-        </execute_command>
-      </example>
-    </command>
-  </contributor_only_commands>
-
-  <issue_creation_command>
-    <command name="gh issue create">
-      <when_to_use>
-        Only use after:
-        1. Confirming no duplicates exist
-        2. Checking for and using repository templates
-        3. Gathering all required information
-        4. Determining if user is contributing or just reporting
-        5. Getting user confirmation
-      </when_to_use>
-      <bug_report_example>
-        <execute_command>
-        <command>gh issue create --repo $REPO_FULL_NAME --title "[Descriptive title of the bug]" --body-file /tmp/issue_body.md --label "bug"</command>
-        </execute_command>
-      </bug_report_example>
-      <feature_request_example>
-        <execute_command>
-        <command>gh issue create --repo $REPO_FULL_NAME --title "[Problem-focused title]" --body-file /tmp/issue_body.md --label "proposal" --label "enhancement"</command>
-        </execute_command>
-      </feature_request_example>
-      <options>
-        --title: Issue title (required)
-        --body: Issue body text
-        --body-file: Read body from file
-        --label: Add labels (can use multiple times)
-        --assignee: Assign to user
-        --project: Add to project
-        --web: Open in browser to create
-      </options>
-    </command>
-  </issue_creation_command>
-
-  <post_creation_commands>
-    <command name="gh issue comment">
-      <when_to_use>
-        ONLY use if user wants to add additional information after creation.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue comment 456 --repo $REPO_FULL_NAME --body "Additional context or comments."</command>
-        </execute_command>
-      </example>
-    </command>
-
-    <command name="gh issue edit">
-      <when_to_use>
-        Use if user realizes they need to update the issue after creation.
-        Can update title, body, or labels.
-      </when_to_use>
-      <example>
-        <execute_command>
-        <command>gh issue edit 456 --repo $REPO_FULL_NAME --title "[Updated title]" --body "[Updated body]"</command>
-        </execute_command>
-      </example>
-    </command>
-  </post_creation_commands>
-
-  <workflow_integration>
-    <step_1_integration>
-      After user selects issue type, immediately search for related issues:
-      1. Use `gh issue list --search` with keywords from their description
-      2. Show any similar issues found
-      3. Ask if they want to continue or comment on existing issue
-    </step_1_integration>
-
-    <step_2_integration>
-      Template detection (NEW):
-      1. Use list_files to check .github/ISSUE_TEMPLATE/ directory
-      2. Read any template files found (YAML or Markdown)
-      3. Parse template structure and metadata
-      4. If multiple templates, let user choose
-      5. If no templates, prepare to create generic one
-    </step_2_integration>
-
-    <step_3_integration>
-      Decision point for contribution:
-      1. Ask user if they want to contribute implementation
-      2. If yes: Use contributor commands for codebase investigation
-      3. If no: Skip directly to creating a problem-focused issue
-      4. This saves time for problem reporters
-    </step_3_integration>
-
-    <step_4_integration>
-      During codebase exploration (CONTRIBUTORS ONLY):
-      1. Clone repo locally if needed: `gh repo clone $REPO_FULL_NAME`
-      2. Use `git log` to find recent changes to affected files
-      3. Use `gh search prs` for related pull requests
-      4. Include findings in the technical context section
-    </step_4_integration>
-
-    <step_5_integration>
-      When creating the issue:
-      1. Use repository template if found, or generic template if not
-      2. Fill template with gathered information
-      3. Format differently based on contributor vs problem reporter
-      4. Save formatted body to temporary file
-      5. Use `gh issue create` with appropriate labels from template
-      6. Capture the returned issue URL
-      7. Show user the created issue URL
-    </step_5_integration>
-  </workflow_integration>
-
-  <best_practices>
-    <practice name="file_handling">
-      When creating issues with long bodies:
-      1. Save to temporary file: `cat > /tmp/issue_body.md << 'EOF'`
-      2. Use --body-file flag with gh issue create
-      3. Clean up after: `rm /tmp/issue_body.md`
-    </practice>
-
-    <practice name="search_efficiency">
-      Use specific search terms:
-      - Include error messages in quotes
-      - Use label filters when appropriate
-      - Limit results to avoid overwhelming output
-    </practice>
-
-    <practice name="json_output">
-      Use --json flag for structured data when needed:
-      - Easier to parse programmatically
-      - Consistent format across commands
-      - Example: `gh issue list --json number,title,state`
-    </practice>
-  </best_practices>
-
-  <error_handling>
-    <duplicate_found>
-      If search finds exact duplicate:
-      - Show the existing issue to user using `gh issue view`
-      - Ask if they want to add a comment instead
-      - Use `gh issue comment` if they agree
-    </duplicate_found>
-
-    <creation_failed>
-      If `gh issue create` fails:
-      - Check error message (auth, permissions, network)
-      - Ensure gh is authenticated: `gh auth status`
-      - Save the drafted issue content for user
-      - Suggest using --web flag to create in browser
-    </creation_failed>
-
-    <authentication>
-      Ensure GitHub CLI is authenticated:
-      - Check status: `gh auth status`
-      - Login if needed: `gh auth login`
-      - Select appropriate scopes for issue creation
-    </authentication>
-  </error_handling>
-
-  <command_reference>
-    <issues>
-      gh issue create    - Create new issue
-      gh issue list      - List and search issues
-      gh issue view      - View issue details
-      gh issue comment   - Add comment to issue
-      gh issue edit      - Edit existing issue
-      gh issue close     - Close an issue
-      gh issue reopen    - Reopen closed issue
-    </issues>
-
-    <search>
-      gh search issues   - Search issues and PRs
-      gh search prs      - Search pull requests
-      gh search repos    - Search repositories
-    </search>
-
-    <repository>
-      gh repo view       - View repository info
-      gh repo clone      - Clone repository
-    </repository>
-  </command_reference>
-
-  <template_handling_reference>
-    <yaml_template_parsing>
-      When parsing YAML templates:
-      - Extract 'name' for template identification
-      - Get 'labels' array for automatic labeling
-      - Parse 'body' array for form elements
-      - Convert form elements to markdown sections
-      - Preserve 'required' field indicators
-    </yaml_template_parsing>
-    
-    <markdown_template_parsing>
-      When parsing Markdown templates:
-      - Check for YAML front matter
-      - Extract metadata (labels, assignees)
-      - Identify section headers
-      - Replace placeholder text
-      - Maintain formatting structure
-    </markdown_template_parsing>
-    
-    <template_usage_flow>
-      1. Detect templates with list_files
-      2. Read templates with read_file
-      3. Parse structure and metadata
-      4. Let user choose if multiple exist
-      5. Fill template with information
-      6. Create issue with template content
-    </template_usage_flow>
-  </template_handling_reference>
-</github_cli_usage>

.roo/rules-mode-writer/1_mode_creation_workflow.xml

@@ -1,301 +0,0 @@
-<mode_management_workflow>
-  <overview>
-    This workflow guides you through creating new custom modes or editing existing modes
-    for the Roo Code Software, ensuring comprehensive understanding and cohesive implementation.
-  </overview>
-
-  <initial_determination>
-    <step number="1">
-      <title>Determine User Intent</title>
-      <description>
-        Identify whether the user wants to create a new mode or edit an existing one
-      </description>
-      <detection_patterns>
-        <pattern type="edit_existing">
-          <indicators>
-            <indicator>User mentions a specific mode by name or slug</indicator>
-            <indicator>User references a mode directory path (e.g., .roo/rules-[mode-slug])</indicator>
-            <indicator>User asks to modify, update, enhance, or fix an existing mode</indicator>
-            <indicator>User says "edit this mode" or "change this mode"</indicator>
-          </indicators>
-        </pattern>
-        <pattern type="create_new">
-          <indicators>
-            <indicator>User asks to create a new mode</indicator>
-            <indicator>User describes a new capability not covered by existing modes</indicator>
-            <indicator>User says "make a mode for" or "create a mode that"</indicator>
-          </indicators>
-        </pattern>
-      </detection_patterns>
-      <clarification_question>
-        <ask_followup_question>
-          <question>I want to make sure I understand correctly. Are you looking to create a brand new mode or modify an existing one?</question>
-          <follow_up>
-            <suggest>Create a new mode for a specific purpose</suggest>
-            <suggest>Edit an existing mode to add new capabilities</suggest>
-            <suggest>Fix issues in an existing mode</suggest>
-            <suggest>Enhance an existing mode with better workflows</suggest>
-          </follow_up>
-        </ask_followup_question>
-      </clarification_question>
-    </step>
-  </initial_determination>
-
-  <workflow_branches>
-    <branch name="create_new_mode">
-      <step number="2a">
-        <title>Gather Requirements for New Mode</title>
-        <description>
-          Understand what the user wants the new mode to accomplish
-        </description>
-        <actions>
-          <action>Ask about the mode's primary purpose and use cases</action>
-          <action>Identify what types of tasks the mode should handle</action>
-          <action>Determine what tools and file access the mode needs</action>
-          <action>Clarify any special behaviors or restrictions</action>
-        </actions>
-        <example>
-          <ask_followup_question>
-            <question>What is the primary purpose of this new mode? What types of tasks should it handle?</question>
-            <follow_up>
-              <suggest>A mode for writing and maintaining documentation</suggest>
-              <suggest>A mode for database schema design and migrations</suggest>
-              <suggest>A mode for API endpoint development and testing</suggest>
-              <suggest>A mode for performance optimization and profiling</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </example>
-      </step>
-
-      <step number="3a">
-        <title>Design Mode Configuration</title>
-        <description>
-          Create the mode definition with all required fields
-        </description>
-        <required_fields>
-          <field name="slug">
-            <description>Unique identifier (lowercase, hyphens allowed)</description>
-            <best_practice>Keep it short and descriptive (e.g., "api-dev", "docs-writer")</best_practice>
-          </field>
-          <field name="name">
-            <description>Display name with optional emoji</description>
-            <best_practice>Use an emoji that represents the mode's purpose</best_practice>
-          </field>
-          <field name="roleDefinition">
-            <description>Detailed description of the mode's role and expertise</description>
-            <best_practice>
-              Start with "You are Roo Code, a [specialist type]..."
-              List specific areas of expertise
-              Mention key technologies or methodologies
-            </best_practice>
-          </field>
-          <field name="groups">
-            <description>Tool groups the mode can access</description>
-            <options>
-              <option name="read">File reading and searching tools</option>
-              <option name="edit">File editing tools (can be restricted by regex)</option>
-              <option name="command">Command execution tools</option>
-              <option name="browser">Browser interaction tools</option>
-              <option name="mcp">MCP server tools</option>
-            </options>
-          </field>
-        </required_fields>
-        <recommended_fields>
-          <field name="whenToUse">
-            <description>Clear description for the Orchestrator</description>
-            <best_practice>Explain specific scenarios and task types</best_practice>
-          </field>
-        </recommended_fields>
-        <important_note>
-          Do not include customInstructions in the .roomodes configuration.
-          All detailed instructions should be placed in XML files within
-          the .roo/rules-[mode-slug]/ directory instead.
-        </important_note>
-      </step>
-
-      <step number="4a">
-        <title>Implement File Restrictions</title>
-        <description>
-          Configure appropriate file access permissions
-        </description>
-        <example>
-          <comment>Restrict edit access to specific file types</comment>
-          <code>
-groups:
-  - read
-  - - edit
-    - fileRegex: \.(md|txt|rst)$
-      description: Documentation files only
-  - command
-          </code>
-        </example>
-        <guidelines>
-          <guideline>Use regex patterns to limit file editing scope</guideline>
-          <guideline>Provide clear descriptions for restrictions</guideline>
-          <guideline>Consider the principle of least privilege</guideline>
-        </guidelines>
-      </step>
-
-      <step number="5a">
-        <title>Create XML Instruction Files</title>
-        <description>
-          Design structured instruction files in .roo/rules-[mode-slug]/
-        </description>
-        <file_structure>
-          <file name="1_workflow.xml">Main workflow and step-by-step processes</file>
-          <file name="2_best_practices.xml">Guidelines and conventions</file>
-          <file name="3_common_patterns.xml">Reusable code patterns and examples</file>
-          <file name="4_tool_usage.xml">Specific tool usage instructions</file>
-          <file name="5_examples.xml">Complete workflow examples</file>
-        </file_structure>
-        <xml_best_practices>
-          <practice>Use semantic tag names that describe content</practice>
-          <practice>Nest tags hierarchically for better organization</practice>
-          <practice>Include code examples in CDATA sections when needed</practice>
-          <practice>Add comments to explain complex sections</practice>
-        </xml_best_practices>
-      </step>
-    </branch>
-
-    <branch name="edit_existing_mode">
-      <step number="2b">
-        <title>Immerse in Existing Mode</title>
-        <description>
-          Fully understand the existing mode before making any changes
-        </description>
-        <actions>
-          <action>Locate and read the mode configuration in .roomodes</action>
-          <action>Read all XML instruction files in .roo/rules-[mode-slug]/</action>
-          <action>Analyze the mode's current capabilities and limitations</action>
-          <action>Understand the mode's role in the broader ecosystem</action>
-        </actions>
-        <questions_to_ask>
-          <ask_followup_question>
-            <question>What specific aspects of the mode would you like to change or enhance?</question>
-            <follow_up>
-              <suggest>Add new capabilities or tool permissions</suggest>
-              <suggest>Fix issues with current workflows or instructions</suggest>
-              <suggest>Improve the mode's roleDefinition or whenToUse description</suggest>
-              <suggest>Enhance XML instructions for better clarity</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </questions_to_ask>
-      </step>
-
-      <step number="3b">
-        <title>Analyze Change Impact</title>
-        <description>
-          Understand how proposed changes will affect the mode
-        </description>
-        <analysis_areas>
-          <area>Compatibility with existing workflows</area>
-          <area>Impact on file permissions and tool access</area>
-          <area>Consistency with mode's core purpose</area>
-          <area>Integration with other modes</area>
-        </analysis_areas>
-        <validation_questions>
-          <ask_followup_question>
-            <question>I've analyzed the existing mode. Here's what I understand about your requested changes. Is this correct?</question>
-            <follow_up>
-              <suggest>Yes, that's exactly what I want to change</suggest>
-              <suggest>Mostly correct, but let me clarify some details</suggest>
-              <suggest>No, I meant something different</suggest>
-              <suggest>I'd like to add additional changes</suggest>
-            </follow_up>
-          </ask_followup_question>
-        </validation_questions>
-      </step>
-
-      <step number="4b">
-        <title>Plan Modifications</title>
-        <description>
-          Create a detailed plan for modifying the mode
-        </description>
-        <planning_steps>
-          <step>Identify which files need to be modified</step>
-          <step>Determine if new XML instruction files are needed</step>
-          <step>Check for potential conflicts or contradictions</step>
-          <step>Plan the order of changes for minimal disruption</step>
-        </planning_steps>
-      </step>
-
-      <step number="5b">
-        <title>Implement Changes</title>
-        <description>
-          Apply the planned modifications to the mode
-        </description>
-        <implementation_order>
-          <change>Update .roomodes configuration if needed</change>
-          <change>Modify existing XML instruction files</change>
-          <change>Create new XML instruction files if required</change>
-          <change>Update examples and documentation</change>
-        </implementation_order>
-      </step>
-    </branch>
-  </workflow_branches>
-
-  <validation_and_cohesion>
-    <step number="6">
-      <title>Validate Cohesion and Consistency</title>
-      <description>
-        Ensure all changes are cohesive and don't contradict each other
-      </description>
-      <validation_checks>
-        <check type="configuration">
-          <item>Mode slug follows naming conventions</item>
-          <item>File restrictions align with mode purpose</item>
-          <item>Tool permissions are appropriate</item>
-          <item>whenToUse clearly differentiates from other modes</item>
-        </check>
-        <check type="instructions">
-          <item>All XML files follow consistent structure</item>
-          <item>No contradicting instructions between files</item>
-          <item>Examples align with stated workflows</item>
-          <item>Tool usage matches granted permissions</item>
-        </check>
-        <check type="integration">
-          <item>Mode integrates well with Orchestrator</item>
-          <item>Clear boundaries with other modes</item>
-          <item>Handoff points are well-defined</item>
-        </check>
-      </validation_checks>
-      <cohesion_questions>
-        <ask_followup_question>
-          <question>I've completed the validation checks. Would you like me to review any specific aspect in more detail?</question>
-          <follow_up>
-            <suggest>Review the file permission patterns</suggest>
-            <suggest>Check for workflow contradictions</suggest>
-            <suggest>Verify integration with other modes</suggest>
-            <suggest>Everything looks good, proceed to testing</suggest>
-          </follow_up>
-        </ask_followup_question>
-      </cohesion_questions>
-    </step>
-
-    <step number="7">
-      <title>Test and Refine</title>
-      <description>
-        Verify the mode works as intended
-      </description>
-      <checklist>
-        <item>Mode appears in the mode list</item>
-        <item>File restrictions work correctly</item>
-        <item>Instructions are clear and actionable</item>
-        <item>Mode integrates well with Orchestrator</item>
-        <item>All examples are accurate and helpful</item>
-        <item>Changes don't break existing functionality (for edits)</item>
-        <item>New capabilities work as expected</item>
-      </checklist>
-    </step>
-  </validation_and_cohesion>
-
-  <quick_reference>
-    <command>Create mode in .roomodes for project-specific modes</command>
-    <command>Create mode in global custom_modes.yaml for system-wide modes</command>
-    <command>Use list_files to verify .roo folder structure</command>
-    <command>Test file regex patterns with search_files</command>
-    <command>Use codebase_search to find existing mode implementations</command>
-    <command>Read all XML files in a mode directory to understand its structure</command>
-    <command>Always validate changes for cohesion and consistency</command>
-  </quick_reference>
-</mode_management_workflow>

.roo/rules-mode-writer/2_xml_structuring_best_practices.xml

@@ -1,220 +0,0 @@
-<xml_structuring_best_practices>
-  <overview>
-    XML tags help Claude parse prompts more accurately, leading to higher-quality outputs.
-    This guide covers best practices for structuring mode instructions using XML.
-  </overview>
-
-  <why_use_xml_tags>
-    <benefit type="clarity">
-      Clearly separate different parts of your instructions and ensure well-structured content
-    </benefit>
-    <benefit type="accuracy">
-      Reduce errors caused by Claude misinterpreting parts of your instructions
-    </benefit>
-    <benefit type="flexibility">
-      Easily find, add, remove, or modify parts of instructions without rewriting everything
-    </benefit>
-    <benefit type="parseability">
-      Having Claude use XML tags in its output makes it easier to extract specific parts of responses
-    </benefit>
-  </why_use_xml_tags>
-
-  <core_principles>
-    <principle name="consistency">
-      <description>Use the same tag names throughout your instructions</description>
-      <example>
-        Always use <step> for workflow steps, not sometimes <action> or <task>
-      </example>
-    </principle>
-    
-    <principle name="semantic_naming">
-      <description>Tag names should clearly describe their content</description>
-      <good_examples>
-        <tag>detailed_steps</tag>
-        <tag>error_handling</tag>
-        <tag>validation_rules</tag>
-      </good_examples>
-      <bad_examples>
-        <tag>stuff</tag>
-        <tag>misc</tag>
-        <tag>data1</tag>
-      </bad_examples>
-    </principle>
-
-    <principle name="hierarchical_nesting">
-      <description>Nest tags to show relationships and structure</description>
-      <example>
-        <workflow>
-          <phase name="preparation">
-            <step>Gather requirements</step>
-            <step>Validate inputs</step>
-          </phase>
-          <phase name="execution">
-            <step>Process data</step>
-            <step>Generate output</step>
-          </phase>
-        </workflow>
-      </example>
-    </principle>
-  </core_principles>
-
-  <common_tag_patterns>
-    <pattern name="workflow_structure">
-      <usage>For step-by-step processes</usage>
-      <template><![CDATA[
-<workflow>
-  <overview>High-level description</overview>
-  <prerequisites>
-    <prerequisite>Required condition 1</prerequisite>
-    <prerequisite>Required condition 2</prerequisite>
-  </prerequisites>
-  <steps>
-    <step number="1">
-      <title>Step Title</title>
-      <description>What this step accomplishes</description>
-      <actions>
-        <action>Specific action to take</action>
-      </actions>
-      <validation>How to verify success</validation>
-    </step>
-  </steps>
-</workflow>
-      ]]></template>
-    </pattern>
-
-    <pattern name="examples_structure">
-      <usage>For providing code examples and demonstrations</usage>
-      <template><![CDATA[
-<examples>
-  <example name="descriptive_name">
-    <description>What this example demonstrates</description>
-    <context>When to use this approach</context>
-    <code language="typescript">
-      // Your code example here
-    </code>
-    <explanation>
-      Key points about the implementation
-    </explanation>
-  </example>
-</examples>
-      ]]></template>
-    </pattern>
-
-    <pattern name="guidelines_structure">
-      <usage>For rules and best practices</usage>
-      <template><![CDATA[
-<guidelines category="category_name">
-  <guideline priority="high">
-    <rule>The specific rule or guideline</rule>
-    <rationale>Why this is important</rationale>
-    <exceptions>When this doesn't apply</exceptions>
-  </guideline>
-</guidelines>
-      ]]></template>
-    </pattern>
-
-    <pattern name="tool_usage_structure">
-      <usage>For documenting how to use specific tools</usage>
-      <template><![CDATA[
-<tool_usage tool="tool_name">
-  <purpose>What this tool accomplishes</purpose>
-  <when_to_use>Specific scenarios for this tool</when_to_use>
-  <syntax>
-    <command>The exact command format</command>
-    <parameters>
-      <parameter name="param1" required="true">
-        <description>What this parameter does</description>
-        <type>string|number|boolean</type>
-        <example>example_value</example>
-      </parameter>
-    </parameters>
-  </syntax>
-  <examples>
-    <example scenario="common_use_case">
-      <code>Actual usage example</code>
-      <output>Expected output</output>
-    </example>
-  </examples>
-</tool_usage>
-      ]]></template>
-    </pattern>
-  </common_tag_patterns>
-
-  <formatting_guidelines>
-    <guideline name="indentation">
-      Use consistent indentation (2 or 4 spaces) for nested elements
-    </guideline>
-    <guideline name="line_breaks">
-      Add line breaks between major sections for readability
-    </guideline>
-    <guideline name="comments">
-      Use XML comments <!-- like this --> to explain complex sections
-    </guideline>
-    <guideline name="cdata_sections">
-      Use CDATA for code blocks or content with special characters:
-      <![CDATA[<code><![CDATA[your code here]]></code>]]>
-    </guideline>
-    <guideline name="attributes_vs_elements">
-      Use attributes for metadata, elements for content:
-      <example type="good">
-        <step number="1" priority="high">
-          <description>The actual step content</description>
-        </step>
-      </example>
-    </guideline>
-  </formatting_guidelines>
-
-  <anti_patterns>
-    <anti_pattern name="flat_structure">
-      <description>Avoid completely flat structures without hierarchy</description>
-      <bad><![CDATA[
-<instructions>
-<item1>Do this</item1>
-<item2>Then this</item2>
-<item3>Finally this</item3>
-</instructions>
-      ]]></bad>
-      <good><![CDATA[
-<instructions>
-  <steps>
-    <step order="1">Do this</step>
-    <step order="2">Then this</step>
-    <step order="3">Finally this</step>
-  </steps>
-</instructions>
-      ]]></good>
-    </anti_pattern>
-
-    <anti_pattern name="inconsistent_naming">
-      <description>Don't mix naming conventions</description>
-      <bad>
-        Mixing camelCase, snake_case, and kebab-case in tag names
-      </bad>
-      <good>
-        Pick one convention (preferably snake_case for XML) and stick to it
-      </good>
-    </anti_pattern>
-
-    <anti_pattern name="overly_generic_tags">
-      <description>Avoid tags that don't convey meaning</description>
-      <bad>data, info, stuff, thing, item</bad>
-      <good>user_input, validation_result, error_message, configuration</good>
-    </anti_pattern>
-  </anti_patterns>
-
-  <integration_tips>
-    <tip>
-      Reference XML content in instructions:
-      "Using the workflow defined in &lt;workflow&gt; tags..."
-    </tip>
-    <tip>
-      Combine XML structure with other techniques like multishot prompting
-    </tip>
-    <tip>
-      Use XML tags in expected outputs to make parsing easier
-    </tip>
-    <tip>
-      Create reusable XML templates for common patterns
-    </tip>
-  </integration_tips>
-</xml_structuring_best_practices>

.roo/rules-mode-writer/3_mode_configuration_patterns.xml

@@ -1,261 +0,0 @@
-<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 tool usage patterns</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- 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 ask_followup_question</characteristic>
-        <characteristic>Process validation at each step</characteristic>
-      </characteristics>
-      <example_template><![CDATA[
-- 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><![CDATA[
-- 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><![CDATA[
-- 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>
-
-  <permission_patterns>
-    <pattern name="documentation_only">
-      <description>For modes that only work with documentation</description>
-      <configuration><![CDATA[
-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><![CDATA[
-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><![CDATA[
-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><![CDATA[
-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 is 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>
-      </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>Use switch_mode when appropriate</item>
-        <item>Document mode interactions</item>
-      </checklist>
-    </guideline>
-  </integration_guidelines>
-</mode_configuration_patterns>

.roo/rules-mode-writer/4_instruction_file_templates.xml

@@ -1,367 +0,0 @@
-<instruction_file_templates>
-  <overview>
-    Templates and examples for creating XML instruction files that provide
-    detailed guidance for each mode's behavior and workflows.
-  </overview>
-
-  <file_organization>
-    <principle>Number files to indicate execution order</principle>
-    <principle>Use descriptive names that indicate content</principle>
-    <principle>Keep related instructions together</principle>
-    <standard_structure>
-      <file>1_workflow.xml - Main workflow and processes</file>
-      <file>2_best_practices.xml - Guidelines and conventions</file>
-      <file>3_common_patterns.xml - Reusable code patterns</file>
-      <file>4_tool_usage.xml - Specific tool instructions</file>
-      <file>5_examples.xml - Complete workflow examples</file>
-      <file>6_error_handling.xml - Error scenarios and recovery</file>
-      <file>7_communication.xml - User interaction guidelines</file>
-    </standard_structure>
-  </file_organization>
-
-  <workflow_file_template>
-    <description>Template for main workflow files (1_workflow.xml)</description>
-    <template><![CDATA[
-<workflow_instructions>
-  <mode_overview>
-    Brief description of what this mode does and its primary purpose
-  </mode_overview>
-
-  <initialization_steps>
-    <step number="1">
-      <action>Understand the user's request</action>
-      <details>
-        Parse the user's input to identify:
-        - Primary objective
-        - Specific requirements
-        - Constraints or limitations
-      </details>
-    </step>
-    
-    <step number="2">
-      <action>Gather necessary context</action>
-      <tools>
-        <tool>codebase_search - Find relevant existing code</tool>
-        <tool>list_files - Understand project structure</tool>
-        <tool>read_file - Examine specific implementations</tool>
-      </tools>
-    </step>
-  </initialization_steps>
-
-  <main_workflow>
-    <phase name="analysis">
-      <description>Analyze the current state and requirements</description>
-      <steps>
-        <step>Identify affected components</step>
-        <step>Assess impact of changes</step>
-        <step>Plan implementation approach</step>
-      </steps>
-    </phase>
-
-    <phase name="implementation">
-      <description>Execute the planned changes</description>
-      <steps>
-        <step>Create/modify necessary files</step>
-        <step>Ensure consistency across codebase</step>
-        <step>Add appropriate documentation</step>
-      </steps>
-    </phase>
-
-    <phase name="validation">
-      <description>Verify the implementation</description>
-      <steps>
-        <step>Check for errors or inconsistencies</step>
-        <step>Validate against requirements</step>
-        <step>Ensure no regressions</step>
-      </steps>
-    </phase>
-  </main_workflow>
-
-  <completion_criteria>
-    <criterion>All requirements have been addressed</criterion>
-    <criterion>Code follows project conventions</criterion>
-    <criterion>Changes are properly documented</criterion>
-    <criterion>No breaking changes introduced</criterion>
-  </completion_criteria>
-</workflow_instructions>
-    ]]></template>
-  </workflow_file_template>
-
-  <best_practices_template>
-    <description>Template for best practices files (2_best_practices.xml)</description>
-    <template><![CDATA[
-<best_practices>
-  <general_principles>
-    <principle priority="high">
-      <name>Principle Name</name>
-      <description>Detailed explanation of the principle</description>
-      <rationale>Why this principle is important</rationale>
-      <example>
-        <scenario>When this applies</scenario>
-        <good>Correct approach</good>
-        <bad>What to avoid</bad>
-      </example>
-    </principle>
-  </general_principles>
-
-  <code_conventions>
-    <convention category="naming">
-      <rule>Specific naming convention</rule>
-      <examples>
-        <good>goodExampleName</good>
-        <bad>bad_example-name</bad>
-      </examples>
-    </convention>
-    
-    <convention category="structure">
-      <rule>How to structure code/files</rule>
-      <template>
-        // Example structure
-      </template>
-    </convention>
-  </code_conventions>
-
-  <common_pitfalls>
-    <pitfall>
-      <description>Common mistake to avoid</description>
-      <why_problematic>Explanation of issues it causes</why_problematic>
-      <correct_approach>How to do it properly</correct_approach>
-    </pitfall>
-  </common_pitfalls>
-
-  <quality_checklist>
-    <category name="before_starting">
-      <item>Understand requirements fully</item>
-      <item>Check existing implementations</item>
-    </category>
-    <category name="during_implementation">
-      <item>Follow established patterns</item>
-      <item>Write clear documentation</item>
-    </category>
-    <category name="before_completion">
-      <item>Review all changes</item>
-      <item>Verify requirements met</item>
-    </category>
-  </quality_checklist>
-</best_practices>
-    ]]></template>
-  </best_practices_template>
-
-  <tool_usage_template>
-    <description>Template for tool usage files (4_tool_usage.xml)</description>
-    <template><![CDATA[
-<tool_usage_guide>
-  <tool_priorities>
-    <priority level="1">
-      <tool>codebase_search</tool>
-      <when>Always use first to find relevant code</when>
-      <why>Semantic search finds functionality better than keywords</why>
-    </priority>
-    <priority level="2">
-      <tool>read_file</tool>
-      <when>After identifying files with codebase_search</when>
-      <why>Get full context of implementations</why>
-    </priority>
-  </tool_priorities>
-
-  <tool_specific_guidance>
-    <tool name="apply_diff">
-      <best_practices>
-        <practice>Always read file first to ensure exact content match</practice>
-        <practice>Make multiple changes in one diff when possible</practice>
-        <practice>Include line numbers for accuracy</practice>
-      </best_practices>
-      <example><![CDATA[
-<apply_diff>
-<path>src/config.ts</path>
-<diff>
-<<<<<<< SEARCH
-:start_line:10
--------
-export const config = {
-  apiUrl: 'http://localhost:3000',
-  timeout: 5000
-};
-=======
-export const config = {
-  apiUrl: process.env.API_URL || 'http://localhost:3000',
-  timeout: parseInt(process.env.TIMEOUT || '5000'),
-  retries: 3
-};
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-      ]]></example>
-    </tool>
-
-    <tool name="ask_followup_question">
-      <best_practices>
-        <practice>Provide 2-4 specific, actionable suggestions</practice>
-        <practice>Order suggestions by likelihood or importance</practice>
-        <practice>Make suggestions complete (no placeholders)</practice>
-      </best_practices>
-      <example><![CDATA[
-<ask_followup_question>
-<question>Which database system should I configure for this project?</question>
-<follow_up>
-<suggest>PostgreSQL with the default configuration</suggest>
-<suggest>MySQL 8.0 with InnoDB storage engine</suggest>
-<suggest>SQLite for local development only</suggest>
-<suggest>MongoDB for document-based storage</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></example>
-    </tool>
-  </tool_specific_guidance>
-
-  <tool_combination_patterns>
-    <pattern name="explore_then_modify">
-      <sequence>
-        <step>codebase_search - Find relevant files</step>
-        <step>list_code_definition_names - Understand structure</step>
-        <step>read_file - Get full context</step>
-        <step>apply_diff or write_to_file - Make changes</step>
-      </sequence>
-    </pattern>
-    
-    <pattern name="verify_then_proceed">
-      <sequence>
-        <step>list_files - Check file exists</step>
-        <step>read_file - Verify current content</step>
-        <step>ask_followup_question - Confirm approach</step>
-        <step>apply_diff - Implement changes</step>
-      </sequence>
-    </pattern>
-  </tool_combination_patterns>
-</tool_usage_guide>
-    ]]></template>
-  </tool_usage_template>
-
-  <examples_file_template>
-    <description>Template for example files (5_examples.xml)</description>
-    <template><![CDATA[
-<complete_examples>
-  <example name="descriptive_example_name">
-    <scenario>
-      Detailed description of the use case this example covers
-    </scenario>
-    
-    <user_request>
-      The initial request from the user
-    </user_request>
-
-    <workflow>
-      <step number="1">
-        <description>First step description</description>
-        <tool_use><![CDATA[
-<codebase_search>
-<query>search query here</query>
-</codebase_search>
-        ]]></tool_use>
-        <expected_outcome>What we learn from this step</expected_outcome>
-      </step>
-
-      <step number="2">
-        <description>Second step description</description>
-        <tool_use><![CDATA[
-<read_file>
-<path>path/to/file.ts</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>How we interpret the results</analysis>
-      </step>
-
-      <step number="3">
-        <description>Implementation step</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>path/to/file.ts</path>
-<diff>
-<<<<<<< SEARCH
-:start_line:1
--------
-original content
-=======
-new content
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <completion><![CDATA[
-<attempt_completion>
-<result>
-Summary of what was accomplished and how it addresses the user's request
-</result>
-</attempt_completion>
-    ]]></completion>
-
-    <key_takeaways>
-      <takeaway>Important lesson from this example</takeaway>
-      <takeaway>Pattern that can be reused</takeaway>
-    </key_takeaways>
-  </example>
-</complete_examples>
-    ]]></template>
-  </examples_file_template>
-
-  <communication_template>
-    <description>Template for communication guidelines (7_communication.xml)</description>
-    <template><![CDATA[
-<communication_guidelines>
-  <tone_and_style>
-    <principle>Be direct and technical, not conversational</principle>
-    <principle>Focus on actions taken and results achieved</principle>
-    <avoid>
-      <phrase>Great! I'll help you with that...</phrase>
-      <phrase>Certainly! Let me...</phrase>
-      <phrase>Sure thing!</phrase>
-    </avoid>
-    <prefer>
-      <phrase>I'll analyze the codebase to...</phrase>
-      <phrase>Implementing the requested changes...</phrase>
-      <phrase>The analysis shows...</phrase>
-    </prefer>
-  </tone_and_style>
-
-  <user_interaction>
-    <when_to_ask_questions>
-      <scenario>Missing critical information</scenario>
-      <scenario>Multiple valid approaches exist</scenario>
-      <scenario>Potential breaking changes</scenario>
-    </when_to_ask_questions>
-    
-    <question_format>
-      <guideline>Be specific about what you need</guideline>
-      <guideline>Provide actionable options</guideline>
-      <guideline>Explain implications of choices</guideline>
-    </question_format>
-  </user_interaction>
-
-  <progress_updates>
-    <when>During long-running operations</when>
-    <format>
-      <update>Analyzing [X] files for [purpose]...</update>
-      <update>Implementing [feature] in [location]...</update>
-      <update>Validating changes against [criteria]...</update>
-    </format>
-  </progress_updates>
-
-  <completion_messages>
-    <structure>
-      <element>What was accomplished</element>
-      <element>Key changes made</element>
-      <element>Any important notes or warnings</element>
-    </structure>
-    <avoid>
-      <element>Questions at the end</element>
-      <element>Offers for further assistance</element>
-      <element>Conversational closings</element>
-    </avoid>
-  </completion_messages>
-</communication_guidelines>
-    ]]></template>
-  </communication_template>
-</instruction_file_templates>

.roo/rules-mode-writer/5_complete_mode_examples.xml

@@ -1,214 +0,0 @@
-<complete_examples>
-  <example name="mode_editing_enhancement">
-    <scenario>
-      Edit the test mode to add support for performance testing and benchmarking
-    </scenario>
-    
-    <user_request>
-      I want to edit the test mode to add benchmark testing capabilities
-    </user_request>
-
-    <workflow>
-      <step number="1">
-        <description>Determine user intent and clarify scope</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I understand you want to edit the test mode to add performance testing capabilities. Before we proceed, let me confirm the scope of changes. What specific performance testing features do you need?</question>
-<follow_up>
-<suggest>Add benchmark testing with Vitest's bench API</suggest>
-<suggest>Include performance profiling and memory usage tracking</suggest>
-<suggest>Add load testing capabilities for API endpoints</suggest>
-<suggest>All of the above - comprehensive performance testing suite</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-        <expected_outcome>User selected: Add benchmark testing with Vitest's bench API</expected_outcome>
-      </step>
-
-      <step number="2">
-        <description>Immerse in existing test mode configuration</description>
-        <tool_use><![CDATA[
-<read_file>
-<path>.roomodes</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>Found test mode configuration with current roleDefinition and file restrictions</analysis>
-      </step>
-
-      <step number="3">
-        <description>Explore existing test mode instructions</description>
-        <tool_use><![CDATA[
-<list_files>
-<path>.roo/rules-test</path>
-<recursive>true</recursive>
-</list_files>
-        ]]></tool_use>
-        <tool_use><![CDATA[
-<read_file>
-<path>.roo/rules-test/1_workflow.xml</path>
-</read_file>
-        ]]></tool_use>
-        <analysis>Understood current test workflows and patterns</analysis>
-      </step>
-
-      <step number="4">
-        <description>Validate changes for cohesion</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I've analyzed the test mode. Adding benchmark testing would require:
-1. Updating the roleDefinition to include performance testing expertise
-2. Modifying file restrictions to include .bench.ts files
-3. Adding new workflow instructions for benchmark creation
-4. Including Vitest bench API examples
-
-This aligns well with the existing testing focus. Should I proceed with all these changes?</question>
-<follow_up>
-<suggest>Yes, implement all the changes as described</suggest>
-<suggest>Start with just the roleDefinition and file restrictions</suggest>
-<suggest>Focus only on the workflow instructions first</suggest>
-<suggest>Let me review the specific changes before proceeding</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-        <expected_outcome>User selected: Yes, implement all the changes as described</expected_outcome>
-      </step>
-
-      <step number="5">
-        <description>Update mode configuration in .roomodes</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>.roomodes</path>
-<diff>
-<<<<<<< SEARCH
-    roleDefinition: |-
-      You are Roo, a Vitest testing specialist with deep expertise in: - Writing and maintaining Vitest test suites - Test-driven development (TDD) practices - Mocking and stubbing with Vitest - Integration testing strategies - TypeScript testing patterns - Code coverage analysis - Test performance optimization
-=======
-    roleDefinition: |-
-      You are Roo, a Vitest testing specialist with deep expertise in: - Writing and maintaining Vitest test suites - Test-driven development (TDD) practices - Mocking and stubbing with Vitest - Integration testing strategies - TypeScript testing patterns - Code coverage analysis - Test performance optimization - Benchmark testing with Vitest bench API - Performance profiling and optimization - Memory usage analysis in tests
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-
-      <step number="6">
-        <description>Update file restrictions to include benchmark files</description>
-        <tool_use><![CDATA[
-<apply_diff>
-<path>.roomodes</path>
-<diff>
-<<<<<<< SEARCH
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
-          description: Test files, mocks, and Vitest configuration
-=======
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|\.bench\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
-          description: Test files, benchmarks, mocks, and Vitest configuration
->>>>>>> REPLACE
-</diff>
-</apply_diff>
-        ]]></tool_use>
-      </step>
-
-      <step number="7">
-        <description>Create new benchmark workflow instructions</description>
-        <tool_use><![CDATA[
-<write_to_file>
-<path>.roo/rules-test/5_benchmark_testing.xml</path>
-<content>
-<benchmark_testing_guide>
-  <overview>
-    Guidelines for creating and maintaining performance benchmarks using Vitest bench API
-  </overview>
-
-  <benchmark_patterns>
-    <pattern name="basic_benchmark">
-      <description>Basic benchmark structure</description>
-      <example><![CDATA[
-import { bench, describe } from 'vitest';
-
-describe('Array operations', () => {
-  bench('Array.push', () => {
-    const arr = [];
-    for (let i = 0; i < 1000; i++) {
-      arr.push(i);
-    }
-  });
-
-  bench('Array spread', () => {
-    let arr = [];
-    for (let i = 0; i < 1000; i++) {
-      arr = [...arr, i];
-    }
-  });
-});
-      ]]></example>
-    </pattern>
-  </benchmark_patterns>
-
-  <best_practices>
-    <practice>Use meaningful benchmark names that describe what's being measured</practice>
-    <practice>Include baseline comparisons when optimizing code</practice>
-    <practice>Run benchmarks in isolation to avoid interference</practice>
-    <practice>Document performance expectations and thresholds</practice>
-  </best_practices>
-</benchmark_testing_guide>
-</content>
-<line_count>38</line_count>
-</write_to_file>
-        ]]></tool_use>
-      </step>
-
-      <step number="8">
-        <description>Validate all changes for consistency</description>
-        <tool_use><![CDATA[
-<ask_followup_question>
-<question>I've completed all the changes to add benchmark testing capabilities to the test mode:
-
-1. ✓ Updated roleDefinition to include benchmark expertise
-2. ✓ Modified file restrictions to include .bench.ts files
-3. ✓ Created new benchmark workflow instructions
-4. ✓ Added Vitest bench API examples
-
-All changes are cohesive and align with the existing test mode structure. Would you like me to test any specific aspect of these changes?</question>
-<follow_up>
-<suggest>Test creating a new benchmark file to verify file permissions</suggest>
-<suggest>Review the complete changes one more time</suggest>
-<suggest>Everything looks good, the mode is ready</suggest>
-<suggest>Create a simple benchmark example to test</suggest>
-</follow_up>
-</ask_followup_question>
-        ]]></tool_use>
-      </step>
-    </workflow>
-
-    <completion><![CDATA[
-<attempt_completion>
-<result>
-I've successfully enhanced the test mode with benchmark testing capabilities:
-
-1. Updated the roleDefinition to include:
-   - Benchmark testing with Vitest bench API
-   - Performance profiling and optimization
-   - Memory usage analysis in tests
-
-2. Modified file restrictions to include .bench.ts files, allowing the mode to create and edit benchmark files
-
-3. Created new workflow instructions at .roo/rules-test/5_benchmark_testing.xml with:
-   - Basic benchmark patterns
-   - Best practices for performance testing
-   - Example code using Vitest's bench API
-
-All changes have been validated for cohesion and consistency with the existing test mode structure. The mode now supports comprehensive performance testing alongside its existing unit and integration testing capabilities.
-</result>
-</attempt_completion>
-    ]]></completion>
-
-    <key_takeaways>
-      <takeaway>Always immerse yourself in the existing mode before making changes</takeaway>
-      <takeaway>Use ask_followup_question aggressively to clarify scope and validate changes</takeaway>
-      <takeaway>Validate all changes for cohesion and consistency</takeaway>
-      <takeaway>Update all relevant parts: configuration, file restrictions, and instructions</takeaway>
-      <takeaway>Test changes to ensure they work as expected</takeaway>
-    </key_takeaways>
-  </example>
-</complete_examples>

.roo/rules-mode-writer/6_mode_testing_validation.xml

@@ -1,207 +0,0 @@
-<mode_testing_validation>
-  <overview>
-    Guidelines for testing and validating newly created modes to ensure they function correctly and integrate well with the Roo Code ecosystem.
-  </overview>
-
-  <validation_checklist>
-    <category name="configuration_validation">
-      <item priority="critical">
-        <check>Mode slug is unique and follows naming conventions</check>
-        <validation>No spaces, lowercase, hyphens only</validation>
-      </item>
-      <item priority="critical">
-        <check>All required fields are present and non-empty</check>
-        <fields>slug, name, roleDefinition, groups</fields>
-      </item>
-      <item priority="critical">
-        <check>No customInstructions field in .roomodes</check>
-        <validation>All instructions must be in XML files in .roo/rules-[slug]/</validation>
-      </item>
-      <item priority="high">
-        <check>File restrictions use valid regex patterns</check>
-        <test_method><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_regex_here</regex>
-</search_files>
-        ]]></test_method>
-      </item>
-      <item priority="high">
-        <check>whenToUse clearly differentiates from other modes</check>
-        <validation>Compare with existing mode descriptions</validation>
-      </item>
-    </category>
-
-    <category name="instruction_validation">
-      <item>
-        <check>XML files are well-formed and valid</check>
-        <validation>No syntax errors, proper closing tags</validation>
-      </item>
-      <item>
-        <check>Instructions follow XML best practices</check>
-        <validation>Semantic tag names, proper nesting</validation>
-      </item>
-      <item>
-        <check>Examples use correct tool syntax</check>
-        <validation>Tool parameters match current API</validation>
-      </item>
-      <item>
-        <check>File paths in examples are consistent</check>
-        <validation>Use project-relative paths</validation>
-      </item>
-    </category>
-
-    <category name="functional_testing">
-      <item>
-        <check>Mode appears in mode list</check>
-        <test>Switch to the new mode and verify it loads</test>
-      </item>
-      <item>
-        <check>Tool permissions work as expected</check>
-        <test>Try using each tool group and verify access</test>
-      </item>
-      <item>
-        <check>File restrictions are enforced</check>
-        <test>Attempt to edit allowed and restricted files</test>
-      </item>
-      <item>
-        <check>Mode handles edge cases gracefully</check>
-        <test>Test with minimal input, errors, edge cases</test>
-      </item>
-    </category>
-  </validation_checklist>
-
-  <testing_workflow>
-    <step number="1">
-      <title>Configuration Testing</title>
-      <actions>
-        <action>Verify mode appears in available modes list</action>
-        <action>Check that mode metadata displays correctly</action>
-        <action>Confirm mode can be activated</action>
-      </actions>
-      <verification><![CDATA[
-<ask_followup_question>
-<question>I've created the mode configuration. Can you see the new mode in your mode list?</question>
-<follow_up>
-<suggest>Yes, I can see the new mode and switch to it</suggest>
-<suggest>No, the mode doesn't appear in the list</suggest>
-<suggest>The mode appears but has errors when switching</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></verification>
-    </step>
-
-    <step number="2">
-      <title>Permission Testing</title>
-      <test_cases>
-        <test case="read_permissions">
-          <action>Use read tools on various files</action>
-          <expected>All read operations should work</expected>
-        </test>
-        <test case="edit_restrictions">
-          <action>Try editing allowed file types</action>
-          <expected>Edits succeed for matching patterns</expected>
-        </test>
-        <test case="edit_restrictions_negative">
-          <action>Try editing restricted file types</action>
-          <expected>FileRestrictionError for non-matching files</expected>
-        </test>
-      </test_cases>
-    </step>
-
-    <step number="3">
-      <title>Workflow Testing</title>
-      <actions>
-        <action>Execute main workflow from start to finish</action>
-        <action>Test each decision point</action>
-        <action>Verify error handling</action>
-        <action>Check completion criteria</action>
-      </actions>
-    </step>
-
-    <step number="4">
-      <title>Integration Testing</title>
-      <areas>
-        <area>Orchestrator mode compatibility</area>
-        <area>Mode switching functionality</area>
-        <area>Tool handoff between modes</area>
-        <area>Consistent behavior with other modes</area>
-      </areas>
-    </step>
-  </testing_workflow>
-
-  <common_issues>
-    <issue type="configuration">
-      <problem>Mode doesn't appear in list</problem>
-      <causes>
-        <cause>Syntax error in YAML</cause>
-        <cause>Invalid mode slug</cause>
-        <cause>File not saved</cause>
-      </causes>
-      <solution>Check YAML syntax, validate slug format</solution>
-    </issue>
-
-    <issue type="permissions">
-      <problem>File restriction not working</problem>
-      <causes>
-        <cause>Invalid regex pattern</cause>
-        <cause>Escaping issues in regex</cause>
-        <cause>Wrong file path format</cause>
-      </causes>
-      <solution>Test regex pattern, use proper escaping</solution>
-      <example><![CDATA[
-# Wrong: *.ts (glob pattern)
-# Right: .*\.ts$ (regex pattern)
-      ]]></example>
-    </issue>
-
-    <issue type="behavior">
-      <problem>Mode not following instructions</problem>
-      <causes>
-        <cause>Instructions not in .roo/rules-[slug]/ folder</cause>
-        <cause>XML parsing errors</cause>
-        <cause>Conflicting instructions</cause>
-      </causes>
-      <solution>Verify file locations and XML validity</solution>
-    </issue>
-  </common_issues>
-
-  <debugging_tools>
-    <tool name="list_files">
-      <usage>Verify instruction files exist in correct location</usage>
-      <command><![CDATA[
-<list_files>
-<path>.roo</path>
-<recursive>true</recursive>
-</list_files>
-      ]]></command>
-    </tool>
-
-    <tool name="read_file">
-      <usage>Check mode configuration syntax</usage>
-      <command><![CDATA[
-<read_file>
-<path>.roomodes</path>
-</read_file>
-      ]]></command>
-    </tool>
-
-    <tool name="search_files">
-      <usage>Test file restriction patterns</usage>
-      <command><![CDATA[
-<search_files>
-<path>.</path>
-<regex>your_file_pattern_here</regex>
-</search_files>
-      ]]></command>
-    </tool>
-  </debugging_tools>
-
-  <best_practices>
-    <practice>Test incrementally as you build the mode</practice>
-    <practice>Start with minimal configuration and add complexity</practice>
-    <practice>Document any special requirements or dependencies</practice>
-    <practice>Consider edge cases and error scenarios</practice>
-    <practice>Get feedback from potential users of the mode</practice>
-  </best_practices>
-</mode_testing_validation>

.roo/rules-mode-writer/7_validation_cohesion_checking.xml

@@ -1,201 +0,0 @@
-<validation_cohesion_checking>
-  <overview>
-    Guidelines for thoroughly validating mode changes to ensure cohesion,
-    consistency, and prevent contradictions across all mode components.
-  </overview>
-
-  <validation_principles>
-    <principle name="comprehensive_review">
-      <description>
-        Every change must be reviewed in context of the entire mode
-      </description>
-      <checklist>
-        <item>Read all existing XML instruction files</item>
-        <item>Verify new changes align with existing patterns</item>
-        <item>Check for duplicate or conflicting instructions</item>
-        <item>Ensure terminology is consistent throughout</item>
-      </checklist>
-    </principle>
-
-    <principle name="aggressive_questioning">
-      <description>
-        Use ask_followup_question extensively to clarify ambiguities
-      </description>
-      <when_to_ask>
-        <scenario>User's intent is unclear</scenario>
-        <scenario>Multiple interpretations are possible</scenario>
-        <scenario>Changes might conflict with existing functionality</scenario>
-        <scenario>Impact on other modes needs clarification</scenario>
-      </when_to_ask>
-      <example><![CDATA[
-<ask_followup_question>
-<question>I notice this change might affect how the mode interacts with file permissions. Should we also update the file regex patterns to match?</question>
-<follow_up>
-<suggest>Yes, update the file regex to include the new file types</suggest>
-<suggest>No, keep the current file restrictions as they are</suggest>
-<suggest>Let me explain what file types I need to work with</suggest>
-<suggest>Show me the current file restrictions first</suggest>
-</follow_up>
-</ask_followup_question>
-      ]]></example>
-    </principle>
-
-    <principle name="contradiction_detection">
-      <description>
-        Actively search for and resolve contradictions
-      </description>
-      <common_contradictions>
-        <contradiction>
-          <type>Permission Mismatch</type>
-          <description>Instructions reference tools the mode doesn't have access to</description>
-          <resolution>Either grant the tool permission or update the instructions</resolution>
-        </contradiction>
-        <contradiction>
-          <type>Workflow Conflicts</type>
-          <description>Different XML files describe conflicting workflows</description>
-          <resolution>Consolidate workflows and ensure single source of truth</resolution>
-        </contradiction>
-        <contradiction>
-          <type>Role Confusion</type>
-          <description>Mode's roleDefinition doesn't match its actual capabilities</description>
-          <resolution>Update roleDefinition to accurately reflect the mode's purpose</resolution>
-        </contradiction>
-      </common_contradictions>
-    </principle>
-  </validation_principles>
-
-  <validation_workflow>
-    <phase name="pre_change_analysis">
-      <description>Before making any changes</description>
-      <steps>
-        <step>Read and understand all existing mode files</step>
-        <step>Create a mental model of current mode behavior</step>
-        <step>Identify potential impact areas</step>
-        <step>Ask clarifying questions about intended changes</step>
-      </steps>
-    </phase>
-
-    <phase name="change_implementation">
-      <description>While making changes</description>
-      <steps>
-        <step>Document each change and its rationale</step>
-        <step>Cross-reference with other files after each change</step>
-        <step>Verify examples still work with new changes</step>
-        <step>Update related documentation immediately</step>
-      </steps>
-    </phase>
-
-    <phase name="post_change_validation">
-      <description>After changes are complete</description>
-      <validation_checklist>
-        <category name="structural_validation">
-          <check>All XML files are well-formed and valid</check>
-          <check>File naming follows established patterns</check>
-          <check>Tag names are consistent across files</check>
-          <check>No orphaned or unused instructions</check>
-        </category>
-
-        <category name="content_validation">
-          <check>roleDefinition accurately describes the mode</check>
-          <check>whenToUse is clear and distinguishable</check>
-          <check>Tool permissions match instruction requirements</check>
-          <check>File restrictions align with mode purpose</check>
-          <check>Examples are accurate and functional</check>
-        </category>
-
-        <category name="integration_validation">
-          <check>Mode boundaries are well-defined</check>
-          <check>Handoff points to other modes are clear</check>
-          <check>No overlap with other modes' responsibilities</check>
-          <check>Orchestrator can correctly route to this mode</check>
-        </category>
-      </validation_checklist>
-    </phase>
-  </validation_workflow>
-
-  <cohesion_patterns>
-    <pattern name="consistent_voice">
-      <description>Maintain consistent tone and terminology</description>
-      <guidelines>
-        <guideline>Use the same terms for the same concepts throughout</guideline>
-        <guideline>Keep instruction style consistent across files</guideline>
-        <guideline>Maintain the same level of detail in similar sections</guideline>
-      </guidelines>
-    </pattern>
-
-    <pattern name="logical_flow">
-      <description>Ensure instructions flow logically</description>
-      <guidelines>
-        <guideline>Prerequisites come before dependent steps</guideline>
-        <guideline>Complex concepts build on simpler ones</guideline>
-        <guideline>Examples follow the explained patterns</guideline>
-      </guidelines>
-    </pattern>
-
-    <pattern name="complete_coverage">
-      <description>Ensure all aspects are covered without gaps</description>
-      <guidelines>
-        <guideline>Every mentioned tool has usage instructions</guideline>
-        <guideline>All workflows have complete examples</guideline>
-        <guideline>Error scenarios are addressed</guideline>
-      </guidelines>
-    </pattern>
-  </cohesion_patterns>
-
-  <validation_questions>
-    <question_set name="before_changes">
-      <ask_followup_question>
-        <question>Before we proceed with changes, I want to ensure I understand the full scope. What is the main goal of these modifications?</question>
-        <follow_up>
-          <suggest>Add new functionality while keeping existing features</suggest>
-          <suggest>Fix issues with current implementation</suggest>
-          <suggest>Refactor for better organization</suggest>
-          <suggest>Expand the mode's capabilities into new areas</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-
-    <question_set name="during_changes">
-      <ask_followup_question>
-        <question>This change might affect other parts of the mode. How should we handle the impact on [specific area]?</question>
-        <follow_up>
-          <suggest>Update all affected areas to maintain consistency</suggest>
-          <suggest>Keep the existing behavior for backward compatibility</suggest>
-          <suggest>Create a migration path from old to new behavior</suggest>
-          <suggest>Let me review the impact first</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-
-    <question_set name="after_changes">
-      <ask_followup_question>
-        <question>I've completed the changes and validation. Which aspect would you like me to test more thoroughly?</question>
-        <follow_up>
-          <suggest>Test the new workflow end-to-end</suggest>
-          <suggest>Verify file permissions work correctly</suggest>
-          <suggest>Check integration with other modes</suggest>
-          <suggest>Review all changes one more time</suggest>
-        </follow_up>
-      </ask_followup_question>
-    </question_set>
-  </validation_questions>
-
-  <red_flags>
-    <flag priority="high">
-      <description>Instructions reference tools not in the mode's groups</description>
-      <action>Either add the tool group or remove the instruction</action>
-    </flag>
-    <flag priority="high">
-      <description>File regex doesn't match described file types</description>
-      <action>Update regex pattern to match intended files</action>
-    </flag>
-    <flag priority="medium">
-      <description>Examples don't follow stated best practices</description>
-      <action>Update examples to demonstrate best practices</action>
-    </flag>
-    <flag priority="medium">
-      <description>Duplicate instructions in different files</description>
-      <action>Consolidate to single location and reference</action>
-    </flag>
-  </red_flags>
-</validation_cohesion_checking>

.roomodes

@@ -1,46 +1,4 @@
 customModes:
-  - slug: test
-    name: 🧪 Test
-    roleDefinition: |-
-      You are Roo, a Vitest testing specialist with deep expertise in: - Writing and maintaining Vitest test suites - Test-driven development (TDD) practices - Mocking and stubbing with Vitest - Integration testing strategies - TypeScript testing patterns - Code coverage analysis - Test performance optimization
-      Your focus is on maintaining high test quality and coverage across the codebase, working primarily with: - Test files in __tests__ directories - Mock implementations in __mocks__ - Test utilities and helpers - Vitest configuration and setup
-      You ensure tests are: - Well-structured and maintainable - Following Vitest best practices - Properly typed with TypeScript - Providing meaningful coverage - Using appropriate mocking strategies
-    whenToUse: Use this mode when you need to write, modify, or maintain tests for the codebase.
-    description: Write, modify, and maintain tests.
-    groups:
-      - read
-      - browser
-      - command
-      - - edit
-        - fileRegex: (__tests__/.*|__mocks__/.*|\.test\.(ts|tsx|js|jsx)$|\.spec\.(ts|tsx|js|jsx)$|/test/.*|vitest\.config\.(js|ts)$|vitest\.setup\.(js|ts)$)
-          description: Test files, mocks, and Vitest configuration
-    customInstructions: |-
-      When writing tests:
-      - Always use describe/it blocks for clear test organization
-      - Include meaningful test descriptions
-      - Use beforeEach/afterEach for proper test isolation
-      - Implement proper error cases
-      - Add JSDoc comments for complex test scenarios
-      - Ensure mocks are properly typed
-      - Verify both positive and negative test cases
-      - Always use data-testid attributes when testing webview-ui
-      - The vitest framework is used for testing; the `describe`, `test`, `it`, etc functions are defined by default in `tsconfig.json` and therefore don't need to be imported
-      - Tests must be run from the same directory as the `package.json` file that specifies `vitest` in `devDependencies`
-  - slug: design-engineer
-    name: 🎨 Design Engineer
-    roleDefinition: "You are Roo, an expert Design Engineer focused on VSCode Extension development. Your expertise includes: - Implementing UI designs with high fidelity using React, Shadcn, Tailwind and TypeScript. - Ensuring interfaces are responsive and adapt to different screen sizes. - Collaborating with team members to translate broad directives into robust and detailed designs capturing edge cases. - Maintaining uniformity and consistency across the user interface."
-    whenToUse: Implement UI designs and ensure consistency.
-    description: Implement UI designs; ensure consistency.
-    groups:
-      - read
-      - - edit
-        - fileRegex: \.(css|html|json|mdx?|jsx?|tsx?|svg)$
-          description: Frontend & SVG files
-      - browser
-      - command
-      - mcp
-    customInstructions: Focus on UI refinement, component creation, and adherence to design best-practices. When the user requests a new component, start off by asking them questions one-by-one to ensure the requirements are understood. Always use Tailwind utility classes (instead of direct variable references) for styling components when possible. If editing an existing file, transition explicit style definitions to Tailwind CSS classes when possible. Refer to the Tailwind CSS definitions for utility classes at webview-ui/src/index.css. Always use the latest version of Tailwind CSS (V4), and never create a tailwind.config.js file. Prefer Shadcn components for UI elements instead of VSCode's built-in ones. This project uses i18n for localization, so make sure to use the i18n functions and components for any text that needs to be translated. Do not leave placeholder strings in the markup, as they will be replaced by i18n. Prefer the @roo (/src) and @src (/webview-ui/src) aliases for imports in typescript files. Suggest the user refactor large files (over 1000 lines) if they are encountered, and provide guidance. Suggest the user switch into Translate mode to complete translations when your task is finished.
-    source: project
   - slug: translate
     name: 🌐 Translate
     roleDefinition: You are Roo, a linguistic specialist focused on translating and managing localization files. Your responsibility is to help maintain and update translation files for the application, ensuring consistency and accuracy across all language resources.
@@ -73,21 +31,6 @@ customModes:
       - edit
       - command
     source: project
-  - slug: integration-tester
-    name: 🧪 Integration Tester
-    roleDefinition: |-
-      You are Roo, an integration testing specialist focused on VSCode E2E tests with expertise in: - Writing and maintaining integration tests using Mocha and VSCode Test framework - Testing Roo Code API interactions and event-driven workflows - Creating complex multi-step task scenarios and mode switching sequences - Validating message formats, API responses, and event emission patterns - Test data generation and fixture management - Coverage analysis and test scenario identification
-      Your focus is on ensuring comprehensive integration test coverage for the Roo Code extension, working primarily with: - E2E test files in apps/vscode-e2e/src/suite/ - Test utilities and helpers - API type definitions in packages/types/ - Extension API testing patterns
-      You ensure integration tests are: - Comprehensive and cover critical user workflows - Following established Mocha TDD patterns - Using async/await with proper timeout handling - Validating both success and failure scenarios - Properly typed with TypeScript
-    whenToUse: Write, modify, or maintain integration tests.
-    description: Write and maintain integration tests.
-    groups:
-      - read
-      - command
-      - - edit
-        - fileRegex: (apps/vscode-e2e/.*\.(ts|js)$|packages/types/.*\.ts$)
-          description: E2E test files, test utilities, and API type definitions
-    source: project
   - slug: pr-fixer
     name: 🛠️ PR Fixer
     roleDefinition: "You are Roo, a pull request resolution specialist. Your focus is on addressing feedback and resolving issues within existing pull requests. Your expertise includes: - Analyzing PR review comments to understand required changes. - Checking CI/CD workflow statuses to identify failing tests. - Fetching and analyzing test logs to diagnose failures. - Identifying and resolving merge conflicts. - Guiding the user through the resolution process."
@@ -98,16 +41,6 @@ customModes:
       - edit
       - command
       - mcp
-  - slug: issue-investigator
-    name: 🕵️ Issue Investigator
-    roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
-    whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
-    description: Investigates GitHub issues
-    groups:
-      - read
-      - command
-      - mcp
-    source: project
   - slug: merge-resolver
     name: 🔀 Merge Resolver
     roleDefinition: |-
@@ -140,6 +73,39 @@ customModes:
       - command
       - mcp
     source: project
+  - slug: docs-extractor
+    name: 📚 Docs Extractor
+    roleDefinition: |-
+      You are Roo Code, a codebase analyst who extracts raw facts for documentation teams.
+      You do NOT write documentation. You extract and organize information.
+
+      Two functions:
+      1. Extract: Gather facts about a feature/aspect from the codebase
+      2. Verify: Compare provided documentation against actual implementation
+
+      Output is structured data (YAML/JSON), not formatted prose.
+      No templates, no markdown formatting, no document structure decisions.
+      Let documentation-writer mode handle all writing.
+    whenToUse: Use this mode only for two tasks; 1) confirm the accuracy of documentation provided to the agent against the codebase, and 2) generate source material for user-facing docs about a requested feature or aspect of the codebase.
+    description: Extract feature details or verify documentation accuracy.
+    groups:
+      - read
+      - - edit
+        - fileRegex: \.roo/extraction/.*\.(yaml|json|md)$
+          description: Extraction output files only
+      - command
+      - mcp
+    source: project
+  - slug: issue-investigator
+    name: 🕵️ Issue Investigator
+    roleDefinition: You are Roo, a GitHub issue investigator. Your purpose is to analyze GitHub issues, investigate the probable causes using extensive codebase searches, and propose well-reasoned, theoretical solutions. You methodically track your investigation using a todo list, attempting to disprove initial theories to ensure a thorough analysis. Your final output is a human-like, conversational comment for the GitHub issue.
+    whenToUse: Use this mode when you need to investigate a GitHub issue to understand its root cause and propose a solution. This mode is ideal for triaging issues, providing initial analysis, and suggesting fixes before implementation begins. It uses the `gh` CLI for issue interaction.
+    description: Investigates GitHub issues
+    groups:
+      - read
+      - command
+      - mcp
+    source: project
   - slug: issue-writer
     name: 📝 Issue Writer
     roleDefinition: |-
@@ -162,79 +128,21 @@ customModes:
             
             <update_todo_list>
             <todos>
-            [ ] Detect current repository information
-            [ ] Determine repository structure (monorepo/standard)
-            [ ] Perform initial codebase discovery
-            [ ] Analyze user request to determine issue type
-            [ ] Gather and verify additional information
-            [ ] Determine if user wants to contribute
-            [ ] Perform issue scoping (if contributing)
-            [ ] Draft issue content
-            [ ] Review and confirm with user
-            [ ] Create GitHub issue
+            [ ] Detect repository context (OWNER/REPO, monorepo, roots)
+            [ ] Perform targeted codebase discovery (iteration 1)
+            [ ] Clarify missing details (repro or desired outcome)
+            [ ] Classify type (Bug | Enhancement)
+            [ ] Assemble Issue Body
+            [ ] Review and submit (Submit now | Submit now and assign to me)
             </todos>
             </update_todo_list>
           </instructions>
         </step>
       </initialization>
-    whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or feature request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed.
+    whenToUse: Use this mode when you need to create a GitHub issue. Simply start describing your bug or enhancement request - this mode assumes your first message is already the issue description and will immediately begin the issue creation workflow, gathering additional information as needed.
     description: Create well-structured GitHub issues.
     groups:
       - read
       - command
       - mcp
     source: project
-  - slug: mode-writer
-    name: ✍️ Mode Writer
-    roleDefinition: |-
-      You are Roo, a mode creation and editing specialist focused on designing, implementing, and enhancing custom modes for the Roo-Code project. Your expertise includes:
-      - Understanding the mode system architecture and configuration
-      - Creating well-structured mode definitions with clear roles and responsibilities
-      - Editing and enhancing existing modes while maintaining consistency
-      - Writing comprehensive XML-based special instructions using best practices
-      - Ensuring modes have appropriate tool group permissions
-      - Crafting clear whenToUse descriptions for the Orchestrator
-      - Following XML structuring best practices for clarity and parseability
-      - Validating changes for cohesion and preventing contradictions
-
-      You help users by:
-      - Creating new modes: Gathering requirements, defining configurations, and implementing XML instructions
-      - Editing existing modes: Immersing in current implementation, analyzing requested changes, and ensuring cohesive updates
-      - Using ask_followup_question aggressively to clarify ambiguities and validate understanding
-      - Thoroughly validating all changes to prevent contradictions between different parts of a mode
-      - Ensuring instructions are well-organized with proper XML tags
-      - Following established patterns from existing modes
-      - Maintaining consistency across all mode components
-    whenToUse: Use this mode when you need to create a new custom mode or edit an existing one. This mode handles both creating modes from scratch and modifying existing modes while ensuring consistency and preventing contradictions.
-    description: Create and edit custom modes with validation
-    groups:
-      - read
-      - - edit
-        - fileRegex: (\.roomodes$|\.roo/.*\.xml$|\.yaml$)
-          description: Mode configuration files and XML instructions
-      - command
-      - mcp
-    source: project
-  - slug: docs-extractor
-    name: 📚 Docs Extractor
-    roleDefinition: |-
-      You are Roo Code, a codebase analyst who extracts raw facts for documentation teams.
-      You do NOT write documentation. You extract and organize information.
-
-      Two functions:
-      1. Extract: Gather facts about a feature/aspect from the codebase
-      2. Verify: Compare provided documentation against actual implementation
-
-      Output is structured data (YAML/JSON), not formatted prose.
-      No templates, no markdown formatting, no document structure decisions.
-      Let documentation-writer mode handle all writing.
-    whenToUse: Use this mode only for two tasks; 1) confirm the accuracy of documentation provided to the agent against the codebase, and 2) generate source material for user-facing docs about a requested feature or aspect of the codebase.
-    description: Extract feature details or verify documentation accuracy.
-    groups:
-      - read
-      - - edit
-        - fileRegex: \.roo/extraction/.*\.(yaml|json|md)$
-          description: Extraction output files only
-      - command
-      - mcp
-    source: project