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

chore: changeset + update rules.

Browse Source
This commit is contained in:
Eyal Toledano
2025-04-03 04:09:27 -04:00
parent 1582fe32c1
commit bad16b200f
54 changed files with 1462 additions and 316 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
tasks/task_043.txt Normal file
View File

@@ -0,0 +1,46 @@
# Task ID: 43
# Title: Add Research Flag to Add-Task Command
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Implement a '--research' flag for the add-task command that enables users to automatically generate research-related subtasks when creating a new task.
# Details:
Modify the add-task command to accept a new optional flag '--research'. When this flag is provided, the system should automatically generate and attach a set of research-oriented subtasks to the newly created task. These subtasks should follow a standard research methodology structure:
1. Background Investigation: Research existing solutions and approaches
2. Requirements Analysis: Define specific requirements and constraints
3. Technology/Tool Evaluation: Compare potential technologies or tools for implementation
4. Proof of Concept: Create a minimal implementation to validate approach
5. Documentation: Document findings and recommendations
The implementation should:
- Update the command-line argument parser to recognize the new flag
- Create a dedicated function to generate the research subtasks with appropriate descriptions
- Ensure subtasks are properly linked to the parent task
- Update help documentation to explain the new flag
- Maintain backward compatibility with existing add-task functionality
The research subtasks should be customized based on the main task's title and description when possible, rather than using generic templates.
# Test Strategy:
Testing should verify both the functionality and usability of the new feature:
1. Unit tests:
- Test that the '--research' flag is properly parsed
- Verify the correct number and structure of subtasks are generated
- Ensure subtask IDs are correctly assigned and linked to the parent task
2. Integration tests:
- Create a task with the research flag and verify all subtasks appear in the task list
- Test that the research flag works with other existing flags (e.g., --priority, --depends-on)
- Verify the task and subtasks are properly saved to the storage backend
3. Manual testing:
- Run 'taskmaster add-task "Test task" --research' and verify the output
- Check that the help documentation correctly describes the new flag
- Verify the research subtasks have meaningful descriptions
- Test the command with and without the flag to ensure backward compatibility
4. Edge cases:
- Test with very short or very long task descriptions
- Verify behavior when maximum task/subtask limits are reached

50
tasks/task_044.txt Normal file
View File

@@ -0,0 +1,50 @@
# Task ID: 44
# Title: Implement Task Automation with Webhooks and Event Triggers
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Design and implement a system that allows users to automate task actions through webhooks and event triggers, enabling integration with external services and automated workflows.
# Details:
This feature will enable users to create automated workflows based on task events and external triggers. Implementation should include:
1. A webhook registration system that allows users to specify URLs to be called when specific task events occur (creation, status change, completion, etc.)
2. An event system that captures and processes all task-related events
3. A trigger definition interface where users can define conditions for automation (e.g., 'When task X is completed, create task Y')
4. Support for both incoming webhooks (external services triggering actions in Taskmaster) and outgoing webhooks (Taskmaster notifying external services)
5. A secure authentication mechanism for webhook calls
6. Rate limiting and retry logic for failed webhook deliveries
7. Integration with the existing task management system
8. Command-line interface for managing webhooks and triggers
9. Payload templating system allowing users to customize the data sent in webhooks
10. Logging system for webhook activities and failures
The implementation should be compatible with both the solo/local mode and the multiplayer/remote mode, with appropriate adaptations for each context. When operating in MCP mode, the system should leverage the MCP communication protocol implemented in Task #42.
# Test Strategy:
Testing should verify both the functionality and security of the webhook system:
1. Unit tests:
- Test webhook registration, modification, and deletion
- Verify event capturing for all task operations
- Test payload generation and templating
- Validate authentication logic
2. Integration tests:
- Set up a mock server to receive webhooks and verify payload contents
- Test the complete flow from task event to webhook delivery
- Verify rate limiting and retry behavior with intentionally failing endpoints
- Test webhook triggers creating new tasks and modifying existing ones
3. Security tests:
- Verify that authentication tokens are properly validated
- Test for potential injection vulnerabilities in webhook payloads
- Verify that sensitive information is not leaked in webhook payloads
- Test rate limiting to prevent DoS attacks
4. Mode-specific tests:
- Verify correct operation in both solo/local and multiplayer/remote modes
- Test the interaction with MCP protocol when in multiplayer mode
5. Manual verification:
- Set up integrations with common services (GitHub, Slack, etc.) to verify real-world functionality
- Verify that the CLI interface for managing webhooks works as expected

55
tasks/task_045.txt Normal file
View File

@@ -0,0 +1,55 @@
# Task ID: 45
# Title: Implement GitHub Issue Import Feature
# Status: pending
# Dependencies: None
# Priority: medium
# Description: Add a '--from-github' flag to the add-task command that accepts a GitHub issue URL and automatically generates a corresponding task with relevant details.
# Details:
Implement a new flag '--from-github' for the add-task command that allows users to create tasks directly from GitHub issues. The implementation should:
1. Accept a GitHub issue URL as an argument (e.g., 'taskmaster add-task --from-github https://github.com/owner/repo/issues/123')
2. Parse the URL to extract the repository owner, name, and issue number
3. Use the GitHub API to fetch the issue details including:
- Issue title (to be used as task title)
- Issue description (to be used as task description)
- Issue labels (to be potentially used as tags)
- Issue assignees (for reference)
- Issue status (open/closed)
4. Generate a well-formatted task with this information
5. Include a reference link back to the original GitHub issue
6. Handle authentication for private repositories using GitHub tokens from environment variables or config file
7. Implement proper error handling for:
- Invalid URLs
- Non-existent issues
- API rate limiting
- Authentication failures
- Network issues
8. Allow users to override or supplement the imported details with additional command-line arguments
9. Add appropriate documentation in help text and user guide
# Test Strategy:
Testing should cover the following scenarios:
1. Unit tests:
- Test URL parsing functionality with valid and invalid GitHub issue URLs
- Test GitHub API response parsing with mocked API responses
- Test error handling for various failure cases
2. Integration tests:
- Test with real GitHub public issues (use well-known repositories)
- Test with both open and closed issues
- Test with issues containing various elements (labels, assignees, comments)
3. Error case tests:
- Invalid URL format
- Non-existent repository
- Non-existent issue number
- API rate limit exceeded
- Authentication failures for private repos
4. End-to-end tests:
- Verify that a task created from a GitHub issue contains all expected information
- Verify that the task can be properly managed after creation
- Test the interaction with other flags and commands
Create mock GitHub API responses for testing to avoid hitting rate limits during development and testing. Use environment variables to configure test credentials if needed.

20
tasks/tasks.json
View File

@@ -2449,6 +2449,26 @@
"priority": "medium",
"details": "Modify the add-task command to accept a new optional flag '--research'. When this flag is provided, the system should automatically generate and attach a set of research-oriented subtasks to the newly created task. These subtasks should follow a standard research methodology structure:\n\n1. Background Investigation: Research existing solutions and approaches\n2. Requirements Analysis: Define specific requirements and constraints\n3. Technology/Tool Evaluation: Compare potential technologies or tools for implementation\n4. Proof of Concept: Create a minimal implementation to validate approach\n5. Documentation: Document findings and recommendations\n\nThe implementation should:\n- Update the command-line argument parser to recognize the new flag\n- Create a dedicated function to generate the research subtasks with appropriate descriptions\n- Ensure subtasks are properly linked to the parent task\n- Update help documentation to explain the new flag\n- Maintain backward compatibility with existing add-task functionality\n\nThe research subtasks should be customized based on the main task's title and description when possible, rather than using generic templates.",
"testStrategy": "Testing should verify both the functionality and usability of the new feature:\n\n1. Unit tests:\n - Test that the '--research' flag is properly parsed\n - Verify the correct number and structure of subtasks are generated\n - Ensure subtask IDs are correctly assigned and linked to the parent task\n\n2. Integration tests:\n - Create a task with the research flag and verify all subtasks appear in the task list\n - Test that the research flag works with other existing flags (e.g., --priority, --depends-on)\n - Verify the task and subtasks are properly saved to the storage backend\n\n3. Manual testing:\n - Run 'taskmaster add-task \"Test task\" --research' and verify the output\n - Check that the help documentation correctly describes the new flag\n - Verify the research subtasks have meaningful descriptions\n - Test the command with and without the flag to ensure backward compatibility\n\n4. Edge cases:\n - Test with very short or very long task descriptions\n - Verify behavior when maximum task/subtask limits are reached"
},
{
"id": 44,
"title": "Implement Task Automation with Webhooks and Event Triggers",
"description": "Design and implement a system that allows users to automate task actions through webhooks and event triggers, enabling integration with external services and automated workflows.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"details": "This feature will enable users to create automated workflows based on task events and external triggers. Implementation should include:\n\n1. A webhook registration system that allows users to specify URLs to be called when specific task events occur (creation, status change, completion, etc.)\n2. An event system that captures and processes all task-related events\n3. A trigger definition interface where users can define conditions for automation (e.g., 'When task X is completed, create task Y')\n4. Support for both incoming webhooks (external services triggering actions in Taskmaster) and outgoing webhooks (Taskmaster notifying external services)\n5. A secure authentication mechanism for webhook calls\n6. Rate limiting and retry logic for failed webhook deliveries\n7. Integration with the existing task management system\n8. Command-line interface for managing webhooks and triggers\n9. Payload templating system allowing users to customize the data sent in webhooks\n10. Logging system for webhook activities and failures\n\nThe implementation should be compatible with both the solo/local mode and the multiplayer/remote mode, with appropriate adaptations for each context. When operating in MCP mode, the system should leverage the MCP communication protocol implemented in Task #42.",
"testStrategy": "Testing should verify both the functionality and security of the webhook system:\n\n1. Unit tests:\n - Test webhook registration, modification, and deletion\n - Verify event capturing for all task operations\n - Test payload generation and templating\n - Validate authentication logic\n\n2. Integration tests:\n - Set up a mock server to receive webhooks and verify payload contents\n - Test the complete flow from task event to webhook delivery\n - Verify rate limiting and retry behavior with intentionally failing endpoints\n - Test webhook triggers creating new tasks and modifying existing ones\n\n3. Security tests:\n - Verify that authentication tokens are properly validated\n - Test for potential injection vulnerabilities in webhook payloads\n - Verify that sensitive information is not leaked in webhook payloads\n - Test rate limiting to prevent DoS attacks\n\n4. Mode-specific tests:\n - Verify correct operation in both solo/local and multiplayer/remote modes\n - Test the interaction with MCP protocol when in multiplayer mode\n\n5. Manual verification:\n - Set up integrations with common services (GitHub, Slack, etc.) to verify real-world functionality\n - Verify that the CLI interface for managing webhooks works as expected"
},
{
"id": 45,
"title": "Implement GitHub Issue Import Feature",
"description": "Add a '--from-github' flag to the add-task command that accepts a GitHub issue URL and automatically generates a corresponding task with relevant details.",
"status": "pending",
"dependencies": [],
"priority": "medium",
"details": "Implement a new flag '--from-github' for the add-task command that allows users to create tasks directly from GitHub issues. The implementation should:\n\n1. Accept a GitHub issue URL as an argument (e.g., 'taskmaster add-task --from-github https://github.com/owner/repo/issues/123')\n2. Parse the URL to extract the repository owner, name, and issue number\n3. Use the GitHub API to fetch the issue details including:\n - Issue title (to be used as task title)\n - Issue description (to be used as task description)\n - Issue labels (to be potentially used as tags)\n - Issue assignees (for reference)\n - Issue status (open/closed)\n4. Generate a well-formatted task with this information\n5. Include a reference link back to the original GitHub issue\n6. Handle authentication for private repositories using GitHub tokens from environment variables or config file\n7. Implement proper error handling for:\n - Invalid URLs\n - Non-existent issues\n - API rate limiting\n - Authentication failures\n - Network issues\n8. Allow users to override or supplement the imported details with additional command-line arguments\n9. Add appropriate documentation in help text and user guide",
"testStrategy": "Testing should cover the following scenarios:\n\n1. Unit tests:\n - Test URL parsing functionality with valid and invalid GitHub issue URLs\n - Test GitHub API response parsing with mocked API responses\n - Test error handling for various failure cases\n\n2. Integration tests:\n - Test with real GitHub public issues (use well-known repositories)\n - Test with both open and closed issues\n - Test with issues containing various elements (labels, assignees, comments)\n\n3. Error case tests:\n - Invalid URL format\n - Non-existent repository\n - Non-existent issue number\n - API rate limit exceeded\n - Authentication failures for private repos\n\n4. End-to-end tests:\n - Verify that a task created from a GitHub issue contains all expected information\n - Verify that the task can be properly managed after creation\n - Test the interaction with other flags and commands\n\nCreate mock GitHub API responses for testing to avoid hitting rate limits during development and testing. Use environment variables to configure test credentials if needed."
}
]
}