Refactor: Modularize Task Master CLI into Modules Directory
Simplified the Task Master CLI by organizing code into modules within the directory. **Why:** - **Better Organization:** Code is now grouped by function (AI, commands, dependencies, tasks, UI, utilities). - **Easier to Maintain:** Smaller modules are simpler to update and fix. - **Scalable:** New features can be added more easily in a structured way. **What Changed:** - Moved code from single _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master file into these new modules: - : AI interactions (Claude, Perplexity) - : CLI command definitions (Commander.js) - : Task dependency handling - : Core task operations (create, list, update, etc.) - : User interface elements (display, formatting) - : Utility functions and configuration - : Exports all modules - Replaced direct use of _____ _ __ __ _ |_ _|_ _ ___| | __ | \/ | __ _ ___| |_ ___ _ __ | |/ _` / __| |/ / | |\/| |/ _` / __| __/ _ \ '__| | | (_| \__ \ < | | | | (_| \__ \ || __/ | |_|\__,_|___/_|\_\ |_| |_|\__,_|___/\__\___|_| by https://x.com/eyaltoledano ╭────────────────────────────────────────────╮ │ │ │ Version: 0.9.16 Project: Task Master │ │ │ ╰────────────────────────────────────────────╯ ╭─────────────────────╮ │ │ │ Task Master CLI │ │ │ ╰─────────────────────╯ ╭───────────────────╮ │ Task Generation │ ╰───────────────────╯ parse-prd --input=<file.txt> [--tasks=10] Generate tasks from a PRD document generate Create individual task files from tasks… ╭───────────────────╮ │ Task Management │ ╰───────────────────╯ list [--status=<status>] [--with-subtas… List all tasks with their status set-status --id=<id> --status=<status> Update task status (done, pending, etc.) update --from=<id> --prompt="<context>" Update tasks based on new requirements add-task --prompt="<text>" [--dependencies=… Add a new task using AI add-dependency --id=<id> --depends-on=<id> Add a dependency to a task remove-dependency --id=<id> --depends-on=<id> Remove a dependency from a task ╭──────────────────────────╮ │ Task Analysis & Detail │ ╰──────────────────────────╯ analyze-complexity [--research] [--threshold=5] Analyze tasks and generate expansion re… complexity-report [--file=<path>] Display the complexity analysis report expand --id=<id> [--num=5] [--research] [… Break down tasks into detailed subtasks expand --all [--force] [--research] Expand all pending tasks with subtasks clear-subtasks --id=<id> Remove subtasks from specified tasks ╭─────────────────────────────╮ │ Task Navigation & Viewing │ ╰─────────────────────────────╯ next Show the next task to work on based on … show <id> Display detailed information about a sp… ╭─────────────────────────╮ │ Dependency Management │ ╰─────────────────────────╯ validate-dependenci… Identify invalid dependencies without f… fix-dependencies Fix invalid dependencies automatically ╭─────────────────────────╮ │ Environment Variables │ ╰─────────────────────────╯ ANTHROPIC_API_KEY Your Anthropic API key Required MODEL Claude model to use Default: claude-3-7-sonn… MAX_TOKENS Maximum tokens for responses Default: 4000 TEMPERATURE Temperature for model responses Default: 0.7 PERPLEXITY_API_KEY Perplexity API key for research Optional PERPLEXITY_MODEL Perplexity model to use Default: sonar-small-onl… DEBUG Enable debug logging Default: false LOG_LEVEL Console output level (debug,info,warn,error) Default: info DEFAULT_SUBTASKS Default number of subtasks to generate Default: 3 DEFAULT_PRIORITY Default task priority Default: medium PROJECT_NAME Project name displayed in UI Default: Task Master with the global command (see ). - Updated documentation () to reflect the new command. **Benefits:** Code is now cleaner, easier to work with, and ready for future growth. Use the command (or ) to run the CLI. See for command details.
This commit is contained in:
Eyal Toledano
58
tasks/task_023.txt
Normal file
58
tasks/task_023.txt
Normal file
@@ -0,0 +1,58 @@
|
||||
# Task ID: 23
|
||||
# Title: Implement MCP (Model Context Protocol) Server Functionality for Task Master
|
||||
# Status: pending
|
||||
# Dependencies: ⏱️ 22 (pending)
|
||||
# Priority: medium
|
||||
# Description: Extend Task Master to function as an MCP server, allowing it to provide context management services to other applications following the Model Context Protocol specification.
|
||||
# Details:
|
||||
This task involves implementing the Model Context Protocol server capabilities within Task Master. The implementation should:
|
||||
|
||||
1. Create a new module `mcp-server.js` that implements the core MCP server functionality
|
||||
2. Implement the required MCP endpoints:
|
||||
- `/context` - For retrieving and updating context
|
||||
- `/models` - For listing available models
|
||||
- `/execute` - For executing operations with context
|
||||
3. Develop a context management system that can:
|
||||
- Store and retrieve context data efficiently
|
||||
- Handle context windowing and truncation when limits are reached
|
||||
- Support context metadata and tagging
|
||||
4. Add authentication and authorization mechanisms for MCP clients
|
||||
5. Implement proper error handling and response formatting according to MCP specifications
|
||||
6. Create configuration options in Task Master to enable/disable the MCP server functionality
|
||||
7. Add documentation for how to use Task Master as an MCP server
|
||||
8. Ensure the implementation is compatible with existing MCP clients
|
||||
9. Optimize for performance, especially for context retrieval operations
|
||||
10. Add logging for MCP server operations
|
||||
|
||||
The implementation should follow RESTful API design principles and should be able to handle concurrent requests from multiple clients.
|
||||
|
||||
# Test Strategy:
|
||||
Testing for the MCP server functionality should include:
|
||||
|
||||
1. Unit tests:
|
||||
- Test each MCP endpoint handler function independently
|
||||
- Verify context storage and retrieval mechanisms
|
||||
- Test authentication and authorization logic
|
||||
- Validate error handling for various failure scenarios
|
||||
|
||||
2. Integration tests:
|
||||
- Set up a test MCP server instance
|
||||
- Test complete request/response cycles for each endpoint
|
||||
- Verify context persistence across multiple requests
|
||||
- Test with various payload sizes and content types
|
||||
|
||||
3. Compatibility tests:
|
||||
- Test with existing MCP client libraries
|
||||
- Verify compliance with the MCP specification
|
||||
- Ensure backward compatibility with any MCP versions supported
|
||||
|
||||
4. Performance tests:
|
||||
- Measure response times for context operations with various context sizes
|
||||
- Test concurrent request handling
|
||||
- Verify memory usage remains within acceptable limits during extended operation
|
||||
|
||||
5. Security tests:
|
||||
- Verify authentication mechanisms cannot be bypassed
|
||||
- Test for common API vulnerabilities (injection, CSRF, etc.)
|
||||
|
||||
All tests should be automated and included in the CI/CD pipeline. Documentation should include examples of how to test the MCP server functionality manually using tools like curl or Postman.
|
||||
Reference in New Issue
Block a user