ros/claude-task-master
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/main' into crunchyman/feat.add.mcp.2

Browse Source
This commit is contained in:
Eyal Toledano
2025-03-26 23:54:47 -04:00
parent bc4e68118c 98d5cefba8
commit 444fb24022
23 changed files with 2397 additions and 288 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
tasks/task_029.txt Normal file
View File

@@ -0,0 +1,33 @@
# Task ID: 29
# Title: Update Claude 3.7 Sonnet Integration with Beta Header for 128k Token Output
# Status: done
# Dependencies: None
# Priority: medium
# Description: Modify the ai-services.js file to include the beta header 'output-128k-2025-02-19' in Claude 3.7 Sonnet API requests to increase the maximum output token length to 128k tokens.
# Details:
The task involves updating the Claude 3.7 Sonnet integration in the ai-services.js file to take advantage of the new 128k token output capability. Specifically:
1. Locate the Claude 3.7 Sonnet API request configuration in ai-services.js
2. Add the beta header 'output-128k-2025-02-19' to the request headers
3. Update any related configuration parameters that might need adjustment for the increased token limit
4. Ensure that token counting and management logic is updated to account for the new 128k token output limit
5. Update any documentation comments in the code to reflect the new capability
6. Consider implementing a configuration option to enable/disable this feature, as it may be a beta feature subject to change
7. Verify that the token management logic correctly handles the increased limit without causing unexpected behavior
8. Ensure backward compatibility with existing code that might assume lower token limits
The implementation should be clean and maintainable, with appropriate error handling for cases where the beta header might not be supported in the future.
# Test Strategy:
Testing should verify that the beta header is correctly included and that the system properly handles the increased token limit:
1. Unit test: Verify that the API request to Claude 3.7 Sonnet includes the 'output-128k-2025-02-19' header
2. Integration test: Make an actual API call to Claude 3.7 Sonnet with the beta header and confirm a successful response
3. Test with a prompt designed to generate a very large response (>20k tokens but <128k tokens) and verify it completes successfully
4. Test the token counting logic with mock responses of various sizes to ensure it correctly handles responses approaching the 128k limit
5. Verify error handling by simulating API errors related to the beta header
6. Test any configuration options for enabling/disabling the feature
7. Performance test: Measure any impact on response time or system resources when handling very large responses
8. Regression test: Ensure existing functionality using Claude 3.7 Sonnet continues to work as expected
Document all test results, including any limitations or edge cases discovered during testing.

40
tasks/task_030.txt Normal file
View File

@@ -0,0 +1,40 @@
# Task ID: 30
# Title: Enhance parse-prd Command to Support Default PRD Path
# Status: done
# Dependencies: None
# Priority: medium
# Description: Modify the parse-prd command to automatically use a default PRD path when no path is explicitly provided, improving user experience by reducing the need for manual path specification.
# Details:
Currently, the parse-prd command requires users to explicitly specify the path to the PRD document. This enhancement should:
1. Implement a default PRD path configuration that can be set in the application settings or configuration file.
2. Update the parse-prd command to check for this default path when no path argument is provided.
3. Add a configuration option that allows users to set/update the default PRD path through a command like `config set default-prd-path <path>`.
4. Ensure backward compatibility by maintaining support for explicit path specification.
5. Add appropriate error handling for cases where the default path is not set or the file doesn't exist.
6. Update the command's help text to indicate that a default path will be used if none is specified.
7. Consider implementing path validation to ensure the default path points to a valid PRD document.
8. If multiple PRD formats are supported (Markdown, PDF, etc.), ensure the default path handling works with all supported formats.
9. Add logging for default path usage to help with debugging and usage analytics.
# Test Strategy:
1. Unit tests:
- Test that the command correctly uses the default path when no path is provided
- Test that explicit paths override the default path
- Test error handling when default path is not set
- Test error handling when default path is set but file doesn't exist
2. Integration tests:
- Test the full workflow of setting a default path and then using the parse-prd command without arguments
- Test with various file formats if multiple are supported
3. Manual testing:
- Verify the command works in a real environment with actual PRD documents
- Test the user experience of setting and using default paths
- Verify help text correctly explains the default path behavior
4. Edge cases to test:
- Relative vs. absolute paths for default path setting
- Path with special characters or spaces
- Very long paths approaching system limits
- Permissions issues with the default path location

42
tasks/task_031.txt Normal file
View File

@@ -0,0 +1,42 @@
# Task ID: 31
# Title: Add Config Flag Support to task-master init Command
# Status: done
# Dependencies: None
# Priority: low
# Description: Enhance the 'task-master init' command to accept configuration flags that allow users to bypass the interactive CLI questions and directly provide configuration values.
# Details:
Currently, the 'task-master init' command prompts users with a series of questions to set up the configuration. This task involves modifying the init command to accept command-line flags that can pre-populate these configuration values, allowing for a non-interactive setup process.
Implementation steps:
1. Identify all configuration options that are currently collected through CLI prompts during initialization
2. Create corresponding command-line flags for each configuration option (e.g., --project-name, --ai-provider, etc.)
3. Modify the init command handler to check for these flags before starting the interactive prompts
4. If a flag is provided, skip the corresponding prompt and use the provided value instead
5. If all required configuration values are provided via flags, skip the interactive process entirely
6. Update the command's help text to document all available flags and their usage
7. Ensure backward compatibility so the command still works with the interactive approach when no flags are provided
8. Consider adding a --non-interactive flag that will fail if any required configuration is missing rather than prompting for it (useful for scripts and CI/CD)
The implementation should follow the existing command structure and use the same configuration file format. Make sure to validate flag values with the same validation logic used for interactive inputs.
# Test Strategy:
Testing should verify both the interactive and non-interactive paths work correctly:
1. Unit tests:
- Test each flag individually to ensure it correctly overrides the corresponding prompt
- Test combinations of flags to ensure they work together properly
- Test validation of flag values to ensure invalid values are rejected
- Test the --non-interactive flag to ensure it fails when required values are missing
2. Integration tests:
- Test a complete initialization with all flags provided
- Test partial initialization with some flags and some interactive prompts
- Test initialization with no flags (fully interactive)
3. Manual testing scenarios:
- Run 'task-master init --project-name="Test Project" --ai-provider="openai"' and verify it skips those prompts
- Run 'task-master init --help' and verify all flags are documented
- Run 'task-master init --non-interactive' without required flags and verify it fails with a helpful error message
- Run a complete non-interactive initialization and verify the resulting configuration file matches expectations
Ensure the command's documentation is updated to reflect the new functionality, and verify that the help text accurately describes all available options.

56
tasks/task_032.txt Normal file
View File

@@ -0,0 +1,56 @@
# Task ID: 32
# Title: Implement 'learn' Command for Automatic Cursor Rule Generation
# Status: pending
# Dependencies: None
# Priority: high
# Description: Create a new 'learn' command that analyzes code changes and chat history to automatically generate or update Cursor rules in the .cursor/rules directory based on successful implementation patterns.
# Details:
Implement a new command in the task-master CLI that enables Cursor to learn from successful coding patterns:
1. Create a new module `commands/learn.js` that implements the command logic
2. Update `index.js` to register the new command
3. The command should:
- Accept an optional parameter for specifying which patterns to focus on
- Use git diff to extract code changes since the last commit
- Access the Cursor chat history if possible (investigate API or file storage location)
- Call Claude via ai-services.js with the following context:
* Code diffs
* Chat history excerpts showing challenges and solutions
* Existing rules from .cursor/rules if present
- Parse Claude's response to extract rule definitions
- Create or update .mdc files in the .cursor/rules directory
- Provide a summary of what was learned and which rules were updated
4. Create helper functions to:
- Extract relevant patterns from diffs
- Format the prompt for Claude to focus on identifying reusable patterns
- Parse Claude's response into valid rule definitions
- Handle rule conflicts or duplications
5. Ensure the command handles errors gracefully, especially if chat history is inaccessible
6. Add appropriate logging to show the learning process
7. Document the command in the README.md file
# Test Strategy:
1. Unit tests:
- Create tests for each helper function in isolation
- Mock git diff responses and chat history data
- Verify rule extraction logic works with different input patterns
- Test error handling for various failure scenarios
2. Integration tests:
- Test the command in a repository with actual code changes
- Verify it correctly generates .mdc files in the .cursor/rules directory
- Check that generated rules follow the correct format
- Verify the command correctly updates existing rules without losing custom modifications
3. Manual testing scenarios:
- Run the command after implementing a feature with specific patterns
- Verify the generated rules capture the intended patterns
- Test the command with and without existing rules
- Verify the command works when chat history is available and when it isn't
- Test with large diffs to ensure performance remains acceptable
4. Validation:
- After generating rules, use them in Cursor to verify they correctly guide future implementations
- Have multiple team members test the command to ensure consistent results

44
tasks/task_033.txt Normal file
View File

@@ -0,0 +1,44 @@
# Task ID: 33
# Title: Create and Integrate Windsurf Rules Document from MDC Files
# Status: done
# Dependencies: None
# Priority: medium
# Description: Develop functionality to generate a .windsurfrules document by combining and refactoring content from three primary .mdc files used for Cursor Rules, ensuring it's properly integrated into the initialization pipeline.
# Details:
This task involves creating a mechanism to generate a Windsurf-specific rules document by combining three existing MDC (Markdown Content) files that are currently used for Cursor Rules. The implementation should:
1. Identify and locate the three primary .mdc files used for Cursor Rules
2. Extract content from these files and merge them into a single document
3. Refactor the content to make it Windsurf-specific, replacing Cursor-specific terminology and adapting guidelines as needed
4. Create a function that generates a .windsurfrules document from this content
5. Integrate this function into the initialization pipeline
6. Implement logic to check if a .windsurfrules document already exists:
- If it exists, append the new content to it
- If it doesn't exist, create a new document
7. Ensure proper error handling for file operations
8. Add appropriate logging to track the generation and modification of the .windsurfrules document
The implementation should be modular and maintainable, with clear separation of concerns between content extraction, refactoring, and file operations.
# Test Strategy:
Testing should verify both the content generation and the integration with the initialization pipeline:
1. Unit Tests:
- Test the content extraction function with mock .mdc files
- Test the content refactoring function to ensure Cursor-specific terms are properly replaced
- Test the file operation functions with mock filesystem
2. Integration Tests:
- Test the creation of a new .windsurfrules document when none exists
- Test appending to an existing .windsurfrules document
- Test the complete initialization pipeline with the new functionality
3. Manual Verification:
- Inspect the generated .windsurfrules document to ensure content is properly combined and refactored
- Verify that Cursor-specific terminology has been replaced with Windsurf-specific terminology
- Run the initialization process multiple times to verify idempotence (content isn't duplicated on multiple runs)
4. Edge Cases:
- Test with missing or corrupted .mdc files
- Test with an existing but empty .windsurfrules document
- Test with an existing .windsurfrules document that already contains some of the content

50
tasks/tasks.json
View File

@@ -1681,6 +1681,56 @@
"parentTaskId": 28
}
]
},
{
"id": 29,
"title": "Update Claude 3.7 Sonnet Integration with Beta Header for 128k Token Output",
"description": "Modify the ai-services.js file to include the beta header 'output-128k-2025-02-19' in Claude 3.7 Sonnet API requests to increase the maximum output token length to 128k tokens.",
"status": "done",
"dependencies": [],
"priority": "medium",
"details": "The task involves updating the Claude 3.7 Sonnet integration in the ai-services.js file to take advantage of the new 128k token output capability. Specifically:\n\n1. Locate the Claude 3.7 Sonnet API request configuration in ai-services.js\n2. Add the beta header 'output-128k-2025-02-19' to the request headers\n3. Update any related configuration parameters that might need adjustment for the increased token limit\n4. Ensure that token counting and management logic is updated to account for the new 128k token output limit\n5. Update any documentation comments in the code to reflect the new capability\n6. Consider implementing a configuration option to enable/disable this feature, as it may be a beta feature subject to change\n7. Verify that the token management logic correctly handles the increased limit without causing unexpected behavior\n8. Ensure backward compatibility with existing code that might assume lower token limits\n\nThe implementation should be clean and maintainable, with appropriate error handling for cases where the beta header might not be supported in the future.",
"testStrategy": "Testing should verify that the beta header is correctly included and that the system properly handles the increased token limit:\n\n1. Unit test: Verify that the API request to Claude 3.7 Sonnet includes the 'output-128k-2025-02-19' header\n2. Integration test: Make an actual API call to Claude 3.7 Sonnet with the beta header and confirm a successful response\n3. Test with a prompt designed to generate a very large response (>20k tokens but <128k tokens) and verify it completes successfully\n4. Test the token counting logic with mock responses of various sizes to ensure it correctly handles responses approaching the 128k limit\n5. Verify error handling by simulating API errors related to the beta header\n6. Test any configuration options for enabling/disabling the feature\n7. Performance test: Measure any impact on response time or system resources when handling very large responses\n8. Regression test: Ensure existing functionality using Claude 3.7 Sonnet continues to work as expected\n\nDocument all test results, including any limitations or edge cases discovered during testing."
},
{
"id": 30,
"title": "Enhance parse-prd Command to Support Default PRD Path",
"description": "Modify the parse-prd command to automatically use a default PRD path when no path is explicitly provided, improving user experience by reducing the need for manual path specification.",
"status": "done",
"dependencies": [],
"priority": "medium",
"details": "Currently, the parse-prd command requires users to explicitly specify the path to the PRD document. This enhancement should:\n\n1. Implement a default PRD path configuration that can be set in the application settings or configuration file.\n2. Update the parse-prd command to check for this default path when no path argument is provided.\n3. Add a configuration option that allows users to set/update the default PRD path through a command like `config set default-prd-path <path>`.\n4. Ensure backward compatibility by maintaining support for explicit path specification.\n5. Add appropriate error handling for cases where the default path is not set or the file doesn't exist.\n6. Update the command's help text to indicate that a default path will be used if none is specified.\n7. Consider implementing path validation to ensure the default path points to a valid PRD document.\n8. If multiple PRD formats are supported (Markdown, PDF, etc.), ensure the default path handling works with all supported formats.\n9. Add logging for default path usage to help with debugging and usage analytics.",
"testStrategy": "1. Unit tests:\n - Test that the command correctly uses the default path when no path is provided\n - Test that explicit paths override the default path\n - Test error handling when default path is not set\n - Test error handling when default path is set but file doesn't exist\n\n2. Integration tests:\n - Test the full workflow of setting a default path and then using the parse-prd command without arguments\n - Test with various file formats if multiple are supported\n\n3. Manual testing:\n - Verify the command works in a real environment with actual PRD documents\n - Test the user experience of setting and using default paths\n - Verify help text correctly explains the default path behavior\n\n4. Edge cases to test:\n - Relative vs. absolute paths for default path setting\n - Path with special characters or spaces\n - Very long paths approaching system limits\n - Permissions issues with the default path location"
},
{
"id": 31,
"title": "Add Config Flag Support to task-master init Command",
"description": "Enhance the 'task-master init' command to accept configuration flags that allow users to bypass the interactive CLI questions and directly provide configuration values.",
"status": "done",
"dependencies": [],
"priority": "low",
"details": "Currently, the 'task-master init' command prompts users with a series of questions to set up the configuration. This task involves modifying the init command to accept command-line flags that can pre-populate these configuration values, allowing for a non-interactive setup process.\n\nImplementation steps:\n1. Identify all configuration options that are currently collected through CLI prompts during initialization\n2. Create corresponding command-line flags for each configuration option (e.g., --project-name, --ai-provider, etc.)\n3. Modify the init command handler to check for these flags before starting the interactive prompts\n4. If a flag is provided, skip the corresponding prompt and use the provided value instead\n5. If all required configuration values are provided via flags, skip the interactive process entirely\n6. Update the command's help text to document all available flags and their usage\n7. Ensure backward compatibility so the command still works with the interactive approach when no flags are provided\n8. Consider adding a --non-interactive flag that will fail if any required configuration is missing rather than prompting for it (useful for scripts and CI/CD)\n\nThe implementation should follow the existing command structure and use the same configuration file format. Make sure to validate flag values with the same validation logic used for interactive inputs.",
"testStrategy": "Testing should verify both the interactive and non-interactive paths work correctly:\n\n1. Unit tests:\n - Test each flag individually to ensure it correctly overrides the corresponding prompt\n - Test combinations of flags to ensure they work together properly\n - Test validation of flag values to ensure invalid values are rejected\n - Test the --non-interactive flag to ensure it fails when required values are missing\n\n2. Integration tests:\n - Test a complete initialization with all flags provided\n - Test partial initialization with some flags and some interactive prompts\n - Test initialization with no flags (fully interactive)\n\n3. Manual testing scenarios:\n - Run 'task-master init --project-name=\"Test Project\" --ai-provider=\"openai\"' and verify it skips those prompts\n - Run 'task-master init --help' and verify all flags are documented\n - Run 'task-master init --non-interactive' without required flags and verify it fails with a helpful error message\n - Run a complete non-interactive initialization and verify the resulting configuration file matches expectations\n\nEnsure the command's documentation is updated to reflect the new functionality, and verify that the help text accurately describes all available options."
},
{
"id": 32,
"title": "Implement 'learn' Command for Automatic Cursor Rule Generation",
"description": "Create a new 'learn' command that analyzes code changes and chat history to automatically generate or update Cursor rules in the .cursor/rules directory based on successful implementation patterns.",
"status": "pending",
"dependencies": [],
"priority": "high",
"details": "Implement a new command in the task-master CLI that enables Cursor to learn from successful coding patterns:\n\n1. Create a new module `commands/learn.js` that implements the command logic\n2. Update `index.js` to register the new command\n3. The command should:\n - Accept an optional parameter for specifying which patterns to focus on\n - Use git diff to extract code changes since the last commit\n - Access the Cursor chat history if possible (investigate API or file storage location)\n - Call Claude via ai-services.js with the following context:\n * Code diffs\n * Chat history excerpts showing challenges and solutions\n * Existing rules from .cursor/rules if present\n - Parse Claude's response to extract rule definitions\n - Create or update .mdc files in the .cursor/rules directory\n - Provide a summary of what was learned and which rules were updated\n\n4. Create helper functions to:\n - Extract relevant patterns from diffs\n - Format the prompt for Claude to focus on identifying reusable patterns\n - Parse Claude's response into valid rule definitions\n - Handle rule conflicts or duplications\n\n5. Ensure the command handles errors gracefully, especially if chat history is inaccessible\n6. Add appropriate logging to show the learning process\n7. Document the command in the README.md file",
"testStrategy": "1. Unit tests:\n - Create tests for each helper function in isolation\n - Mock git diff responses and chat history data\n - Verify rule extraction logic works with different input patterns\n - Test error handling for various failure scenarios\n\n2. Integration tests:\n - Test the command in a repository with actual code changes\n - Verify it correctly generates .mdc files in the .cursor/rules directory\n - Check that generated rules follow the correct format\n - Verify the command correctly updates existing rules without losing custom modifications\n\n3. Manual testing scenarios:\n - Run the command after implementing a feature with specific patterns\n - Verify the generated rules capture the intended patterns\n - Test the command with and without existing rules\n - Verify the command works when chat history is available and when it isn't\n - Test with large diffs to ensure performance remains acceptable\n\n4. Validation:\n - After generating rules, use them in Cursor to verify they correctly guide future implementations\n - Have multiple team members test the command to ensure consistent results"
},
{
"id": 33,
"title": "Create and Integrate Windsurf Rules Document from MDC Files",
"description": "Develop functionality to generate a .windsurfrules document by combining and refactoring content from three primary .mdc files used for Cursor Rules, ensuring it's properly integrated into the initialization pipeline.",
"status": "done",
"dependencies": [],
"priority": "medium",
"details": "This task involves creating a mechanism to generate a Windsurf-specific rules document by combining three existing MDC (Markdown Content) files that are currently used for Cursor Rules. The implementation should:\n\n1. Identify and locate the three primary .mdc files used for Cursor Rules\n2. Extract content from these files and merge them into a single document\n3. Refactor the content to make it Windsurf-specific, replacing Cursor-specific terminology and adapting guidelines as needed\n4. Create a function that generates a .windsurfrules document from this content\n5. Integrate this function into the initialization pipeline\n6. Implement logic to check if a .windsurfrules document already exists:\n - If it exists, append the new content to it\n - If it doesn't exist, create a new document\n7. Ensure proper error handling for file operations\n8. Add appropriate logging to track the generation and modification of the .windsurfrules document\n\nThe implementation should be modular and maintainable, with clear separation of concerns between content extraction, refactoring, and file operations.",
"testStrategy": "Testing should verify both the content generation and the integration with the initialization pipeline:\n\n1. Unit Tests:\n - Test the content extraction function with mock .mdc files\n - Test the content refactoring function to ensure Cursor-specific terms are properly replaced\n - Test the file operation functions with mock filesystem\n\n2. Integration Tests:\n - Test the creation of a new .windsurfrules document when none exists\n - Test appending to an existing .windsurfrules document\n - Test the complete initialization pipeline with the new functionality\n\n3. Manual Verification:\n - Inspect the generated .windsurfrules document to ensure content is properly combined and refactored\n - Verify that Cursor-specific terminology has been replaced with Windsurf-specific terminology\n - Run the initialization process multiple times to verify idempotence (content isn't duplicated on multiple runs)\n\n4. Edge Cases:\n - Test with missing or corrupted .mdc files\n - Test with an existing but empty .windsurfrules document\n - Test with an existing .windsurfrules document that already contains some of the content"
}
]
}