From 25b094d2f3564c47e27623beccb6a3396181762c Mon Sep 17 00:00:00 2001 From: hannesrudolph Date: Mon, 28 Jul 2025 18:54:48 -0600 Subject: [PATCH] improve: enhance new_task tool description for better LLM understanding - Made the description more explicit about when and how to use todos - Added clearer examples showing both simple and complex use cases - Emphasized the importance of including todos for complex subtasks - Provided more detailed formatting instructions - Added an IMPORTANT note to encourage todo usage for better task organization --- .../1_orchestrator_workflow.xml | 202 ---------- .../2_critical_review_guidelines.xml | 208 ---------- .../3_delegation_patterns.xml | 238 ------------ .../rules-pr-reviewer/4_github_operations.xml | 224 ----------- .../5_context_management.xml | 356 ------------------ .roomodes | 43 +-- .../architect-mode-prompt.snap | 31 +- .../ask-mode-prompt.snap | 31 +- .../mcp-server-creation-disabled.snap | 31 +- .../mcp-server-creation-enabled.snap | 31 +- .../partial-reads-enabled.snap | 31 +- .../consistent-system-prompt.snap | 31 +- .../with-computer-use-support.snap | 31 +- .../with-diff-enabled-false.snap | 31 +- .../system-prompt/with-diff-enabled-true.snap | 31 +- .../with-diff-enabled-undefined.snap | 31 +- .../with-different-viewport-size.snap | 31 +- .../system-prompt/with-mcp-hub-provided.snap | 31 +- .../system-prompt/with-undefined-mcp-hub.snap | 31 +- src/core/prompts/tools/new-task.ts | 31 +- 20 files changed, 322 insertions(+), 1383 deletions(-) delete mode 100644 .roo/rules-pr-reviewer/1_orchestrator_workflow.xml delete mode 100644 .roo/rules-pr-reviewer/2_critical_review_guidelines.xml delete mode 100644 .roo/rules-pr-reviewer/3_delegation_patterns.xml delete mode 100644 .roo/rules-pr-reviewer/4_github_operations.xml delete mode 100644 .roo/rules-pr-reviewer/5_context_management.xml diff --git a/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml b/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml deleted file mode 100644 index 8bb94694d6..0000000000 --- a/.roo/rules-pr-reviewer/1_orchestrator_workflow.xml +++ /dev/null @@ -1,202 +0,0 @@ - - - This workflow orchestrates a comprehensive pull request review process by delegating - specialized analysis tasks to appropriate modes while maintaining context through - structured report files. The orchestrator ensures critical review coverage while - avoiding redundant feedback. All GitHub operations are performed using the GitHub CLI. - - - - - Parse PR Information and Initialize Context - - Extract PR information from user input (URL or PR number). - Create context directory and tracking files. - If called by another mode (Issue Fixer, PR Fixer), set calledByMode field. - - - - Parse PR URL or number from user input - - Create directory: .roo/temp/pr-[PR_NUMBER]/ - - Initialize review-context.json with PR metadata - - Check if called by another mode and record it - - - - - - - Fetch PR Details and Context - - Use GitHub CLI to fetch comprehensive PR details. - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles - - .roo/temp/pr-[PR_NUMBER]/pr-metadata.json - - - - Fetch Linked Issue - - If PR references an issue, fetch its details for context. - - - gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state - - .roo/temp/pr-[PR_NUMBER]/linked-issue.json - - - - Fetch Existing Comments and Reviews - - CRITICAL: Get all existing feedback to avoid redundancy. - - - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments' - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews' - - .roo/temp/pr-[PR_NUMBER]/existing-feedback.json - - - - Check Out PR Locally - gh pr checkout [PR_NUMBER] --repo [owner]/[repo] - Enable local code analysis and pattern comparison - - - - - - Delegate Pattern Analysis - - Create a subtask to analyze code patterns and organization. - - - code - - - Identifying similar existing features/components - - Checking if implementations follow established patterns - - Finding potential code redundancy - - Verifying test organization - - Checking file/directory structure consistency - - .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md - - - - - Delegate Architecture Review - - Create a subtask for architectural analysis. - - - architect - - - Module boundary violations - - Dependency management issues - - Separation of concerns - - Potential circular dependencies - - Overall architectural consistency - - .roo/temp/pr-[PR_NUMBER]/architecture-review.md - - - - - Delegate Test Coverage Analysis - - If test files are modified or added, delegate test analysis. - - - test - - - Test organization and location - - Test coverage adequacy - - Test naming conventions - - Mock usage patterns - - Edge case coverage - - .roo/temp/pr-[PR_NUMBER]/test-analysis.md - - - - - - - Synthesize Findings - - Collect all delegated analysis results and create comprehensive review. - - - - Read all analysis files from .roo/temp/pr-[PR_NUMBER]/ - - Identify critical issues vs suggestions - - Check against existing comments to avoid redundancy - - Prioritize findings by impact - - - - - Create Final Review Report - - Generate comprehensive review report with all findings. - - .roo/temp/pr-[PR_NUMBER]/final-review.md - - - Executive Summary - - Critical Issues (must fix) - - Pattern Inconsistencies - - Redundancy Findings - - Architecture Concerns - - Test Coverage Issues - - Minor Suggestions - - - - - - - Present Review to User - - Show the review findings and ask for action. - - - - Only present the analysis report, do not comment on PR - - - Ask user if they want to post the review as a comment - - - - - - Post Review Comment (if approved) - - If user approves and not called by another mode, post review using GitHub CLI. - - - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file .roo/temp/pr-[PR_NUMBER]/final-review.md - - - - - - - - Inform user to run 'gh auth login' and check authentication status - - - Verify PR number and repository, ask user to confirm details - - - Wait briefly and retry, inform user about rate limiting - - - - Continue with available analysis and note limitations - - - Always save intermediate results to temp files - - - \ No newline at end of file diff --git a/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml b/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml deleted file mode 100644 index ebccff3dbc..0000000000 --- a/.roo/rules-pr-reviewer/2_critical_review_guidelines.xml +++ /dev/null @@ -1,208 +0,0 @@ - - - These guidelines ensure PR reviews are appropriately critical while remaining - constructive. The goal is to maintain high code quality and consistency - across the codebase by identifying issues that might be overlooked in a - less thorough review. - - - - - Always support criticism with evidence from the codebase - - Instead of: "This doesn't follow our patterns" - Say: "This implementation differs from the pattern used in src/api/handlers/*.ts - where we consistently use the factory pattern for endpoint creation" - - - - - Reference similar existing implementations - - 1. Find 2-3 examples of similar features - 2. Identify the common patterns they follow - 3. Explain how the PR deviates from these patterns - 4. Suggest alignment with existing approaches - - - - - Challenge architectural choices when appropriate - - - "Why was this implemented as a separate module instead of extending the existing X module?" - - "This introduces a new pattern for Y. Have we considered using the established pattern from Z?" - - "This creates a circular dependency with module A. Could we restructure to maintain cleaner boundaries?" - - - - - - - Do new endpoints follow the same structure as existing ones? - Are error responses consistent with other endpoints? - Is authentication/authorization handled the same way? - Are request validations following established patterns? - - - - Do components follow the same file structure (types, helpers, component)? - Are props interfaces defined consistently? - Is state management approach consistent with similar components? - Are hooks used in the same patterns as elsewhere? - - - - Are test files in the correct directory structure? - Do test descriptions follow the same format? - Are mocking strategies consistent with other tests? - Is test data generation following established patterns? - - - - Could this utility already exist elsewhere? - Should this be added to an existing utility module? - Does the naming convention match other utilities? - Are similar transformations already implemented? - - - - - - - Search for similar functionality by behavior - - If PR adds a "formatDate" function, search for: - - "date format" - - "format.*date" - - "dateFormat" - - Existing date manipulation utilities - - - - - Search for similar code patterns - - If PR adds error handling, search for: - - try/catch patterns in similar contexts - - Error boundary implementations - - Existing error utilities - - - - - Check what similar files import - - Look at imports in files with similar purposes - to discover existing utilities that could be reused - - - - - - - Reimplementing existing utilities - - - String manipulation functions - - Array transformations - - Date formatting - - API response transformations - - - - - Creating similar components - - - Modal variations that could use a base modal - - Form inputs that could extend existing inputs - - List components with slight variations - - - - - Repeating business logic - - - Validation rules implemented multiple times - - Permission checks duplicated across files - - Data transformation logic repeated - - - - - - - - - - - - - - - - - - Issues that should block PR approval - - - Security vulnerabilities - - Breaking changes without migration path - - Significant pattern violations that would confuse future developers - - Major redundancy that adds maintenance burden - - - - - Important issues that need addressing - - - Test files in wrong location - - Inconsistent error handling - - Missing critical test cases - - Code organization that violates module boundaries - - - - - Improvements that would benefit the codebase - - - Minor pattern inconsistencies - - Opportunities for code reuse - - Additional test coverage - - Documentation improvements - - - - \ No newline at end of file diff --git a/.roo/rules-pr-reviewer/3_delegation_patterns.xml b/.roo/rules-pr-reviewer/3_delegation_patterns.xml deleted file mode 100644 index 9632c7dcf7..0000000000 --- a/.roo/rules-pr-reviewer/3_delegation_patterns.xml +++ /dev/null @@ -1,238 +0,0 @@ - - - Patterns for effectively delegating analysis tasks to specialized modes - while maintaining context and ensuring comprehensive review coverage. - - - - - - When PR contains new features or significant code changes - - code - - Analyze the following changed files for pattern consistency: - [List of changed files] - - Please focus on: - 1. Finding similar existing implementations in the codebase - 2. Identifying established patterns for this type of feature - 3. Checking if the new code follows these patterns - 4. Looking for potential code redundancy - 5. Verifying proper file organization - - Use codebase_search and search_files to find similar code. - Document all findings with specific examples and file references. - - Save your analysis to: .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md - - Format the output as: - ## Pattern Analysis for PR #[PR_NUMBER] - ### Similar Existing Implementations - ### Established Patterns - ### Pattern Deviations - ### Redundancy Findings - ### Organization Issues - - - - - - When PR modifies core modules, adds new modules, or changes dependencies - - architect - - Review the architectural implications of PR #[PR_NUMBER]: - - Changed files: - [List of changed files] - - PR Description: - [PR description] - - Please analyze: - 1. Module boundary adherence - 2. Dependency management (new dependencies, circular dependencies) - 3. Separation of concerns - 4. Impact on system architecture - 5. Consistency with architectural patterns - - Save your findings to: .roo/temp/pr-[PR_NUMBER]/architecture-review.md - - Format as: - ## Architecture Review for PR #[PR_NUMBER] - ### Module Boundaries - ### Dependency Analysis - ### Architectural Concerns - ### Recommendations - - - - - - When PR adds or modifies test files - - test - - Analyze test changes in PR #[PR_NUMBER]: - - Test files changed: - [List of test files] - - Please review: - 1. Test file organization and location - 2. Test naming conventions - 3. Coverage of edge cases - 4. Mock usage patterns - 5. Consistency with existing test patterns - - Compare with similar existing tests in the codebase. - - Save analysis to: .roo/temp/pr-[PR_NUMBER]/test-analysis.md - - Format as: - ## Test Analysis for PR #[PR_NUMBER] - ### Test Organization - ### Coverage Assessment - ### Pattern Consistency - ### Recommendations - - - - - - When PR modifies UI components or adds new ones - - design-engineer - - Review UI changes in PR #[PR_NUMBER]: - - UI files changed: - [List of UI files] - - Please analyze: - 1. Component structure consistency - 2. Styling approach (Tailwind usage) - 3. Accessibility considerations - 4. i18n implementation - 5. Component reusability - - Save findings to: .roo/temp/pr-[PR_NUMBER]/ui-review.md - - - - - - - Always save delegation results to temp files - .roo/temp/pr-[PR_NUMBER]/[analysis-type].md - - - - Request structured markdown output from delegates - - - Easy to parse and combine - - Consistent formatting - - Clear section headers - - - - - Include relevant context in delegation requests - - - PR number and description - - List of changed files - - Specific areas of concern - - Output file location - - - - - - - Delegate tasks one at a time, using results to inform next delegation - - 1. Pattern analysis first - 2. If patterns violated, delegate architecture review - 3. If tests affected, delegate test analysis - - - - - Delegate multiple independent analyses simultaneously - - - Pattern analysis (code mode) - - Test analysis (test mode) - - UI review (design-engineer mode) - - - - - Only delegate based on file types changed - - - If *.test.ts changed -> delegate to test mode - - If src/components/* changed -> delegate to design-engineer - - If package.json changed -> delegate to architect - - - - - - - Read all analysis files from temp directory - - - pattern-analysis.md - - architecture-review.md - - test-analysis.md - - ui-review.md - - - - - Find common issues across analyses - - - Pattern violations mentioned multiple times - - Redundancy identified by different modes - - Organizational issues - - - - - Categorize by severity - - - Critical (blocks PR) - - Important (should fix) - - Suggestions (nice to have) - - - - - Combine all findings into final review - - ## PR Review Summary - ### Critical Issues - ### Pattern Inconsistencies - ### Architecture Concerns - ### Test Coverage - ### Suggestions - - - - - - - Continue with available analyses - Document which analyses couldn't be completed - - - - Perform basic analysis in orchestrator mode - Note limitations in final report - - - - Use completed analyses - Set reasonable time limits for delegations - - - \ No newline at end of file diff --git a/.roo/rules-pr-reviewer/4_github_operations.xml b/.roo/rules-pr-reviewer/4_github_operations.xml deleted file mode 100644 index ad1fdc4459..0000000000 --- a/.roo/rules-pr-reviewer/4_github_operations.xml +++ /dev/null @@ -1,224 +0,0 @@ - - - Guidelines for handling GitHub operations using the GitHub CLI (gh). - This mode exclusively uses command-line operations for all GitHub interactions. - - - - - GitHub CLI must be installed and authenticated - gh auth status - https://cli.github.com/ - - - User must be authenticated with appropriate permissions - gh auth login - - - - - - Fetch comprehensive PR metadata - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles - JSON - .roo/temp/pr-[PR_NUMBER]/pr-metadata.json - - - - Get the full diff of PR changes - gh pr diff [PR_NUMBER] --repo [owner]/[repo] - .roo/temp/pr-[PR_NUMBER]/pr.diff - - - - List all files changed in the PR - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json files --jq '.files[].path' - Line-separated file paths - - - - Get all comments on the PR - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json comments --jq '.comments' - JSON array of comments - - - - Get all reviews on the PR - gh pr view [PR_NUMBER] --repo [owner]/[repo] --json reviews --jq '.reviews' - JSON array of reviews - - - - Check out PR branch locally for analysis - gh pr checkout [PR_NUMBER] --repo [owner]/[repo] - This switches the current branch to the PR branch - - - - Post a comment on the PR - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body-file [file_path] - gh pr comment [PR_NUMBER] --repo [owner]/[repo] --body "[comment_text]" - - - - Create a PR review with comments - gh pr review [PR_NUMBER] --repo [owner]/[repo] --comment --body-file [review_file] - - - - - - - - - Get issue details (for linked issues) - gh issue view [issue_number] --repo [owner]/[repo] --json number,title,body,author,state - JSON - - - - - - - Error contains "authentication" or "not logged in" - - - 1. Inform user about auth issue - 2. Suggest running: gh auth login - 3. Check status with: gh auth status - - - - - - Error contains "rate limit" or "API rate limit exceeded" - - - 1. Wait 30-60 seconds before retry - 2. Inform user about rate limiting - 3. Consider reducing API calls - - - - - - Error contains "not found" or "could not find pull request" - - - 1. Verify PR number and repository format - 2. Check if repository is accessible - 3. Ensure correct owner/repo format - - - - - - Error contains "permission denied" or "403" - - - 1. Check repository permissions - 2. Verify authentication scope - 3. May need to re-authenticate with proper scopes - - - - - - - Always save command outputs to temp files - Preserve data for analysis and recovery - - - - Use jq for JSON parsing when available - - gh pr view --json files --jq '.files[].path' - - - - - For PRs with many files, save outputs to files first - More than 50 files - Save to file, then process in chunks - - - - Always validate JSON before parsing - jq empty < file.json || echo "Invalid JSON" - - - - - - gh pr view [number] - - - - - - - number, title, author, state, body, url, - headRefName, baseRefName, files, additions, - deletions, changedFiles, comments, reviews, - isDraft, mergeable, mergeStateStatus - - - - - - gh pr checkout [number]: Check out PR locally - gh pr diff [number]: View PR diff - gh pr comment [number] --body "[text]": Add comment - gh pr review [number]: Create review - gh pr close [number]: Close PR - gh pr reopen [number]: Reopen PR - - - - - gh issue view [number] - - number, title, body, author, state, - labels, assignees, milestone, comments - - - - - - gh repo view --json [fields]: Get repo info - gh repo clone [owner]/[repo]: Clone repository - - - - - - Always specify --repo to avoid ambiguity - Use --json for structured data that needs parsing - Save command outputs to temp files for reliability - Check gh auth status before starting operations - Handle both personal repos and organization repos - Use meaningful file names when saving outputs - Include error handling for all commands - Document the expected format of saved files - - - - - Fetch all PR data for analysis - - gh pr view 123 --repo owner/repo --json number,title,author,state,body,url,headRefName,baseRefName,files,additions,deletions,changedFiles > .roo/temp/pr-123/metadata.json - gh pr view 123 --repo owner/repo --json comments > .roo/temp/pr-123/comments.json - gh pr view 123 --repo owner/repo --json reviews > .roo/temp/pr-123/reviews.json - gh pr diff 123 --repo owner/repo > .roo/temp/pr-123/pr.diff - - - - - Post a comprehensive review - - Create review content in .roo/temp/pr-123/review.md - gh pr review 123 --repo owner/repo --comment --body-file .roo/temp/pr-123/review.md - - - - \ No newline at end of file diff --git a/.roo/rules-pr-reviewer/5_context_management.xml b/.roo/rules-pr-reviewer/5_context_management.xml deleted file mode 100644 index 4b55431c74..0000000000 --- a/.roo/rules-pr-reviewer/5_context_management.xml +++ /dev/null @@ -1,356 +0,0 @@ - - - Strategies for maintaining review context across delegated tasks and - ensuring no information is lost during the orchestration process. - - - - - Central tracking file for the entire review process - .roo/temp/pr-[PR_NUMBER]/review-context.json - - { - "prNumber": "string", - "repository": "string", - "reviewStartTime": "ISO timestamp", - "calledByMode": "string or null", - "prMetadata": { - "title": "string", - "author": "string", - "state": "string", - "baseRefName": "string", - "headRefName": "string", - "additions": "number", - "deletions": "number", - "changedFiles": "number" - }, - "linkedIssue": { - "number": "number", - "title": "string", - "body": "string" - }, - "existingComments": [], - "existingReviews": [], - "filesChanged": [], - "delegatedTasks": [ - { - "mode": "string", - "status": "pending|completed|failed", - "outputFile": "string", - "startTime": "ISO timestamp", - "endTime": "ISO timestamp" - } - ], - "findings": { - "critical": [], - "patterns": [], - "redundancy": [], - "architecture": [], - "tests": [] - }, - "reviewStatus": "initialized|analyzing|synthesizing|completed" - } - - - - - Raw PR data from GitHub - .roo/temp/pr-[PR_NUMBER]/pr-metadata.json - - - - All existing comments and reviews - .roo/temp/pr-[PR_NUMBER]/existing-feedback.json - - - - Output from code mode delegation - .roo/temp/pr-[PR_NUMBER]/pattern-analysis.md - - - - Output from architect mode delegation - .roo/temp/pr-[PR_NUMBER]/architecture-review.md - - - - Output from test mode delegation - .roo/temp/pr-[PR_NUMBER]/test-analysis.md - - - - Synthesized review ready for posting - .roo/temp/pr-[PR_NUMBER]/final-review.md - - - - - - Update review-context.json with PR metadata - -.roo/temp/pr-123/review-context.json - - - - - -.roo/temp/pr-123/review-context.json - -{ - ...existing, - "prMetadata": { - "title": "Fix user authentication", - "author": "developer123", - ... - }, - "filesChanged": ["src/auth.ts", "tests/auth.test.ts"], - "reviewStatus": "analyzing" -} - - - ]]> - - - - Update delegatedTasks array with task status - - - mode: Which mode was delegated to - - status: pending -> completed/failed - - outputFile: Where results were saved - - timestamps: Start and end times - - - - - Update findings object with categorized issues - - - critical: Must-fix issues - - patterns: Pattern inconsistencies - - redundancy: Duplicate code findings - - architecture: Architectural concerns - - tests: Test-related issues - - - - - - - Always read-modify-write for JSON updates - - 1. Read current context file - 2. Parse JSON - 3. Update specific fields - 4. Write entire updated JSON - - - - - Save copies of important data - - - PR diff before analysis - - Existing comments before review - - Each delegation output - - - - - Track review progress through status field - - - initialized: Just started - - analyzing: Delegating tasks - - synthesizing: Combining results - - completed: Ready for user - - - - - - - Some delegations failed - - 1. Mark failed tasks in context - 2. Continue with available data - 3. Note limitations in final review - - - - - JSON file becomes invalid - - 1. Try to recover from backups - 2. Reconstruct from individual files - 3. Start fresh if necessary - - - - - Review process interrupted - - 1. Check reviewStatus field - 2. Resume from last completed step - 3. Re-run failed delegations - - - - - - - Keep reviewStatus current to enable recovery - - - - Add timestamps to all operations for debugging - - - - Ensure JSON is valid before writing - - - - Make it clear what each file contains - - - - Suggest cleaning .roo/temp/ periodically - - - - - - Initialize context - -New-Item -ItemType Directory -Force -Path ".roo/temp/pr-123" - - - -.roo/temp/pr-123/review-context.json - -{ - "prNumber": "123", - "repository": "RooCodeInc/Roo-Code", - "reviewStartTime": "2025-01-04T18:00:00Z", - "calledByMode": null, - "prMetadata": {}, - "linkedIssue": {}, - "existingComments": [], - "existingReviews": [], - "filesChanged": [], - "delegatedTasks": [], - "findings": { - "critical": [], - "patterns": [], - "redundancy": [], - "architecture": [], - "tests": [] - }, - "reviewStatus": "initialized" -} - - - ]]> - - - - Update after GitHub fetch - -.roo/temp/pr-123/review-context.json - - - - - -.roo/temp/pr-123/review-context.json - -{ - ...existing, - "prMetadata": { - "title": "Fix user authentication", - "author": "developer123", - "state": "open", - "baseRefName": "main", - "headRefName": "fix-auth", - "additions": 150, - "deletions": 50, - "changedFiles": 3 - }, - "filesChanged": ["src/auth.ts", "tests/auth.test.ts", "docs/auth.md"], - "reviewStatus": "analyzing" -} - - - ]]> - - - - Track delegation - - -.roo/temp/pr-123/review-context.json - - - - -.roo/temp/pr-123/review-context.json - -{ - ...existing, - "delegatedTasks": [ - ...existing, - { - "mode": "code", - "status": "pending", - "outputFile": "pattern-analysis.md", - "startTime": "2025-01-04T18:05:00Z", - "endTime": null - } - ] -} - - - - - - ]]> - - - - Synthesize results - - -.roo/temp/pr-123/pattern-analysis.md - - - -.roo/temp/pr-123/architecture-review.md - - - -.roo/temp/pr-123/test-analysis.md - - - - -.roo/temp/pr-123/review-context.json - -{ - ...existing, - "findings": { - "critical": ["Missing error handling in auth.ts"], - "patterns": ["Inconsistent naming convention"], - "redundancy": ["Duplicate validation logic"], - "architecture": [], - "tests": ["Missing test for edge case"] - }, - "reviewStatus": "completed" -} - - - ]]> - - - \ No newline at end of file diff --git a/.roomodes b/.roomodes index e9cb7d8a94..c08d438b8d 100644 --- a/.roomodes +++ b/.roomodes @@ -164,35 +164,6 @@ customModes: - fileRegex: (apps/vscode-e2e/.*\.(ts|js)$|packages/types/.*\.ts$) description: E2E test files, test utilities, and API type definitions source: project - - slug: pr-reviewer - name: 🔍 PR Reviewer - roleDefinition: |- - You are Roo, a critical pull request review orchestrator specializing in code quality, architectural consistency, and codebase organization. Your expertise includes: - - Orchestrating comprehensive PR reviews by delegating specialized analysis tasks - - Analyzing pull request diffs with a critical eye for code organization and patterns - - Evaluating whether changes follow established codebase patterns and conventions - - Identifying redundant or duplicate code that already exists elsewhere - - Ensuring tests are properly organized with other similar tests - - Verifying that new features follow patterns established by similar existing features - - Detecting code smells, technical debt, and architectural inconsistencies - - Delegating deep codebase analysis to specialized modes when needed - - Maintaining context through structured report files in .roo/temp/pr-[number]/ - - Ensuring proper internationalization (i18n) for UI changes - - Providing direct, constructive feedback that improves code quality - - Being appropriately critical to maintain high code standards - - Using GitHub CLI when MCP tools are unavailable - - You work primarily with the RooCodeInc/Roo-Code repository, creating context reports to track findings and delegating complex pattern analysis to specialized modes while maintaining overall review coordination. When called by other modes (Issue Fixer, PR Fixer), you focus only on analysis without commenting on the PR. - whenToUse: Use this mode to critically review pull requests, focusing on code organization, pattern consistency, and identifying redundancy or architectural issues. This mode orchestrates complex analysis tasks while maintaining review context. - description: Critically review pull requests. - groups: - - read - - - edit - - fileRegex: (\.md$|\.roo/temp/pr-.*\.(json|md|txt)$) - description: Markdown files and PR review context files - - mcp - - command - source: project - slug: docs-extractor name: 📚 Docs Extractor roleDefinition: You are Roo, a comprehensive documentation extraction specialist focused on analyzing and documenting all technical and non-technical information about features and components within codebases. @@ -257,3 +228,17 @@ customModes: - command - mcp source: project + - slug: pr-reviewer + name: 🔍 PR Reviewer + roleDefinition: |- + You are Roo, a pull request reviewer specializing in code quality, structure, and translation consistency. Your expertise includes: - Analyzing pull request diffs and understanding code changes in context - Evaluating code quality, identifying code smells and technical debt - Ensuring structural consistency across the codebase - Verifying proper internationalization (i18n) for UI changes - Providing constructive feedback with a friendly, curious tone - Reviewing test coverage and quality without executing tests - Identifying opportunities for code improvements and refactoring + You work primarily with the RooCodeInc/Roo-Code repository, using GitHub MCP tools to fetch and review pull requests. You check out PRs locally for better context understanding and focus on providing actionable, constructive feedback that helps improve code quality. + whenToUse: Use this mode to review pull requests on the Roo-Code GitHub repository or any other repository if specified by the user. + groups: + - read + - - edit + - fileRegex: \.md$ + description: Markdown files only + - mcp + - command + source: project diff --git a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap +++ b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap index 4c7986b27e..deaed5aaba 100644 --- a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap +++ b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap @@ -246,12 +246,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -265,25 +268,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap +++ b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap index dcf10902be..e00e213206 100644 --- a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap +++ b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap @@ -398,12 +398,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -417,25 +420,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap index b832a7569b..0c2e9a9a9a 100644 --- a/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap +++ b/src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap @@ -354,12 +354,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -373,25 +376,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap index 93c9438bfe..5e36683004 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap @@ -402,12 +402,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -421,25 +424,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap index 8087ec392e..7cefbfcbf6 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap @@ -437,12 +437,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -456,25 +459,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap index 285984d92c..244d858539 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap @@ -402,12 +402,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -421,25 +424,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap index dcf10902be..e00e213206 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap @@ -398,12 +398,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -417,25 +420,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap index 347b1abeaf..b09a479f03 100644 --- a/src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap +++ b/src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap @@ -349,12 +349,15 @@ Example: Requesting to switch to code mode ## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -368,25 +371,35 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. + ## update_todo_list diff --git a/src/core/prompts/tools/new-task.ts b/src/core/prompts/tools/new-task.ts index a8cfd9c5d2..82b7ae1196 100644 --- a/src/core/prompts/tools/new-task.ts +++ b/src/core/prompts/tools/new-task.ts @@ -2,12 +2,15 @@ import { ToolArgs } from "./types" export function getNewTaskDescription(_args: ToolArgs): string { return `## new_task -Description: This will let you create a new task instance in the chosen mode using your provided message. +Description: This will let you create a new task instance in the chosen mode using your provided message. You can optionally provide a todo list to help organize and track the subtask's progress. Parameters: - mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect"). - message: (required) The initial user message or instructions for this new task. -- todos: (optional) A markdown checklist of todo items to initialize the new task with. Use the same format as update_todo_list. +- todos: (optional) A markdown checklist of todo items to initialize the new task with. When creating subtasks for complex work, include todos to break down the work into manageable steps. Format each item as a markdown checkbox: + - [ ] for pending tasks + - [x] for completed tasks + - [-] for in-progress tasks Usage: @@ -21,23 +24,33 @@ Usage: -Example: +Example without todos: code -Implement a new feature for the application. +Fix the typo in the README file -Example with todos: +Example with todos (recommended for complex tasks): code -Implement user authentication +Implement user authentication system +[ ] Research authentication libraries [ ] Set up authentication middleware -[ ] Create login endpoint -[ ] Create logout endpoint +[ ] Create user model and database schema +[ ] Implement registration endpoint +[ ] Implement login endpoint +[ ] Implement logout endpoint +[ ] Add password hashing +[ ] Create JWT token generation [ ] Add session management -[ ] Write tests for authentication +[ ] Implement password reset functionality +[ ] Write unit tests for auth endpoints +[ ] Write integration tests +[ ] Update API documentation + +IMPORTANT: When delegating complex work to a subtask, always consider including a todos list to help the subtask stay organized and track progress effectively. ` }