Compare commits

...

139 Commits

Author SHA1 Message Date
Ralph Khreish
879409ac66 feat: improve tm init 2025-04-16 14:51:02 +02:00
Ralph Khreish
d9296614f8 chore: fix weird bug where package.json is not upgrading its version based on current package version 2025-04-16 14:48:20 +02:00
Ralph Khreish
454a1d9d37 fix: shebang issues (#243)
Closes #241 #211 #184 #193
2025-04-16 11:06:18 +02:00
Eyal Toledano
4c57537157 Merge pull request #239 from eyaltoledano/update-task-id-desc
fix(update/update-task/update-subtask):
2025-04-16 00:42:15 -04:00
Eyal Toledano
6599cb0bf9 fix(update/update-task/update-subtask): Updates the parameter descriptions for update, update-task and update-subtask to ensure the MCP server correctly reaches for the right update command based on what is being updated -- all tasks, one task, or a subtask. 2025-04-16 00:40:32 -04:00
Ralph Khreish
48a8d952bc fix: README bug not showing precise instructions (#190) 2025-04-12 19:44:15 +02:00
Ralph Khreish
94601f1e11 Merge pull request #176 from eyaltoledano/changeset-release/main
Version Packages
2025-04-11 21:39:50 +02:00
github-actions[bot]
9f834f5a27 Version Packages 2025-04-11 19:34:07 +00:00
Eyal Toledano
f5c4eda132 Merge pull request #156 from eyaltoledano/changelog
chore: Adjusts changeset to a user-facing changelog.
2025-04-11 15:33:49 -04:00
Eyal Toledano
9122e516b6 chore: prettier formatting 2025-04-11 15:09:01 -04:00
Eyal Toledano
04de6d9698 chore: Adjusts changeset to a user-facing changelog. 2025-04-11 15:08:58 -04:00
Eyal Toledano
3530e28ee3 Merge pull request #172 from eyaltoledano/adjust-context-window
chore(ai): Reduces context window back from 128k to 64k

We'll bump it back up when the better ai model management is implemented.
2025-04-11 14:42:25 -04:00
Eyal Toledano
08f0319058 Merge pull request #177 from eyaltoledano/crunchyman/changeset.modification
chore: change changeset to minor instead of patch
2025-04-11 14:34:20 -04:00
Ralph Khreish
6f2cda0a6f chore: change changeset to minor instead of patch 2025-04-11 20:30:45 +02:00
Ralph Khreish
cb720ca298 Merge pull request #171 from eyaltoledano/next
Release 0.11.x
2025-04-11 20:14:49 +02:00
Eyal Toledano
c6b8783bce chore: clean up default env value references across the code to be consistent. 2025-04-11 13:38:12 -04:00
Eyal Toledano
9c0ed3c799 chore(ai): Reduces context window back from 128k to 64k until we decouple context windows between main and research models. 2025-04-11 13:33:02 -04:00
Ralph Khreish
d3d9dc6ebe fix: replace tool parameter inputs with root directory paths (#147)
* wip: replace tool parameter inputs with root directory paths

* fix: moved path resolving responsibility to tools

- made path in parameters to optional for AI
- internalised path resolving using session roots

* chore: update package-lock.json

* chore: fix regressions and fix CI

* fix: make projectRoot required

* fix: add-task tool

* fix: updateTask tool

* fix: remove reportProgress

* chore: cleanup

* fix: expand-task tool

* chore: remove usless logs

* fix: dependency manager logging in mcp server
2025-04-11 18:57:43 +02:00
Joe Danziger
30e6d47577 Don't add task-master-mcp to mcp.json if it already exists (#169) 2025-04-11 18:07:58 +02:00
Eyal Toledano
140bd3d265 Merge PR #165 - feat(mcp): Fix parse-prd tool path resolution
Refactors parse-prd MCP tool to properly handle project root and path resolution, fixing the 'Input file not found: /scripts/prd.txt' error.

Key changes include: Made projectRoot a required parameter, prioritized args.projectRoot over session-derived paths, added validation to prevent parsing in invalid directories (/, home dir), improved error handling with detailed messages, and added creation of output directory if needed.

This resolves issues similar to those fixed in initialize-project, where the tool was incorrectly resolving paths when session context was incomplete.

RC
2025-04-11 03:13:15 -04:00
Eyal Toledano
5ed2120ee6 feat(mcp): Fix parse-prd tool path resolution
Refactors parse-prd MCP tool to properly handle project root and path resolution, fixing the 'Input file not found: /scripts/prd.txt' error.

Key changes include: Made projectRoot a required parameter, prioritized args.projectRoot over session-derived paths, added validation to prevent parsing in invalid directories (/, home dir), improved error handling with detailed messages, and added creation of output directory if needed.

This resolves issues similar to those fixed in initialize-project, where the tool was incorrectly resolving paths when session context was incomplete.
2025-04-11 02:27:02 -04:00
Eyal Toledano
34c980ee51 Merge #164: feat(mcp): Refactor initialize_project tool for direct execution
Refactors the `initialize_project` MCP tool to call a dedicated direct function (`initializeProjectDirect`) instead of executing the CLI command. This improves reliability and aligns it with other MCP tools.

Key changes include:
- Modified `mcp-server/src/tools/initialize-project.js` to call `initializeProjectDirect`.
- Updated the tool's Zod schema to require the `projectRoot` parameter.
- Implemented `handleApiResult` for consistent MCP response formatting.
- Enhanced `mcp-server/src/core/direct-functions/initialize-project-direct.js`:
    - Prioritizes `args.projectRoot` over session-derived paths for determining the target directory.
    - Added validation to prevent initialization attempts in invalid directories (e.g., '/', home directory).
    - Forces `yes: true` when calling the core `initializeProject` function for non-interactive use.
    - Ensures `process.chdir()` targets the validated directory.
- Added more robust `isSilentMode()` checks in core modules (`utils.js`, `init.js`) to suppress console output during MCP operations.

This resolves issues where the tool previously failed due to incorrect fallback directory resolution (e.g., initializing in '/') when session context was incomplete.
2025-04-11 01:28:55 -04:00
Eyal Toledano
e88682f881 feat(mcp): Refactor initialize_project tool for direct execution
Refactors the initialize_project MCP tool to call a dedicated direct function (initializeProjectDirect) instead of executing the CLI command. This improves reliability and aligns it with other MCP tools.

Key changes include: Modified initialize-project.js to call initializeProjectDirect, required projectRoot parameter, implemented handleApiResult for MCP response formatting, enhanced direct function to prioritize args.projectRoot over session-derived paths, added validation to prevent initialization in invalid directories, forces yes:true for non-interactive use, ensures process.chdir() targets validated directory, and added isSilentMode() checks to suppress console output during MCP operations.

This resolves issues where the tool previously failed due to incorrect fallback directory resolution when session context was incomplete.
2025-04-11 01:16:32 -04:00
Eyal Toledano
59208ab7a9 chore(rules): Adjusts rules to capture new init.js behaviour. 2025-04-10 22:34:51 -04:00
Eyal Toledano
a86e9affc5 refactor(init): Fix init command execution and argument handling
Centralizes init command logic within the main CLI structure. The action handler in commands.js now directly calls initializeProject from the init.js module, resolving issues with argument parsing (like -y) and removing the need for the separate bin/task-master-init.js executable. Updates package.json and bin/task-master.js accordingly.
2025-04-10 22:32:08 -04:00
Eyal Toledano
6403e96ef9 Merge pull request #154 from eyaltoledano/issue-templates
Update issue templates
2025-04-10 02:29:14 -04:00
Eyal Toledano
51919950f1 Update issue templates 2025-04-10 02:26:42 -04:00
Eyal Toledano
39efd11979 Merge pull request #150 from eyaltoledano/analyze-complexity-threshold
fix(analyze-complexity): fix threshold parameter validation and testing
Change threshold parameter in analyze_project_complexity from union type to coerce.number with min/max validation. Fix Invalid type error that occurred with certain input formats. Add test implementation to avoid real API calls and proper tests for parameter validation.
2025-04-09 21:29:09 -04:00
Eyal Toledano
65e7886506 fix: threshold parameter validation in analyze-complexity
Change threshold parameter in analyze_project_complexity from union type to coerce.number with min/max validation. Fix Invalid type error that occurred with certain input formats. Add test implementation to avoid real API calls and proper tests for parameter validation.
2025-04-09 21:25:21 -04:00
Eyal Toledano
b8e55dd612 Merge pull request #149 from eyaltoledano/initialize-next-steps
- feat(mcp): Add next_step guidance to initialize-project and add tests
- chore: removes unnecessary output from the createcontentResponse of initialize-project
- fix: Update fileValidator in parse-prd test to return boolean values
- chore: Adjust next_step information to mention: 'Before creating the PRD for the user, make sure you understand the idea fully and ask questions to eliminate ambiguity'
- feat(parse-prd): Improves the numTasks param description to encourage the LLM agent to use a number of tasks to break down the PRD into that is logical relative to project complexity
2025-04-09 21:20:54 -04:00
Eyal Toledano
819fc5d2f7 chore: changeset. 2025-04-09 21:18:50 -04:00
Eyal Toledano
6ec892b2c1 feat(parse-prd): Improves the numTasks param description to encourage the LLM agent to use a number of tasks to break down the PRD into that is logical relative to project complexity. 2025-04-09 21:17:02 -04:00
Eyal Toledano
08589b2796 chore: prettier formatting 2025-04-09 20:05:18 -04:00
Eyal Toledano
d2a5f0e6a9 chore: Adjust next_step information to mention: 'Before creating the PRD for the user, make sure you understand the idea fully and ask questions to eliminate ambiguity' 2025-04-09 20:03:32 -04:00
Eyal Toledano
e1e3e31998 chore: prettier formatting. 2025-04-09 19:50:27 -04:00
Eyal Toledano
c414d50bdf fix: Update fileValidator in parse-prd test to return boolean values 2025-04-09 19:49:51 -04:00
Eyal Toledano
2c63742a85 chore: prettier formatting. 2025-04-09 19:23:31 -04:00
Eyal Toledano
729e033fef chore: removes unnecessary output from the createcontentResponse of initialize-project. 2025-04-09 19:21:07 -04:00
Eyal Toledano
69e0b3c393 feat(mcp): Add next_step guidance to initialize-project and add tests
Added detailed next_step guidance to the initialize-project MCP tool response,
providing clear instructions about creating a PRD file and using parse-prd
after initialization. This helps users understand the workflow better after
project initialization.

Also added comprehensive unit tests for the initialize-project MCP tool that:
- Verify tool registration with correct parameters
- Test command construction with proper argument formatting
- Check special character escaping in command arguments
- Validate success response formatting including the new next_step field
- Test error handling and fallback mechanisms
- Verify logging behavior

The tests follow the same pattern as other MCP tool tests in the codebase.
2025-04-09 18:45:38 -04:00
Eyal Toledano
da95466ee1 Merge pull request #146 from eyaltoledano/add-task-manual-flags
fix(commands): implement manual creation mode for add-task command
- Add support for --title/-t and --description/-d flags in add-task command
- Fix validation for manual creation mode (title + description)
- Implement proper testing for both prompt and manual creation modes
- Update testing documentation with Commander.js testing best practices
- Add guidance on handling variable hoisting and module initialization issues
- Fully tested, all green

Changeset: brave-doors-open.md
2025-04-09 18:27:09 -04:00
Eyal Toledano
4f68bf3b47 chore: prettier formatting 2025-04-09 18:20:47 -04:00
Eyal Toledano
12519946b4 fix(commands): implement manual creation mode for add-task command
- Add support for --title/-t and --description/-d flags in add-task command
- Fix validation for manual creation mode (title + description)
- Implement proper testing for both prompt and manual creation modes
- Update testing documentation with Commander.js testing best practices
- Add guidance on handling variable hoisting and module initialization issues

Changeset: brave-doors-open.md
2025-04-09 18:18:13 -04:00
Eyal Toledano
709ea63350 fix(add-task): sets up test and new test rules for the fix for add-task to support flags for manually setting title and subtitle (stashed, next commit) 2025-04-09 16:29:24 -04:00
Eyal Toledano
ca3d54f7d6 Merge pull request #144 from eyaltoledano/rules-adjust-post-init
Rules adjust post init
2025-04-09 15:13:53 -04:00
Eyal Toledano
8c5d609c9c chore(rules): Adjusts the taskmaster.mdc rules for init and parse-prd so the LLM correctly reaches for the next steps rather than trying to reinitialize or access tasks not yet created until PRD has been parsed. 2025-04-09 15:11:59 -04:00
Ralph Khreish
b78535ac19 fix: adjust mcp to always use absolute path in description (#143) 2025-04-09 20:52:29 +02:00
Ralph Khreish
cfe3ba91e8 fix: MCP config and commands (#141) 2025-04-09 20:01:27 +02:00
Eyal Toledano
34501878b2 Merge pull request #130 from eyaltoledano/expand-all-bug
fix(expand-all): resolve NaN errors and improve error reporting
2025-04-09 12:01:07 -04:00
Ralph Khreish
af9421b9ae chore: add contributors section (#134) 2025-04-09 14:25:59 +02:00
Ralph Khreish
42bf897f81 fix: Remove fallback subtasks in parseSubtasksFromText to properly throw errors on invalid input 2025-04-09 10:22:16 +02:00
Ralph Khreish
5e01399dca chore: run formatting on codebase to pass CI 2025-04-09 10:07:49 +02:00
Eyal Toledano
e6fe5dac85 fix: Remove task-master-ai as a dependency from the package.json generated during init (#129)
Co-authored-by: Eyal Toledano <eyal@microangel.so>
2025-04-09 10:06:40 +02:00
Ralph Khreish
66f16870c6 chore: add extension recommendations to codebase 2025-04-09 10:05:58 +02:00
Eyal Toledano
01a5be25a8 fix(expand-all): resolve NaN errors and improve error reporting
- Fix expand-all command bugs that caused NaN errors with --all option and JSON formatting errors with research enabled

- Improve error handling to provide clear feedback when subtask generation fails

- Include task IDs and actionable suggestions in error messages
2025-04-09 01:24:14 -04:00
Ralph Khreish
4386e74ed2 Update README.md 2025-04-09 00:51:21 +02:00
Ralph Khreish
5d3d66ee64 chore: remove newline in readme 2025-04-09 00:50:56 +02:00
Ralph Khreish
bf38baf858 chore: remove license duplicate 2025-04-09 00:46:00 +02:00
Ralph Khreish
ab6746a0c0 chore: add prettier package 2025-04-09 00:30:05 +02:00
Ralph Khreish
c02483bc41 chore: run npm run format 2025-04-09 00:30:05 +02:00
Ralph Khreish
3148b57f1b chore: add prettier config 2025-04-09 00:30:05 +02:00
Ralph Khreish
47b79c0e29 chore: revamp README (#126) 2025-04-09 00:16:43 +02:00
Eyal Toledano
0dfecec1b3 Merge pull request #71 from eyaltoledano/23.16-23.30
23.16 23.30
2025-04-08 17:05:00 -04:00
Eyal Toledano
4386d01bf1 chore: makes tests pass. 2025-04-08 17:02:09 -04:00
Eyal Toledano
9a66db0309 docs: update changeset with model config while preserving existing changes 2025-04-08 15:55:22 -04:00
Eyal Toledano
b7580e038d Recovers lost files and commits work from the past 5-6 days. Holy shit that was a close call. 2025-04-08 15:55:22 -04:00
Eyal Toledano
b3e7ebefd9 chore: adjust the setupMCPConfiguration so it adds in the new env stuff. 2025-04-08 15:55:22 -04:00
Eyal Toledano
189d9288c1 fix: Improve MCP server robustness and debugging
- Refactor  for more reliable project root detection, particularly when running within integrated environments like Cursor IDE. Includes deriving root from script path and avoiding fallback to '/'.
- Enhance error handling in :
    - Add detailed debug information (paths searched, CWD, etc.) to the error message when  is not found in the provided project root.
    - Improve clarity of error messages and potential solutions.
- Add verbose logging in  to trace session object content and the finally resolved project root path, aiding in debugging path-related issues.
- Add default values for  and  to the example  environment configuration.
2025-04-08 15:55:22 -04:00
Ralph Khreish
1a547fac91 fix(mcp): get everything working, cleanup, and test all tools 2025-04-08 15:55:22 -04:00
Ralph Khreish
3f1f96076c feat(wip): set up mcp server and tools, but mcp on cursor not working despite working in inspector 2025-04-08 15:55:22 -04:00
Eyal Toledano
0f9bc3378d git commit -m "fix: improve CLI error handling and standardize option flags
This commit fixes several issues with command line interface error handling:

   1. Fix inconsistent behavior between --no-generate and --skip-generate:
      - Standardized on --skip-generate across all commands
      - Updated bin/task-master.js to use --skip-generate instead of --no-generate
      - Modified add-subtask and remove-subtask commands to use --skip-generate

   2. Enhance error handling for unknown options:
      - Removed .allowUnknownOption() from commands to properly detect unknown options
      - Added global error handler in bin/task-master.js for unknown commands/options
      - Added command-specific error handlers with helpful error messages

   3. Improve user experience with better help messages:
      - Added helper functions to display formatted command help on errors
      - Created command-specific help displays for add-subtask and remove-subtask
      - Show available options when encountering unknown options

   4. Update MCP server configuration:
      - Modified .cursor/mcp.json to use node ./mcp-server/server.js directly
      - Removed npx -y usage for more reliable execution

   5. Other minor improvements:
      - Adjusted column width for task ID display in UI
      - Updated version number in package-lock.json to 0.9.30

   This resolves issues where users would see confusing error messages like
   'error: unknown option --generate' when using an incorrect flag."
2025-04-08 15:55:22 -04:00
Eyal Toledano
bdd582b9cb Ensures that the updateTask (single task) doesn't change the title of the task. 2025-04-08 15:55:22 -04:00
Ralph Khreish
693369128d fix(mcp): get everything working, cleanup, and test all tools 2025-04-08 15:55:22 -04:00
Ralph Khreish
2b5fab5cb5 feat(wip): set up mcp server and tools, but mcp on cursor not working despite working in inspector 2025-04-08 15:55:22 -04:00
Eyal Toledano
e6c062d061 Recovers lost files and commits work from the past 5-6 days. Holy shit that was a close call. 2025-04-08 15:55:22 -04:00
Eyal Toledano
689e2de94e Replace API keys with placeholders 2025-04-08 15:55:22 -04:00
Eyal Toledano
ab5025e204 Remove accidentally exposed keys 2025-04-08 15:55:22 -04:00
Eyal Toledano
268577fd20 feat(mcp): Refine AI-based MCP tool patterns and update MCP rules 2025-04-08 15:55:22 -04:00
Ralph Khreish
141e8a8585 fix: remove master command 2025-04-08 15:55:22 -04:00
Eyal Toledano
76ecfc086a Makes default command npx -y task-master-mcp-server 2025-04-08 15:55:22 -04:00
Eyal Toledano
33bb596c01 Supports both task-master-mcp and task-master-mcp-server commands 2025-04-08 15:55:22 -04:00
Eyal Toledano
8e478f9e5e chore: Adjusts the mcp server command from task-master-mcp-server to task-master-mcp. It cannot be simpler because global installations of the npm package would expose this as a globally available command. Calling it like 'mcp' could collide and also is lacking in branding and clarity of what command would be run. This is as good as we can make it. 2025-04-08 15:55:22 -04:00
Eyal Toledano
bad16b200f chore: changeset + update rules. 2025-04-08 15:55:22 -04:00
Eyal Toledano
1582fe32c1 chore: task mgmt 2025-04-08 15:55:22 -04:00
Eyal Toledano
87b1eb61ee chore: task mgmt 2025-04-08 15:55:20 -04:00
Eyal Toledano
f11e00a026 Changeset 2025-04-08 15:54:36 -04:00
Eyal Toledano
feddeafd6e feat: Adds initialize-project to the MCP tools to enable onboarding to Taskmaster directly from MCP only. 2025-04-08 15:54:36 -04:00
Eyal Toledano
d71e7872ea chore: adds task-master-ai to the createProjectStructure which merges/creates the package.json. This is so that onboarding via MCP is possible. When the MCP server runs and does npm i, it will get task-master, and get the ability to run task-master init. 2025-04-08 15:54:36 -04:00
Eyal Toledano
01bd121de2 chore: Adjust init with new dependencies for MCP and other missing dependencies. 2025-04-08 15:54:36 -04:00
Eyal Toledano
cdd87ccc5e feat: adds remove-task command + MCP implementation. 2025-04-08 15:54:33 -04:00
Eyal Toledano
6442bf5ee1 fix: Adjusts default temp from 0.7 down to 0.2 2025-04-08 15:54:06 -04:00
Eyal Toledano
f16a574ad8 feat: Adjustst the parsePRD system prompt and cursor rule so to improve following specific details that may already be outliend in the PRD. This reduces cases where the AI will not use those details and come up with its own approach. Next commit will reduce detfault temperature to do this at scale across the system too. 2025-04-08 15:54:06 -04:00
Eyal Toledano
6393f9f7fb chore: adjust the setupMCPConfiguration so it adds in the new env stuff. 2025-04-08 15:54:06 -04:00
Eyal Toledano
74b67830ac fix(mcp): optimize get_task response payload by removing allTasks data
- Add custom processTaskResponse function to get-task.js to filter response data
- Significantly reduce MCP response size by returning only the requested task
- Preserve allTasks in CLI/UI for dependency status formatting
- Update changeset with documentation of optimization

This change maintains backward compatibility while making MCP responses
more efficient, addressing potential context overflow issues in AI clients.
2025-04-08 15:54:06 -04:00
Eyal Toledano
a49a77d19f fix: Improve MCP server robustness and debugging
- Refactor  for more reliable project root detection, particularly when running within integrated environments like Cursor IDE. Includes deriving root from script path and avoiding fallback to '/'.
- Enhance error handling in :
    - Add detailed debug information (paths searched, CWD, etc.) to the error message when  is not found in the provided project root.
    - Improve clarity of error messages and potential solutions.
- Add verbose logging in  to trace session object content and the finally resolved project root path, aiding in debugging path-related issues.
- Add default values for  and  to the example  environment configuration.
2025-04-08 15:54:06 -04:00
Eyal Toledano
1a74b50658 docs: Update rules for MCP/CLI workflow and project root handling
Updated several Cursor rules documentation files (`mcp.mdc`, `utilities.mdc`, `architecture.mdc`, `new_features.mdc`, `commands.mdc`) to accurately reflect recent refactoring and clarify best practices.

Key documentation updates include:

- Explicitly stating the preference for using MCP tools over CLI commands in integrated environments (`commands.mdc`, `dev_workflow.mdc`).

- Describing the new standard pattern for getting the project root using `getProjectRootFromSession` within MCP tool `execute` methods (`mcp.mdc`, `utilities.mdc`, `architecture.mdc`, `new_features.mdc`).

- Clarifying the simplified role of `findTasksJsonPath` in direct functions (`mcp.mdc`, `utilities.mdc`, `architecture.mdc`, `new_features.mdc`).

- Ensuring proper interlinking between related documentation files.
2025-04-08 15:54:06 -04:00
Eyal Toledano
e04c16cec6 refactor(mcp-server): Prioritize session roots for project path discovery
This commit refactors how the MCP server determines the project root directory, prioritizing the path provided by the client session (e.g., Cursor) for increased reliability and simplification.

Previously, project root discovery relied on a complex chain of fallbacks (environment variables, CWD searching, package path checks) within `findTasksJsonPath`. This could be brittle and less accurate when running within an integrated environment like Cursor.

Key changes:

- **Prioritize Session Roots:** MCP tools (`add-task`, `add-dependency`, etc.) now first attempt to extract the project root URI directly from `session.roots[0].uri`.

- **New Utility `getProjectRootFromSession`:** Added a utility function in `mcp-server/src/tools/utils.js` to encapsulate the logic for extracting and decoding the root URI from the session object.

- **Refactor MCP Tools:** Updated tools (`add-task.js`, `add-dependency.js`) to use `getProjectRootFromSession`.

- **Simplify `findTasksJsonPath`:** Prioritized `args.projectRoot`, removed checks for `TASK_MASTER_PROJECT_ROOT` env var and package directory fallback. Retained CWD search and cache check for CLI compatibility.

- **Fix `reportProgress` Usage:** Corrected parameters in `add-dependency.js`.

This change makes project root determination more robust for the MCP server while preserving discovery mechanisms for the standalone CLI.
2025-04-08 15:54:06 -04:00
Eyal Toledano
3af469b35f feat(mcp): major MCP server improvements and documentation overhaul
- Enhance MCP server robustness and usability:
  - Implement smart project root detection with hierarchical fallbacks
  - Make projectRoot parameter optional across all MCP tools
  - Add comprehensive PROJECT_MARKERS for reliable project detection
  - Improve error messages and logging for better debugging
  - Split monolithic core into focused direct-function files

- Implement full suite of MCP commands:
  - Add task management: update-task, update-subtask, generate
  - Add task organization: expand-task, expand-all, clear-subtasks
  - Add dependency handling: add/remove/validate/fix dependencies
  - Add analysis tools: analyze-complexity, complexity-report
  - Rename commands for better API consistency (list-tasks → get-tasks)

- Enhance documentation and developer experience:
  - Create and bundle new taskmaster.mdc as comprehensive reference
  - Document all tools with natural language patterns and examples
  - Clarify project root auto-detection in documentation
  - Standardize naming conventions across MCP components
  - Add cross-references between related tools and commands

- Improve UI and progress tracking:
  - Add color-coded progress bars with status breakdown
  - Implement cancelled/deferred task status handling
  - Enhance status visualization and counting
  - Optimize display for various terminal sizes

This major update significantly improves the robustness and usability
of the MCP server while providing comprehensive documentation for both
users and developers. The changes make Task Master more intuitive to
use programmatically while maintaining full CLI functionality.
2025-04-08 15:54:06 -04:00
Eyal Toledano
d5ecca25db fix(mcp): make projectRoot optional in all MCP tools
- Update all tool definitions to use z.string().optional() for projectRoot
- Fix direct function implementations to use findTasksJsonPath(args, log) pattern
- Enables consistent project root detection without requiring explicit params
- Update changeset to document these improvements

This change ensures MCP tools work properly with the smart project root
detection system, removing the need for explicit projectRoot parameters in
client applications. Improves usability and reduces integration friction.
2025-04-08 15:54:06 -04:00
Eyal Toledano
65f56978b2 chore/doc: renames list-tasks to get-tasks and show-tasks to get-tasks in the mcp tools to follow api conventions and likely natural language used (get my tasks). also updates changeset. 2025-04-08 15:54:06 -04:00
Eyal Toledano
5e22c8b4ba chore: changesett 2025-04-08 15:54:06 -04:00
Eyal Toledano
bdd0035fc0 chore: task mgmt 2025-04-08 15:54:06 -04:00
Eyal Toledano
c98b0cea11 Adjusts the taskmaster mcp invokation command in mcp.json shipped with taskmaster init. 2025-04-08 15:54:06 -04:00
Eyal Toledano
f9ef0c1887 feat(paths): Implement robust project root detection and path utilities
Overhauls the project root detection system with a hierarchical precedence mechanism that intelligently locates tasks.json and identifies project roots. This improves user experience by reducing the need for explicit path parameters and enhances cross-platform compatibility.

Key Improvements:
- Implement hierarchical precedence for project root detection:
  * Environment variable override (TASK_MASTER_PROJECT_ROOT)
  * Explicitly provided --project-root parameter
  * Cached project root from previous successful operations
  * Current directory with project markers
  * Parent directory traversal to find tasks.json
  * Package directory as fallback

- Create comprehensive PROJECT_MARKERS detection system with 20+ common indicators:
  * Task Master specific files (tasks.json, tasks/tasks.json)
  * Version control directories (.git, .svn)
  * Package manifests (package.json, pyproject.toml, Gemfile, go.mod, Cargo.toml)
  * IDE/editor configurations (.cursor, .vscode, .idea)
  * Dependency directories (node_modules, venv, .venv)
  * Configuration files (.env, tsconfig.json, webpack.config.js)
  * CI/CD files (.github/workflows, .gitlab-ci.yml, .circleci/config.yml)

- DRY refactoring of path utilities:
  * Centralize path-related functions in core/utils/path-utils.js
  * Export PROJECT_MARKERS as a single source of truth
  * Add caching via lastFoundProjectRoot for performance optimization

- Enhanced user experience:
  * Improve error messages with specific troubleshooting guidance
  * Add detailed logging to indicate project root detection source
  * Update tool parameter descriptions for better clarity
  * Add recursive parent directory searching for tasks.json

Testing:
- Verified in local dev environment
- Added unit tests for the progress bar visualization
- Updated "automatically detected" description in MCP tools

This commit addresses Task #38: Implement robust project root handling for file paths.
2025-04-08 15:53:47 -04:00
Eyal Toledano
0e16d27294 chore: removes the optional from projectRoot. 2025-04-08 15:51:55 -04:00
Eyal Toledano
3bfbe19fe3 Enhance progress bars with status breakdown, improve readability, optimize display width, and update changeset 2025-04-08 15:51:55 -04:00
Eyal Toledano
087de784fa feat(ui): add cancelled status and improve MCP resource docs
- Add cancelled status to UI module for marking tasks cancelled without deletion
- Improve MCP server resource documentation with implementation examples
- Update architecture.mdc with detailed resource management info
- Add comprehensive resource handling guide to mcp.mdc
- Update changeset to reflect new features and documentation
- Mark task 23.6 as cancelled (MCP SDK integration no longer needed)
- Complete task 23.12 (structured logging system)
2025-04-08 15:51:55 -04:00
Eyal Toledano
f76b69c935 docs: improve MCP server resource documentation
- Update subtask 23.10 with details on resource and resource template implementation
- Add resource management section to architecture.mdc with proper directory structure
- Create comprehensive resource implementation guide in mcp.mdc with examples and best practices
- Document proper integration of resources in FastMCP server initialization
2025-04-08 15:51:55 -04:00
Eyal Toledano
6a6d06766b feat(mcp): Implement add-dependency MCP command for creating dependency relationships between tasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
9f430ca48b chore: task mgmt 2025-04-08 15:51:55 -04:00
Eyal Toledano
ca87476919 chore: task mgmt 2025-04-08 15:51:55 -04:00
Eyal Toledano
fec9e12f49 feat(mcp): Implement complexity-report MCP command for displaying task complexity analysis reports 2025-04-08 15:51:55 -04:00
Eyal Toledano
d06e45bf12 Implement fix-dependencies MCP command for automatically fixing invalid dependencies 2025-04-08 15:51:55 -04:00
Eyal Toledano
535fb5be71 Implement validate-dependencies MCP command for checking dependency validity 2025-04-08 15:51:55 -04:00
Eyal Toledano
fba6131db7 Implement remove-dependency MCP command for removing dependencies from tasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
7f0cdf9046 chore: task mgmt 2025-04-08 15:51:55 -04:00
Eyal Toledano
eecad5bfe0 chore: task mgmt 2025-04-08 15:51:55 -04:00
Eyal Toledano
fb4a8b6cb7 feat(ui): add color-coded progress bar to task show view for visualizing subtask completion status 2025-04-08 15:51:55 -04:00
Eyal Toledano
00e01d1d93 Implement expand-all MCP command for expanding all pending tasks with subtasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
995e95263c Implement clear-subtasks MCP command for clearing subtasks from parent tasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
0b7b395aa4 Implement analyze-complexity MCP command for analyzing task complexity 2025-04-08 15:51:55 -04:00
Eyal Toledano
1679075b6b Implement remove-subtask MCP command for removing subtasks from parent tasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
1908c4a337 Implement add-subtask MCP command for adding subtasks to existing tasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
43022d7010 feat: implement add-task MCP command
- Create direct function wrapper in add-task.js with prompt and dependency handling

- Add MCP tool integration for creating new tasks via AI

- Update task-master-core.js to expose addTaskDirect function

- Update changeset to document the new command
2025-04-08 15:51:55 -04:00
Eyal Toledano
04c2dee593 chore: uncomments the addResource and addResourceTemplate calls in the index.js for MCP. TODO: Figure out the project roots so we can do this on other projects vs just our own. 2025-04-08 15:51:55 -04:00
Eyal Toledano
d0092a6e6f feat: implement expand-task MCP command
- Create direct function wrapper in expand-task.js with error handling

- Add MCP tool integration for breaking down tasks into subtasks

- Update task-master-core.js to expose expandTaskDirect function

- Update changeset to document the new command

- Parameter support for subtask generation options (num, research, prompt, force)
2025-04-08 15:51:55 -04:00
Eyal Toledano
729ae4d2d5 feat: implement next-task MCP command
- Create direct function wrapper in next-task.js with error handling and caching

- Add MCP tool integration for finding the next task to work on

- Update task-master-core.js to expose nextTaskDirect function

- Update changeset to document the new command
2025-04-08 15:51:55 -04:00
Eyal Toledano
219b40b516 chore: task mgmt 2025-04-08 15:51:55 -04:00
Eyal Toledano
05950ef318 feat: implement show-task MCP command
- Create direct function wrapper in show-task.js with error handling and caching

- Add MCP tool integration for displaying detailed task information

- Update task-master-core.js to expose showTaskDirect function

- Update changeset to document the new command

- Follow kebab-case/camelCase/snake_case naming conventions
2025-04-08 15:51:55 -04:00
Eyal Toledano
9582c0a91f docs: document MCP server naming conventions and implement set-status
- Update architecture.mdc with file/function naming standards for MCP server components

- Update mcp.mdc with detailed naming conventions section

- Update task 23 to include naming convention details

- Update changeset to capture documentation changes

- Rename MCP tool files to follow kebab-case convention

- Implement set-task-status MCP command
2025-04-08 15:51:55 -04:00
Eyal Toledano
6d01ae3d47 feat: implement set-status MCP command and update changeset 2025-04-08 15:51:55 -04:00
Eyal Toledano
d4f92858c2 feat(mcp): Implement generate MCP command for creating task files from tasks.json 2025-04-08 15:51:55 -04:00
Eyal Toledano
e02ee96aff feat(mcp): Implement update-subtask MCP command for appending information to subtasks 2025-04-08 15:51:55 -04:00
Eyal Toledano
38f9e4deaa feat(mcp): Implement update-task MCP command for updating single tasks by ID with proper direct function wrapper, MCP tool implementation, and registration 2025-04-08 15:51:55 -04:00
Eyal Toledano
71410629ba refactor(mcp): Modularize direct functions in MCP server
Split monolithic task-master-core.js into separate function files within
the mcp-server/src/core/direct-functions/ directory. This change:

- Creates individual files for each direct function implementation
- Moves findTasksJsonPath to a dedicated utils/path-utils.js file
- Converts task-master-core.js to be a simple import/export hub
- Improves maintainability and organization of the codebase
- Reduces potential merge conflicts when multiple developers contribute
- Follows standard module separation patterns

Each function is now in its own self-contained file with clear imports and
focused responsibility, while maintaining the same API endpoints.
2025-04-08 15:51:55 -04:00
Eyal Toledano
450549d875 Adds update direct function into MCP. 2025-04-08 15:51:55 -04:00
Eyal Toledano
a49f5a117b chore: adds changeset.mdc to help agent automatically trigger changeset command with contextual information based on how we want to use it. not to be called for internal dev stuff. 2025-04-08 15:51:55 -04:00
Eyal Toledano
bc9707f813 refactor(mcp): Remove unused executeMCPToolAction utility
The  function aimed to abstract the common flow within MCP tool  methods (logging, calling direct function, handling result).

However, the established pattern (e.g., in ) involves the  method directly calling the  function (which handles its own caching via ) and then passing the result to . This pattern is clear, functional, and leverages the core utilities effectively.

Removing the unused  simplifies , eliminates a redundant abstraction layer, and clarifies the standard implementation pattern for MCP tools.
2025-04-08 15:51:55 -04:00
Ralph Khreish
a56a3628b3 CHORE: Add CI for making sure PRs don't break things (#89)
* fix: add CI for better control of regressions during PRs

* fix: slight readme improvement

* chore: fix CI

* cleanup

* fix: duplicate workflow trigger
2025-04-03 16:01:58 +02:00
Ralph Khreish
9dc5e75760 Revert "Update analyze-complexity with realtime feedback and enhanced complex…"
This reverts commit 16f4d4b932.
2025-04-02 19:28:01 +02:00
184 changed files with 50431 additions and 27232 deletions

View File

@@ -0,0 +1,6 @@
---
'task-master-ai': patch
---
- Fixes shebang issue not allowing task-master to run on certain windows operating systems
- Resolves #241 #211 #184 #193

View File

@@ -0,0 +1,5 @@
---
'task-master-ai': patch
---
Updates the parameter descriptions for update, update-task and update-subtask to ensure the MCP server correctly reaches for the right update command based on what is being updated -- all tasks, one task, or a subtask.

View File

@@ -1,5 +0,0 @@
---
"task-master-ai": minor
---
Improve analyze-complexity UI with realtime feedback.

View File

@@ -0,0 +1,6 @@
---
'task-master-ai': patch
---
- Fix `task-master init` polluting codebase with new packages inside `package.json` and modifying project `README`
- Now only initializes with cursor rules, windsurf rules, mcp.json, scripts/example_prd.txt, .gitignore modifications, and `README-task-master.md`

View File

@@ -1,5 +0,0 @@
---
"task-master-ai": patch
---
Fix github actions creating npm releases on next branch push

View File

@@ -2,9 +2,17 @@
"mcpServers": {
"taskmaster-ai": {
"command": "node",
"args": [
"./mcp-server/server.js"
]
"args": ["./mcp-server/server.js"],
"env": {
"ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
"PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
"MODEL": "claude-3-7-sonnet-20250219",
"PERPLEXITY_MODEL": "sonar-pro",
"MAX_TOKENS": 64000,
"TEMPERATURE": 0.2,
"DEFAULT_SUBTASKS": 5,
"DEFAULT_PRIORITY": "medium"
}
}
}
}

View File

@@ -14,13 +14,13 @@ alwaysApply: false
- **Purpose**: Defines and registers all CLI commands using Commander.js.
- **Responsibilities** (See also: [`commands.mdc`](mdc:.cursor/rules/commands.mdc)):
- Parses command-line arguments and options.
- Invokes appropriate functions from other modules to execute commands.
- Invokes appropriate functions from other modules to execute commands (e.g., calls `initializeProject` from `init.js` for the `init` command).
- Handles user input and output related to command execution.
- Implements input validation and error handling for CLI commands.
- **Key Components**:
- `programInstance` (Commander.js `Command` instance): Manages command definitions.
- `registerCommands(programInstance)`: Function to register all application commands.
- Command action handlers: Functions executed when a specific command is invoked.
- Command action handlers: Functions executed when a specific command is invoked, delegating to core modules.
- **[`task-manager.js`](mdc:scripts/modules/task-manager.js): Task Data Management**
- **Purpose**: Manages task data, including loading, saving, creating, updating, deleting, and querying tasks.
@@ -85,7 +85,7 @@ alwaysApply: false
- `parsePRDWithAI(prdContent)`: Extracts tasks from PRD content using AI.
- **[`utils.js`](mdc:scripts/modules/utils.js): Utility Functions and Configuration**
- **Purpose**: Provides reusable utility functions and global configuration settings used across the application.
- **Purpose**: Provides reusable utility functions and global configuration settings used across the **CLI application**.
- **Responsibilities** (See also: [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)):
- Manages global configuration settings loaded from environment variables and defaults.
- Implements logging utility with different log levels and output formatting.
@@ -93,6 +93,7 @@ alwaysApply: false
- Includes string manipulation utilities (e.g., `truncate`, `sanitizePrompt`).
- Offers task-specific utility functions (e.g., `formatTaskId`, `findTaskById`, `taskExists`).
- Implements graph algorithms like cycle detection for dependency management.
- **Silent Mode Control**: Provides `enableSilentMode` and `disableSilentMode` functions to control log output.
- **Key Components**:
- `CONFIG`: Global configuration object.
- `log(level, ...args)`: Logging function.
@@ -100,28 +101,181 @@ alwaysApply: false
- `truncate(text, maxLength)`: String truncation utility.
- `formatTaskId(id)` / `findTaskById(tasks, taskId)`: Task ID and search utilities.
- `findCycles(subtaskId, dependencyMap)`: Cycle detection algorithm.
- `enableSilentMode()` / `disableSilentMode()`: Control console logging output.
- **[`mcp-server/`](mdc:mcp-server/): MCP Server Integration**
- **Purpose**: Provides an MCP (Model Context Protocol) interface for Task Master, allowing integration with external tools like Cursor. Uses FastMCP framework.
- **Responsibilities** (See also: [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)):
- Registers Task Master functionalities as tools consumable via MCP.
- Handles MCP requests and translates them into calls to the Task Master core logic.
- Prefers direct function calls to core modules via [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js) for performance.
- Uses CLI execution via `executeTaskMasterCommand` as a fallback.
- **Implements Caching**: Utilizes a caching layer (`ContextManager` with `lru-cache`) invoked via `getCachedOrExecute` within direct function wrappers ([`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js)) to optimize performance for specific read operations (e.g., listing tasks).
- Standardizes response formatting for MCP clients using utilities in [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
- Handles MCP requests via tool `execute` methods defined in `mcp-server/src/tools/*.js`.
- Tool `execute` methods call corresponding **direct function wrappers**.
- Tool `execute` methods use `getProjectRootFromSession` (from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js)) to determine the project root from the client session and pass it to the direct function.
- **Direct function wrappers (`*Direct` functions in `mcp-server/src/core/direct-functions/*.js`) contain the main logic for handling MCP requests**, including path resolution, argument validation, caching, and calling core Task Master functions.
- Direct functions use `findTasksJsonPath` (from [`core/utils/path-utils.js`](mdc:mcp-server/src/core/utils/path-utils.js)) to locate `tasks.json` based on the provided `projectRoot`.
- **Silent Mode Implementation**: Direct functions use `enableSilentMode` and `disableSilentMode` to prevent logs from interfering with JSON responses.
- **Async Operations**: Uses `AsyncOperationManager` to handle long-running operations in the background.
- **Project Initialization**: Provides `initialize_project` command for setting up new projects from within integrated clients.
- Tool `execute` methods use `handleApiResult` from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) to process the result from the direct function and format the final MCP response.
- Uses CLI execution via `executeTaskMasterCommand` as a fallback only when necessary.
- **Implements Robust Path Finding**: The utility [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) (specifically `getProjectRootFromSession`) and [`core/utils/path-utils.js`](mdc:mcp-server/src/core/utils/path-utils.js) (specifically `findTasksJsonPath`) work together. The tool gets the root via session, passes it to the direct function, which uses `findTasksJsonPath` to locate the specific `tasks.json` file within that root.
- **Implements Caching**: Utilizes a caching layer (`ContextManager` with `lru-cache`). Caching logic is invoked *within* the direct function wrappers using the `getCachedOrExecute` utility for performance-sensitive read operations.
- Standardizes response formatting and data filtering using utilities in [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
- **Resource Management**: Provides access to static and dynamic resources.
- **Key Components**:
- `mcp-server/src/index.js`: Main server class definition with FastMCP initialization, resource registration, and server lifecycle management.
- `mcp-server/src/server.js`: Main server setup and initialization.
- `mcp-server/src/tools/`: Directory containing individual tool definitions, each registering a specific Task Master command for MCP.
- `mcp-server/src/tools/`: Directory containing individual tool definitions. Each tool's `execute` method orchestrates the call to core logic and handles the response.
- `mcp-server/src/tools/utils.js`: Provides MCP-specific utilities like `handleApiResult`, `processMCPResponseData`, `getCachedOrExecute`, and **`getProjectRootFromSession`**.
- `mcp-server/src/core/utils/`: Directory containing utility functions specific to the MCP server, like **`path-utils.js` for resolving `tasks.json` within a given root** and **`async-manager.js` for handling background operations**.
- `mcp-server/src/core/direct-functions/`: Directory containing individual files for each **direct function wrapper (`*Direct`)**. These files contain the primary logic for MCP tool execution.
- `mcp-server/src/core/resources/`: Directory containing resource handlers for task templates, workflow definitions, and other static/dynamic data exposed to LLM clients.
- [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js): Acts as an import/export hub, collecting and exporting direct functions from the `direct-functions` directory and MCP utility functions.
- **Naming Conventions**:
- **Files** use **kebab-case**: `list-tasks.js`, `set-task-status.js`, `parse-prd.js`
- **Direct Functions** use **camelCase** with `Direct` suffix: `listTasksDirect`, `setTaskStatusDirect`, `parsePRDDirect`
- **Tool Registration Functions** use **camelCase** with `Tool` suffix: `registerListTasksTool`, `registerSetTaskStatusTool`
- **MCP Tool Names** use **snake_case**: `list_tasks`, `set_task_status`, `parse_prd_document`
- **Resource Handlers** use **camelCase** with pattern URI: `@mcp.resource("tasks://templates/{template_id}")`
- **AsyncOperationManager**:
- **Purpose**: Manages background execution of long-running operations.
- **Location**: `mcp-server/src/core/utils/async-manager.js`
- **Key Features**:
- Operation tracking with unique IDs using UUID
- Status management (pending, running, completed, failed)
- Progress reporting forwarded from background tasks
- Operation history with automatic cleanup of completed operations
- Context preservation (log, session, reportProgress)
- Robust error handling for background tasks
- **Usage**: Used for CPU-intensive operations like task expansion and PRD parsing
- **[`init.js`](mdc:scripts/init.js): Project Initialization Logic**
- **Purpose**: Contains the core logic for setting up a new Task Master project structure.
- **Responsibilities**:
- Creates necessary directories (`.cursor/rules`, `scripts`, `tasks`).
- Copies template files (`.env.example`, `.gitignore`, rule files, `dev.js`, etc.).
- Creates or merges `package.json` with required dependencies and scripts.
- Sets up MCP configuration (`.cursor/mcp.json`).
- Optionally initializes a git repository and installs dependencies.
- Handles user prompts for project details *if* called without skip flags (`-y`).
- **Key Function**:
- `initializeProject(options)`: The main function exported and called by the `init` command's action handler in [`commands.js`](mdc:scripts/modules/commands.js). It receives parsed options directly.
- **Note**: This script is used as a module and no longer handles its own argument parsing or direct execution via a separate `bin` file.
- **Data Flow and Module Dependencies**:
- **Commands Initiate Actions**: User commands entered via the CLI (handled by [`commands.js`](mdc:scripts/modules/commands.js)) are the entry points for most operations.
- **Command Handlers Delegate to Managers**: Command handlers in [`commands.js`](mdc:scripts/modules/commands.js) call functions in [`task-manager.js`](mdc:scripts/modules/task-manager.js) and [`dependency-manager.js`](mdc:scripts/modules/dependency-manager.js) to perform core task and dependency management logic.
- **Commands Initiate Actions**: User commands entered via the CLI (parsed by `commander` based on definitions in [`commands.js`](mdc:scripts/modules/commands.js)) are the entry points for most operations.
- **Command Handlers Delegate to Core Logic**: Action handlers within [`commands.js`](mdc:scripts/modules/commands.js) call functions in core modules like [`task-manager.js`](mdc:scripts/modules/task-manager.js), [`dependency-manager.js`](mdc:scripts/modules/dependency-manager.js), and [`init.js`](mdc:scripts/init.js) (for the `init` command) to perform the actual work.
- **UI for Presentation**: [`ui.js`](mdc:scripts/modules/ui.js) is used by command handlers and task/dependency managers to display information to the user. UI functions primarily consume data and format it for output, without modifying core application state.
- **Utilities for Common Tasks**: [`utils.js`](mdc:scripts/modules/utils.js) provides helper functions used by all other modules for configuration, logging, file operations, and common data manipulations.
- **AI Services Integration**: AI functionalities (complexity analysis, task expansion, PRD parsing) are invoked from [`task-manager.js`](mdc:scripts/modules/task-manager.js) and potentially [`commands.js`](mdc:scripts/modules/commands.js), likely using functions that would reside in a dedicated `ai-services.js` module or be integrated within `utils.js` or `task-manager.js`.
- **MCP Server Interaction**: External tools interact with the `mcp-server`, which then calls direct function wrappers in `task-master-core.js` or falls back to `executeTaskMasterCommand`. Responses are formatted by `mcp-server/src/tools/utils.js`. See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details.
- **MCP Server Interaction**: External tools interact with the `mcp-server`. MCP Tool `execute` methods use `getProjectRootFromSession` to find the project root, then call direct function wrappers (in `mcp-server/src/core/direct-functions/`) passing the root in `args`. These wrappers handle path finding for `tasks.json` (using `path-utils.js`), validation, caching, call the core logic from `scripts/modules/` (passing logging context via the standard wrapper pattern detailed in mcp.mdc), and return a standardized result. The final MCP response is formatted by `mcp-server/src/tools/utils.js`. See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details.
## Silent Mode Implementation Pattern in MCP Direct Functions
Direct functions (the `*Direct` functions in `mcp-server/src/core/direct-functions/`) need to carefully implement silent mode to prevent console logs from interfering with the structured JSON responses required by MCP. This involves both using `enableSilentMode`/`disableSilentMode` around core function calls AND passing the MCP logger via the standard wrapper pattern (see mcp.mdc). Here's the standard pattern for correct implementation:
1. **Import Silent Mode Utilities**:
```javascript
import { enableSilentMode, disableSilentMode, isSilentMode } from '../../../../scripts/modules/utils.js';
```
2. **Parameter Matching with Core Functions**:
- ✅ **DO**: Ensure direct function parameters match the core function parameters
- ✅ **DO**: Check the original core function signature before implementing
- ❌ **DON'T**: Add parameters to direct functions that don't exist in core functions
```javascript
// Example: Core function signature
// async function expandTask(tasksPath, taskId, numSubtasks, useResearch, additionalContext, options)
// Direct function implementation - extract only parameters that exist in core
export async function expandTaskDirect(args, log, context = {}) {
// Extract parameters that match the core function
const taskId = parseInt(args.id, 10);
const numSubtasks = args.num ? parseInt(args.num, 10) : undefined;
const useResearch = args.research === true;
const additionalContext = args.prompt || '';
// Later pass these parameters in the correct order to the core function
const result = await expandTask(
tasksPath,
taskId,
numSubtasks,
useResearch,
additionalContext,
{ mcpLog: log, session: context.session }
);
}
```
3. **Checking Silent Mode State**:
- ✅ **DO**: Always use `isSilentMode()` function to check current status
- ❌ **DON'T**: Directly access the global `silentMode` variable or `global.silentMode`
```javascript
// CORRECT: Use the function to check current state
if (!isSilentMode()) {
// Only create a loading indicator if not in silent mode
loadingIndicator = startLoadingIndicator('Processing...');
}
// INCORRECT: Don't access global variables directly
if (!silentMode) { // ❌ WRONG
loadingIndicator = startLoadingIndicator('Processing...');
}
```
4. **Wrapping Core Function Calls**:
- ✅ **DO**: Use a try/finally block pattern to ensure silent mode is always restored
- ✅ **DO**: Enable silent mode before calling core functions that produce console output
- ✅ **DO**: Disable silent mode in a finally block to ensure it runs even if errors occur
- ❌ **DON'T**: Enable silent mode without ensuring it gets disabled
```javascript
export async function someDirectFunction(args, log) {
try {
// Argument preparation
const tasksPath = findTasksJsonPath(args, log);
const someArg = args.someArg;
// Enable silent mode to prevent console logs
enableSilentMode();
try {
// Call core function which might produce console output
const result = await someCoreFunction(tasksPath, someArg);
// Return standardized result object
return {
success: true,
data: result,
fromCache: false
};
} finally {
// ALWAYS disable silent mode in finally block
disableSilentMode();
}
} catch (error) {
// Standard error handling
log.error(`Error in direct function: ${error.message}`);
return {
success: false,
error: { code: 'OPERATION_ERROR', message: error.message },
fromCache: false
};
}
}
```
5. **Mixed Parameter and Global Silent Mode Handling**:
- For functions that need to handle both a passed `silentMode` parameter and check global state:
```javascript
// Check both the function parameter and global state
const isSilent = options.silentMode || (typeof options.silentMode === 'undefined' && isSilentMode());
if (!isSilent) {
console.log('Operation starting...');
}
```
By following these patterns consistently, direct functions will properly manage console output suppression while ensuring that silent mode is always properly reset, even when errors occur. This creates a more robust system that helps prevent unexpected silent mode states that could cause logging problems in subsequent operations.
- **Testing Architecture**:
@@ -164,3 +318,67 @@ alwaysApply: false
- **Clarity**: The modular structure provides a clear separation of concerns, making the codebase easier to navigate and understand for developers.
This architectural overview should help AI models understand the structure and organization of the Task Master CLI codebase, enabling them to more effectively assist with code generation, modification, and understanding.
## Implementing MCP Support for a Command
Follow these steps to add MCP support for an existing Task Master command (see [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for more detail):
1. **Ensure Core Logic Exists**: Verify the core functionality is implemented and exported from the relevant module in `scripts/modules/`.
2. **Create Direct Function File in `mcp-server/src/core/direct-functions/`:**
- Create a new file (e.g., `your-command.js`) using **kebab-case** naming.
- Import necessary core functions, **`findTasksJsonPath` from `../utils/path-utils.js`**, and **silent mode utilities**.
- Implement `async function yourCommandDirect(args, log)` using **camelCase** with `Direct` suffix:
- **Path Resolution**: Obtain the tasks file path using `const tasksPath = findTasksJsonPath(args, log);`. This relies on `args.projectRoot` being provided.
- Parse other `args` and perform necessary validation.
- **Implement Silent Mode**: Wrap core function calls with `enableSilentMode()` and `disableSilentMode()`.
- Implement caching with `getCachedOrExecute` if applicable.
- Call core logic.
- Return `{ success: true/false, data/error, fromCache: boolean }`.
- Export the wrapper function.
3. **Update `task-master-core.js` with Import/Export**: Add imports/exports for the new `*Direct` function.
4. **Create MCP Tool (`mcp-server/src/tools/`)**:
- Create a new file (e.g., `your-command.js`) using **kebab-case**.
- Import `zod`, `handleApiResult`, **`getProjectRootFromSession`**, and your `yourCommandDirect` function.
- Implement `registerYourCommandTool(server)`.
- **Define parameters, making `projectRoot` optional**: `projectRoot: z.string().optional().describe(...)`.
- Consider if this operation should run in the background using `AsyncOperationManager`.
- Implement the standard `execute` method:
- Get `rootFolder` using `getProjectRootFromSession` (with fallback to `args.projectRoot`).
- Call `yourCommandDirect({ ...args, projectRoot: rootFolder }, log)` or use `asyncOperationManager.addOperation`.
- Pass the result to `handleApiResult`.
5. **Register Tool**: Import and call `registerYourCommandTool` in `mcp-server/src/tools/index.js`.
6. **Update `mcp.json`**: Add the new tool definition.
## Project Initialization
The `initialize_project` command provides a way to set up a new Task Master project:
- **CLI Command**: `task-master init`
- **MCP Tool**: `initialize_project`
- **Functionality**:
- Creates necessary directories and files for a new project
- Sets up `tasks.json` and initial task files
- Configures project metadata (name, description, version)
- Handles shell alias creation if requested
- Works in both interactive and non-interactive modes
## Async Operation Management
The AsyncOperationManager provides background task execution capabilities:
- **Location**: `mcp-server/src/core/utils/async-manager.js`
- **Key Components**:
- `asyncOperationManager` singleton instance
- `addOperation(operationFn, args, context)` method
- `getStatus(operationId)` method
- **Usage Flow**:
1. Client calls an MCP tool that may take time to complete
2. Tool uses AsyncOperationManager to run the operation in background
3. Tool returns immediate response with operation ID
4. Client polls `get_operation_status` tool with the ID
5. Once completed, client can access operation results

105
.cursor/rules/changeset.mdc Normal file
View File

@@ -0,0 +1,105 @@
---
description: Guidelines for using Changesets (npm run changeset) to manage versioning and changelogs.
alwaysApply: true
---
# Changesets Workflow Guidelines
Changesets is used to manage package versioning and generate accurate `CHANGELOG.md` files automatically. It's crucial to use it correctly after making meaningful changes that affect the package from an external perspective or significantly impact internal development workflow documented elsewhere.
## When to Run Changeset
- Run `npm run changeset` (or `npx changeset add`) **after** you have staged (`git add .`) a logical set of changes that should be communicated in the next release's `CHANGELOG.md`.
- This typically includes:
- **New Features** (Backward-compatible additions)
- **Bug Fixes** (Fixes to existing functionality)
- **Breaking Changes** (Changes that are not backward-compatible)
- **Performance Improvements** (Enhancements to speed or resource usage)
- **Significant Refactoring** (Major code restructuring, even if external behavior is unchanged, as it might affect stability or maintainability) - *Such as reorganizing the MCP server's direct function implementations into separate files*
- **User-Facing Documentation Updates** (Changes to README, usage guides, public API docs)
- **Dependency Updates** (Especially if they fix known issues or introduce significant changes)
- **Build/Tooling Changes** (If they affect how consumers might build or interact with the package)
- **Every Pull Request** containing one or more of the above change types **should include a changeset file**.
## What NOT to Add a Changeset For
Avoid creating changesets for changes that have **no impact or relevance to external consumers** of the `task-master` package or contributors following **public-facing documentation**. Examples include:
- **Internal Documentation Updates:** Changes *only* to files within `.cursor/rules/` that solely guide internal development practices for this specific repository.
- **Trivial Chores:** Very minor code cleanup, adding comments that don't clarify behavior, typo fixes in non-user-facing code or internal docs.
- **Non-Impactful Test Updates:** Minor refactoring of tests, adding tests for existing functionality without fixing bugs.
- **Local Configuration Changes:** Updates to personal editor settings, local `.env` files, etc.
**Rule of Thumb:** If a user installing or using the `task-master` package wouldn't care about the change, or if a contributor following the main README wouldn't need to know about it for their workflow, you likely don't need a changeset.
## How to Run and What It Asks
1. **Run the command**:
```bash
npm run changeset
# or
npx changeset add
```
2. **Select Packages**: It will prompt you to select the package(s) affected by your changes using arrow keys and spacebar. If this is not a monorepo, select the main package.
3. **Select Bump Type**: Choose the appropriate semantic version bump for **each** selected package:
* **`Major`**: For **breaking changes**. Use sparingly.
* **`Minor`**: For **new features**.
* **`Patch`**: For **bug fixes**, performance improvements, **user-facing documentation changes**, significant refactoring, relevant dependency updates, or impactful build/tooling changes.
4. **Enter Summary**: Provide a concise summary of the changes **for the `CHANGELOG.md`**.
* **Purpose**: This message is user-facing and explains *what* changed in the release.
* **Format**: Use the imperative mood (e.g., "Add feature X", "Fix bug Y", "Update README setup instructions"). Keep it brief, typically a single line.
* **Audience**: Think about users installing/updating the package or developers consuming its public API/CLI.
* **Not a Git Commit Message**: This summary is *different* from your detailed Git commit message.
## Changeset Summary vs. Git Commit Message
- **Changeset Summary**:
- **Audience**: Users/Consumers of the package (reads `CHANGELOG.md`).
- **Purpose**: Briefly describe *what* changed in the released version that is relevant to them.
- **Format**: Concise, imperative mood, single line usually sufficient.
- **Example**: `Fix dependency resolution bug in 'next' command.`
- **Git Commit Message**:
- **Audience**: Developers browsing the Git history of *this* repository.
- **Purpose**: Explain *why* the change was made, the context, and the implementation details (can include internal context).
- **Format**: Follows commit conventions (e.g., Conventional Commits), can be multi-line with a subject and body.
- **Example**:
```
fix(deps): Correct dependency lookup in 'next' command
The logic previously failed to account for subtask dependencies when
determining the next available task. This commit refactors the
dependency check in `findNextTask` within `task-manager.js` to
correctly traverse both direct and subtask dependencies. Added
unit tests to cover this specific scenario.
```
- ✅ **DO**: Provide *both* a concise changeset summary (when appropriate) *and* a detailed Git commit message.
- ❌ **DON'T**: Use your detailed Git commit message body as the changeset summary.
- ❌ **DON'T**: Skip running `changeset` for user-relevant changes just because you wrote a good commit message.
## The `.changeset` File
- Running the command creates a unique markdown file in the `.changeset/` directory (e.g., `.changeset/random-name.md`).
- This file contains the bump type information and the summary you provided.
- **This file MUST be staged and committed** along with your relevant code changes.
## Standard Workflow Sequence (When a Changeset is Needed)
1. Make your code or relevant documentation changes.
2. Stage your changes: `git add .`
3. Run changeset: `npm run changeset`
* Select package(s).
* Select bump type (`Patch`, `Minor`, `Major`).
* Enter the **concise summary** for the changelog.
4. Stage the generated changeset file: `git add .changeset/*.md`
5. Commit all staged changes (code + changeset file) using your **detailed Git commit message**:
```bash
git commit -m "feat(module): Add new feature X..."
```
## Release Process (Context)
- The generated `.changeset/*.md` files are consumed later during the release process.
- Commands like `changeset version` read these files, update `package.json` versions, update the `CHANGELOG.md`, and delete the individual changeset files.
- Commands like `changeset publish` then publish the new versions to npm.
Following this workflow ensures that versioning is consistent and changelogs are automatically and accurately generated based on the contributions made.

View File

@@ -6,6 +6,16 @@ alwaysApply: false
# Command-Line Interface Implementation Guidelines
**Note on Interaction Method:**
While this document details the implementation of Task Master's **CLI commands**, the **preferred method for interacting with Task Master in integrated environments (like Cursor) is through the MCP server tools**.
- **Use MCP Tools First**: Always prefer using the MCP tools (e.g., `get_tasks`, `add_task`) when interacting programmatically or via an integrated tool. They offer better performance, structured data, and richer error handling. See [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a comprehensive list of MCP tools and their corresponding CLI commands.
- **CLI as Fallback/User Interface**: The `task-master` CLI commands described here are primarily intended for:
- Direct user interaction in the terminal.
- A fallback mechanism if the MCP server is unavailable or a specific functionality is not exposed via an MCP tool.
- **Implementation Context**: This document (`commands.mdc`) focuses on the standards for *implementing* the CLI commands using Commander.js within the [`commands.js`](mdc:scripts/modules/commands.js) module.
## Command Structure Standards
- **Basic Command Template**:
@@ -14,7 +24,7 @@ alwaysApply: false
programInstance
.command('command-name')
.description('Clear, concise description of what the command does')
.option('-s, --short-option <value>', 'Option description', 'default value')
.option('-o, --option <value>', 'Option description', 'default value')
.option('--long-option <value>', 'Option description')
.action(async (options) => {
// Command implementation
@@ -24,9 +34,130 @@ alwaysApply: false
- **Command Handler Organization**:
- ✅ DO: Keep action handlers concise and focused
- ✅ DO: Extract core functionality to appropriate modules
- ✅ DO: Include validation for required parameters
- ✅ DO: Have the action handler import and call the relevant function(s) from core modules (e.g., `task-manager.js`, `init.js`), passing the parsed `options`.
- ✅ DO: Perform basic parameter validation (e.g., checking for required options) within the action handler or at the start of the called core function.
- ❌ DON'T: Implement business logic in command handlers
## Best Practices for Removal/Delete Commands
When implementing commands that delete or remove data (like `remove-task` or `remove-subtask`), follow these specific guidelines:
- **Confirmation Prompts**:
- ✅ **DO**: Include a confirmation prompt by default for destructive operations
- ✅ **DO**: Provide a `--yes` or `-y` flag to skip confirmation for scripting/automation
- ✅ **DO**: Show what will be deleted in the confirmation message
- ❌ **DON'T**: Perform destructive operations without user confirmation unless explicitly overridden
```javascript
// ✅ DO: Include confirmation for destructive operations
programInstance
.command('remove-task')
.description('Remove a task or subtask permanently')
.option('-i, --id <id>', 'ID of the task to remove')
.option('-y, --yes', 'Skip confirmation prompt', false)
.action(async (options) => {
// Validation code...
if (!options.yes) {
const confirm = await inquirer.prompt([{
type: 'confirm',
name: 'proceed',
message: `Are you sure you want to permanently delete task ${taskId}? This cannot be undone.`,
default: false
}]);
if (!confirm.proceed) {
console.log(chalk.yellow('Operation cancelled.'));
return;
}
}
// Proceed with removal...
});
```
- **File Path Handling**:
- ✅ **DO**: Use `path.join()` to construct file paths
- ✅ **DO**: Follow established naming conventions for tasks (e.g., `task_001.txt`)
- ✅ **DO**: Check if files exist before attempting to delete them
- ✅ **DO**: Handle file deletion errors gracefully
- ❌ **DON'T**: Construct paths with string concatenation
```javascript
// ✅ DO: Properly construct file paths
const taskFilePath = path.join(
path.dirname(tasksPath),
`task_${taskId.toString().padStart(3, '0')}.txt`
);
// ✅ DO: Check existence before deletion
if (fs.existsSync(taskFilePath)) {
try {
fs.unlinkSync(taskFilePath);
console.log(chalk.green(`Task file deleted: ${taskFilePath}`));
} catch (error) {
console.warn(chalk.yellow(`Could not delete task file: ${error.message}`));
}
}
```
- **Clean Up References**:
- ✅ **DO**: Clean up references to the deleted item in other parts of the data
- ✅ **DO**: Handle both direct and indirect references
- ✅ **DO**: Explain what related data is being updated
- ❌ **DON'T**: Leave dangling references
```javascript
// ✅ DO: Clean up references when deleting items
console.log(chalk.blue('Cleaning up task dependencies...'));
let referencesRemoved = 0;
// Update dependencies in other tasks
data.tasks.forEach(task => {
if (task.dependencies && task.dependencies.includes(taskId)) {
task.dependencies = task.dependencies.filter(depId => depId !== taskId);
referencesRemoved++;
}
});
if (referencesRemoved > 0) {
console.log(chalk.green(`Removed ${referencesRemoved} references to task ${taskId} from other tasks`));
}
```
- **Task File Regeneration**:
- ✅ **DO**: Regenerate task files after destructive operations
- ✅ **DO**: Pass all required parameters to generation functions
- ✅ **DO**: Provide an option to skip regeneration if needed
- ❌ **DON'T**: Assume default parameters will work
```javascript
// ✅ DO: Properly regenerate files after deletion
if (!options.skipGenerate) {
console.log(chalk.blue('Regenerating task files...'));
try {
// Note both parameters are explicitly provided
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
console.log(chalk.green('Task files regenerated successfully'));
} catch (error) {
console.warn(chalk.yellow(`Warning: Could not regenerate task files: ${error.message}`));
}
}
```
- **Alternative Suggestions**:
- ✅ **DO**: Suggest non-destructive alternatives when appropriate
- ✅ **DO**: Explain the difference between deletion and status changes
- ✅ **DO**: Include examples of alternative commands
```javascript
// ✅ DO: Suggest alternatives for destructive operations
console.log(chalk.yellow('Note: If you just want to exclude this task from active work, consider:'));
console.log(chalk.cyan(` task-master set-status --id='${taskId}' --status='cancelled'`));
console.log(chalk.cyan(` task-master set-status --id='${taskId}' --status='deferred'`));
console.log('This preserves the task and its history for reference.');
```
## Option Naming Conventions
- **Command Names**:
@@ -123,7 +254,7 @@ alwaysApply: false
const taskId = parseInt(options.id, 10);
if (isNaN(taskId) || taskId <= 0) {
console.error(chalk.red(`Error: Invalid task ID: ${options.id}. Task ID must be a positive integer.`));
console.log(chalk.yellow('Usage example: task-master update-task --id=23 --prompt="Update with new information"'));
console.log(chalk.yellow('Usage example: task-master update-task --id=\'23\' --prompt=\'Update with new information.\nEnsure proper error handling.\''));
process.exit(1);
}
@@ -169,8 +300,8 @@ alwaysApply: false
(dependencies.length > 0 ? chalk.white(`Dependencies: ${dependencies.join(', ')}`) + '\n' : '') +
'\n' +
chalk.white.bold('Next Steps:') + '\n' +
chalk.cyan(`1. Run ${chalk.yellow(`task-master show ${parentId}`)} to see the parent task with all subtasks`) + '\n' +
chalk.cyan(`2. Run ${chalk.yellow(`task-master set-status --id=${parentId}.${subtask.id} --status=in-progress`)} to start working on it`),
chalk.cyan(`1. Run ${chalk.yellow(`task-master show '${parentId}'`)} to see the parent task with all subtasks`) + '\n' +
chalk.cyan(`2. Run ${chalk.yellow(`task-master set-status --id='${parentId}.${subtask.id}' --status='in-progress'`)} to start working on it`),
{ padding: 1, borderColor: 'green', borderStyle: 'round', margin: { top: 1 } }
));
```
@@ -245,7 +376,7 @@ alwaysApply: false
' --option1 <value> Description of option1 (required)\n' +
' --option2 <value> Description of option2\n\n' +
chalk.cyan('Examples:') + '\n' +
' task-master command --option1=value --option2=value',
' task-master command --option1=\'value1\' --option2=\'value2\'',
{ padding: 1, borderColor: 'blue', borderStyle: 'round' }
));
}
@@ -288,7 +419,7 @@ alwaysApply: false
// Provide more helpful error messages for common issues
if (error.message.includes('task') && error.message.includes('not found')) {
console.log(chalk.yellow('\nTo fix this issue:'));
console.log(' 1. Run task-master list to see all available task IDs');
console.log(' 1. Run \'task-master list\' to see all available task IDs');
console.log(' 2. Use a valid task ID with the --id parameter');
} else if (error.message.includes('API key')) {
console.log(chalk.yellow('\nThis error is related to API keys. Check your environment variables.'));
@@ -432,3 +563,45 @@ alwaysApply: false
```
Refer to [`commands.js`](mdc:scripts/modules/commands.js) for implementation examples and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines.
// Helper function to show add-subtask command help
function showAddSubtaskHelp() {
console.log(boxen(
chalk.white.bold('Add Subtask Command Help') + '\n\n' +
chalk.cyan('Usage:') + '\n' +
` task-master add-subtask --parent=<id> [options]\n\n` +
chalk.cyan('Options:') + '\n' +
' -p, --parent <id> Parent task ID (required)\n' +
' -i, --task-id <id> Existing task ID to convert to subtask\n' +
' -t, --title <title> Title for the new subtask\n' +
' -d, --description <text> Description for the new subtask\n' +
' --details <text> Implementation details for the new subtask\n' +
' --dependencies <ids> Comma-separated list of dependency IDs\n' +
' -s, --status <status> Status for the new subtask (default: "pending")\n' +
' -f, --file <file> Path to the tasks file (default: "tasks/tasks.json")\n' +
' --skip-generate Skip regenerating task files\n\n' +
chalk.cyan('Examples:') + '\n' +
' task-master add-subtask --parent=\'5\' --task-id=\'8\'\n' +
' task-master add-subtask -p \'5\' -t \'Implement login UI\' -d \'Create the login form\'\n' +
' task-master add-subtask -p \'5\' -t \'Handle API Errors\' --details $\'Handle 401 Unauthorized.\nHandle 500 Server Error.\'',
{ padding: 1, borderColor: 'blue', borderStyle: 'round' }
));
}
// Helper function to show remove-subtask command help
function showRemoveSubtaskHelp() {
console.log(boxen(
chalk.white.bold('Remove Subtask Command Help') + '\n\n' +
chalk.cyan('Usage:') + '\n' +
` task-master remove-subtask --id=<parentId.subtaskId> [options]\n\n` +
chalk.cyan('Options:') + '\n' +
' -i, --id <id> Subtask ID(s) to remove in format "parentId.subtaskId" (can be comma-separated, required)\n' +
' -c, --convert Convert the subtask to a standalone task instead of deleting it\n' +
' -f, --file <file> Path to the tasks file (default: "tasks/tasks.json")\n' +
' --skip-generate Skip regenerating task files\n\n' +
chalk.cyan('Examples:') + '\n' +
' task-master remove-subtask --id=\'5.2\'\n' +
' task-master remove-subtask --id=\'5.2,6.3,7.1\'\n' +
' task-master remove-subtask --id=\'5.2\' --convert',
{ padding: 1, borderColor: 'blue', borderStyle: 'round' }
));
}

View File

@@ -1,223 +1,125 @@
---
description: Guide for using meta-development script (scripts/dev.js) to manage task-driven development workflows
description: Guide for using Task Master to manage task-driven development workflows
globs: **/*
alwaysApply: true
---
- **Global CLI Commands**
- Task Master now provides a global CLI through the `task-master` command (See [`commands.mdc`](mdc:.cursor/rules/commands.mdc) for details)
- All functionality from `scripts/dev.js` is available through this interface
- Install globally with `npm install -g claude-task-master` or use locally via `npx`
- Use `task-master <command>` instead of `node scripts/dev.js <command>`
- Examples:
- `task-master list`
- `task-master next`
- `task-master expand --id=3`
- All commands accept the same options as their script equivalents
- The CLI (`task-master`) is the **primary** way for users to interact with the application.
# Task Master Development Workflow
- **Development Workflow Process**
- Start new projects by running `task-master init` or `node scripts/dev.js parse-prd --input=<prd-file.txt>` to generate initial tasks.json
- Begin coding sessions with `task-master list` to see current tasks, status, and IDs
- Analyze task complexity with `task-master analyze-complexity --research` before breaking down tasks
This guide outlines the typical process for using Task Master to manage software development projects.
## Primary Interaction: MCP Server vs. CLI
Task Master offers two primary ways to interact:
1. **MCP Server (Recommended for Integrated Tools)**:
- For AI agents and integrated development environments (like Cursor), interacting via the **MCP server is the preferred method**.
- The MCP server exposes Task Master functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
- This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
- Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details on the MCP architecture and available tools.
- A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
- **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
2. **`task-master` CLI (For Users & Fallback)**:
- The global `task-master` command provides a user-friendly interface for direct terminal interaction.
- It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
- Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
- The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
- Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a detailed command reference.
## Standard Development Workflow Process
- Start new projects by running `init` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json
- Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to see current tasks, status, and IDs
- Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Analyze task complexity with `analyze_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before breaking down tasks
- Review complexity report using `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Select tasks based on dependencies (all marked 'done'), priority level, and ID order
- Clarify tasks by checking task files in tasks/ directory or asking for user input
- View specific task details using `task-master show <id>` to understand implementation requirements
- Break down complex tasks using `task-master expand --id=<id>` with appropriate flags
- Clear existing subtasks if needed using `task-master clear-subtasks --id=<id>` before regenerating
- View specific task details using `get_task` / `task-master show <id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to understand implementation requirements
- Break down complex tasks using `expand_task` / `task-master expand --id=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) with appropriate flags
- Clear existing subtasks if needed using `clear_subtasks` / `task-master clear-subtasks --id=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before regenerating
- Implement code following task details, dependencies, and project standards
- Verify tasks according to test strategies before marking as complete
- Mark completed tasks with `task-master set-status --id=<id> --status=done`
- Update dependent tasks when implementation differs from original plan
- Generate task files with `task-master generate` after updating tasks.json
- Maintain valid dependency structure with `task-master fix-dependencies` when needed
- Verify tasks according to test strategies before marking as complete (See [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
- Mark completed tasks with `set_task_status` / `task-master set-status --id=<id> --status=done` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
- Update dependent tasks when implementation differs from original plan using `update` / `task-master update --from=<id> --prompt="..."` or `update_task` / `task-master update-task --id=<id> --prompt="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
- Add new tasks discovered during implementation using `add_task` / `task-master add-task --prompt="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Add new subtasks as needed using `add_subtask` / `task-master add-subtask --parent=<id> --title="..."` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Append notes or details to subtasks using `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='Add implementation notes here...\nMore details...'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
- Generate task files with `generate` / `task-master generate` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) after updating tasks.json
- Maintain valid dependency structure with `add_dependency`/`remove_dependency` tools or `task-master add-dependency`/`remove-dependency` commands, `validate_dependencies` / `task-master validate-dependencies`, and `fix_dependencies` / `task-master fix-dependencies` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) when needed
- Respect dependency chains and task priorities when selecting work
- **MCP Server**: For integrations (like Cursor), interact via the MCP server which prefers direct function calls. Restart the MCP server if core logic in `scripts/modules` changes. See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc).
- Report progress regularly using the list command
- Report progress regularly using `get_tasks` / `task-master list`
- **Task Complexity Analysis**
- Run `node scripts/dev.js analyze-complexity --research` for comprehensive analysis
- Review complexity report in scripts/task-complexity-report.json
- Or use `node scripts/dev.js complexity-report` for a formatted, readable version of the report
## Task Complexity Analysis
- Run `analyze_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for comprehensive analysis
- Review complexity report via `complexity_report` / `task-master complexity-report` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) for a formatted, readable version.
- Focus on tasks with highest complexity scores (8-10) for detailed breakdown
- Use analysis results to determine appropriate subtask allocation
- Note that reports are automatically used by the expand command
- Note that reports are automatically used by the `expand` tool/command
- **Task Breakdown Process**
- For tasks with complexity analysis, use `node scripts/dev.js expand --id=<id>`
- Otherwise use `node scripts/dev.js expand --id=<id> --subtasks=<number>`
## Task Breakdown Process
- For tasks with complexity analysis, use `expand_task` / `task-master expand --id=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc))
- Otherwise use `expand_task` / `task-master expand --id=<id> --num=<number>`
- Add `--research` flag to leverage Perplexity AI for research-backed expansion
- Use `--prompt="<context>"` to provide additional context when needed
- Review and adjust generated subtasks as necessary
- Use `--all` flag to expand multiple pending tasks at once
- If subtasks need regeneration, clear them first with `clear-subtasks` command (See Command Reference below)
- Use `--all` flag with `expand` or `expand_all` to expand multiple pending tasks at once
- If subtasks need regeneration, clear them first with `clear_subtasks` / `task-master clear-subtasks` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
## Implementation Drift Handling
- **Implementation Drift Handling**
- When implementation differs significantly from planned approach
- When future tasks need modification due to current implementation choices
- When new dependencies or requirements emerge
- Call `node scripts/dev.js update --from=<futureTaskId> --prompt="<explanation>"` to update tasks.json
- Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to update multiple future tasks.
- Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to update a single specific task.
## Task Status Management
- **Task Status Management**
- Use 'pending' for tasks ready to be worked on
- Use 'done' for completed and verified tasks
- Use 'deferred' for postponed tasks
- Add custom status values as needed for project-specific workflows
- **Task File Format Reference**
```
# Task ID: <id>
# Title: <title>
# Status: <status>
# Dependencies: <comma-separated list of dependency IDs>
# Priority: <priority>
# Description: <brief description>
# Details:
<detailed implementation notes>
## Task Structure Fields
# Test Strategy:
<verification approach>
```
- **Command Reference: parse-prd**
- CLI Syntax: `task-master parse-prd --input=<prd-file.txt>`
- Description: Parses a PRD document and generates a `tasks.json` file with structured tasks
- Parameters:
- `--input=<file>`: Path to the PRD text file (default: sample-prd.txt)
- Example: `task-master parse-prd --input=requirements.txt`
- Notes: Will overwrite existing tasks.json file. Use with caution.
- **Command Reference: update**
- CLI Syntax: `task-master update --from=<id> --prompt="<prompt>"`
- Description: Updates tasks with ID >= specified ID based on the provided prompt
- Parameters:
- `--from=<id>`: Task ID from which to start updating (required)
- `--prompt="<text>"`: Explanation of changes or new context (required)
- Example: `task-master update --from=4 --prompt="Now we are using Express instead of Fastify."`
- Notes: Only updates tasks not marked as 'done'. Completed tasks remain unchanged.
- **Command Reference: update-task**
- CLI Syntax: `task-master update-task --id=<id> --prompt="<prompt>"`
- Description: Updates a single task by ID with new information
- Parameters:
- `--id=<id>`: ID of the task to update (required)
- `--prompt="<text>"`: New information or context to update the task (required)
- `--research`: Use Perplexity AI for research-backed updates
- Example: `task-master update-task --id=5 --prompt="Use JWT for authentication instead of sessions."`
- Notes: Only updates tasks not marked as 'done'. Preserves completed subtasks.
- **Command Reference: update-subtask**
- CLI Syntax: `task-master update-subtask --id=<id> --prompt="<prompt>"`
- Description: Appends additional information to a specific subtask without replacing existing content
- Parameters:
- `--id=<id>`: ID of the subtask to update in format "parentId.subtaskId" (required)
- `--prompt="<text>"`: Information to add to the subtask (required)
- `--research`: Use Perplexity AI for research-backed updates
- Example: `task-master update-subtask --id=5.2 --prompt="Add details about API rate limiting."`
- Notes:
- Appends new information to subtask details with timestamp
- Does not replace existing content, only adds to it
- Uses XML-like tags to clearly mark added information
- Will not update subtasks marked as 'done' or 'completed'
- **Command Reference: generate**
- CLI Syntax: `task-master generate`
- Description: Generates individual task files in tasks/ directory based on tasks.json
- Parameters:
- `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
- `--output=<dir>, -o`: Output directory (default: 'tasks')
- Example: `task-master generate`
- Notes: Overwrites existing task files. Creates tasks/ directory if needed.
- **Command Reference: set-status**
- CLI Syntax: `task-master set-status --id=<id> --status=<status>`
- Description: Updates the status of a specific task in tasks.json
- Parameters:
- `--id=<id>`: ID of the task to update (required)
- `--status=<status>`: New status value (required)
- Example: `task-master set-status --id=3 --status=done`
- Notes: Common values are 'done', 'pending', and 'deferred', but any string is accepted.
- **Command Reference: list**
- CLI Syntax: `task-master list`
- Description: Lists all tasks in tasks.json with IDs, titles, and status
- Parameters:
- `--status=<status>, -s`: Filter by status
- `--with-subtasks`: Show subtasks for each task
- `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
- Example: `task-master list`
- Notes: Provides quick overview of project progress. Use at start of sessions.
- **Command Reference: expand**
- CLI Syntax: `task-master expand --id=<id> [--num=<number>] [--research] [--prompt="<context>"]`
- Description: Expands a task with subtasks for detailed implementation
- Parameters:
- `--id=<id>`: ID of task to expand (required unless using --all)
- `--all`: Expand all pending tasks, prioritized by complexity
- `--num=<number>`: Number of subtasks to generate (default: from complexity report)
- `--research`: Use Perplexity AI for research-backed generation
- `--prompt="<text>"`: Additional context for subtask generation
- `--force`: Regenerate subtasks even for tasks that already have them
- Example: `task-master expand --id=3 --num=5 --research --prompt="Focus on security aspects"`
- Notes: Uses complexity report recommendations if available.
- **Command Reference: analyze-complexity**
- CLI Syntax: `task-master analyze-complexity [options]`
- Description: Analyzes task complexity and generates expansion recommendations
- Parameters:
- `--output=<file>, -o`: Output file path (default: scripts/task-complexity-report.json)
- `--model=<model>, -m`: Override LLM model to use
- `--threshold=<number>, -t`: Minimum score for expansion recommendation (default: 5)
- `--file=<path>, -f`: Use alternative tasks.json file
- `--research, -r`: Use Perplexity AI for research-backed analysis
- Example: `task-master analyze-complexity --research`
- Notes: Report includes complexity scores, recommended subtasks, and tailored prompts.
- **Command Reference: clear-subtasks**
- CLI Syntax: `task-master clear-subtasks --id=<id>`
- Description: Removes subtasks from specified tasks to allow regeneration
- Parameters:
- `--id=<id>`: ID or comma-separated IDs of tasks to clear subtasks from
- `--all`: Clear subtasks from all tasks
- Examples:
- `task-master clear-subtasks --id=3`
- `task-master clear-subtasks --id=1,2,3`
- `task-master clear-subtasks --all`
- Notes:
- Task files are automatically regenerated after clearing subtasks
- Can be combined with expand command to immediately generate new subtasks
- Works with both parent tasks and individual subtasks
- **Task Structure Fields**
- **id**: Unique identifier for the task (Example: `1`)
- **id**: Unique identifier for the task (Example: `1`, `1.1`)
- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2]`)
- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
- Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
- This helps quickly identify which prerequisite tasks are blocking work
- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
- Refer to [`tasks.mdc`](mdc:.cursor/rules/tasks.mdc) for more details on the task data structure.
- **Environment Variables Configuration**
- **ANTHROPIC_API_KEY** (Required): Your Anthropic API key for Claude (Example: `ANTHROPIC_API_KEY=sk-ant-api03-...`)
- **MODEL** (Default: `"claude-3-7-sonnet-20250219"`): Claude model to use (Example: `MODEL=claude-3-opus-20240229`)
- **MAX_TOKENS** (Default: `"4000"`): Maximum tokens for responses (Example: `MAX_TOKENS=8000`)
- **TEMPERATURE** (Default: `"0.7"`): Temperature for model responses (Example: `TEMPERATURE=0.5`)
- **DEBUG** (Default: `"false"`): Enable debug logging (Example: `DEBUG=true`)
- **LOG_LEVEL** (Default: `"info"`): Console output level (Example: `LOG_LEVEL=debug`)
- **DEFAULT_SUBTASKS** (Default: `"3"`): Default subtask count (Example: `DEFAULT_SUBTASKS=5`)
- **DEFAULT_PRIORITY** (Default: `"medium"`): Default priority (Example: `DEFAULT_PRIORITY=high`)
- **PROJECT_NAME** (Default: `"MCP SaaS MVP"`): Project name in metadata (Example: `PROJECT_NAME=My Awesome Project`)
- **PROJECT_VERSION** (Default: `"1.0.0"`): Version in metadata (Example: `PROJECT_VERSION=2.1.0`)
- **PERPLEXITY_API_KEY**: For research-backed features (Example: `PERPLEXITY_API_KEY=pplx-...`)
- **PERPLEXITY_MODEL** (Default: `"sonar-medium-online"`): Perplexity model (Example: `PERPLEXITY_MODEL=sonar-large-online`)
## Environment Variables Configuration
- **Determining the Next Task**
- Run `task-master next` to show the next task to work on
- The next command identifies tasks with all dependencies satisfied
- Task Master behavior is configured via environment variables:
- **ANTHROPIC_API_KEY** (Required): Your Anthropic API key for Claude.
- **MODEL**: Claude model to use (e.g., `claude-3-opus-20240229`).
- **MAX_TOKENS**: Maximum tokens for AI responses.
- **TEMPERATURE**: Temperature for AI model responses.
- **DEBUG**: Enable debug logging (`true`/`false`).
- **LOG_LEVEL**: Console output level (`debug`, `info`, `warn`, `error`).
- **DEFAULT_SUBTASKS**: Default number of subtasks for `expand`.
- **DEFAULT_PRIORITY**: Default priority for new tasks.
- **PROJECT_NAME**: Project name used in metadata.
- **PROJECT_VERSION**: Project version used in metadata.
- **PERPLEXITY_API_KEY**: API key for Perplexity AI (for `--research` flags).
- **PERPLEXITY_MODEL**: Perplexity model to use (e.g., `sonar-medium-online`).
- See [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for default values and examples.
## Determining the Next Task
- Run `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to show the next task to work on
- The command identifies tasks with all dependencies satisfied
- Tasks are prioritized by priority level, dependency count, and ID
- The command shows comprehensive task information including:
- Basic task details and description
@@ -229,8 +131,9 @@ alwaysApply: true
- Ensures tasks are completed in the appropriate sequence
- Provides ready-to-use commands for common task actions
- **Viewing Specific Task Details**
- Run `task-master show <id>` or `task-master show --id=<id>` to view a specific task
## Viewing Specific Task Details
- Run `get_task` / `task-master show <id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to view a specific task
- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
- Displays comprehensive information similar to the next command, but for a specific task
- For parent tasks, shows all subtasks and their current status
@@ -238,108 +141,75 @@ alwaysApply: true
- Provides contextual suggested actions appropriate for the specific task
- Useful for examining task details before implementation or checking status
- **Managing Task Dependencies**
- Use `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency
- Use `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency
## Managing Task Dependencies
- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to add a dependency
- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to remove a dependency
- The system prevents circular dependencies and duplicate dependency entries
- Dependencies are checked for existence before being added or removed
- Task files are automatically regenerated after dependency changes
- Dependencies are visualized with status indicators in task listings and files
- **Command Reference: add-dependency**
- CLI Syntax: `task-master add-dependency --id=<id> --depends-on=<id>`
- Description: Adds a dependency relationship between two tasks
- Parameters:
- `--id=<id>`: ID of task that will depend on another task (required)
- `--depends-on=<id>`: ID of task that will become a dependency (required)
- Example: `task-master add-dependency --id=22 --depends-on=21`
- Notes: Prevents circular dependencies and duplicates; updates task files automatically
## Iterative Subtask Implementation
- **Command Reference: remove-dependency**
- CLI Syntax: `task-master remove-dependency --id=<id> --depends-on=<id>`
- Description: Removes a dependency relationship between two tasks
- Parameters:
- `--id=<id>`: ID of task to remove dependency from (required)
- `--depends-on=<id>`: ID of task to remove as a dependency (required)
- Example: `task-master remove-dependency --id=22 --depends-on=21`
- Notes: Checks if dependency actually exists; updates task files automatically
Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
- **Command Reference: validate-dependencies**
- CLI Syntax: `task-master validate-dependencies [options]`
- Description: Checks for and identifies invalid dependencies in tasks.json and task files
- Parameters:
- `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
- Example: `task-master validate-dependencies`
- Notes:
- Reports all non-existent dependencies and self-dependencies without modifying files
- Provides detailed statistics on task dependency state
- Use before fix-dependencies to audit your task structure
1. **Understand the Goal (Preparation):**
* Use `get_task` / `task-master show <subtaskId>` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to thoroughly understand the specific goals and requirements of the subtask.
- **Command Reference: fix-dependencies**
- CLI Syntax: `task-master fix-dependencies [options]`
- Description: Finds and fixes all invalid dependencies in tasks.json and task files
- Parameters:
- `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
- Example: `task-master fix-dependencies`
- Notes:
- Removes references to non-existent tasks and subtasks
- Eliminates self-dependencies (tasks depending on themselves)
- Regenerates task files with corrected dependencies
- Provides detailed report of all fixes made
2. **Initial Exploration & Planning (Iteration 1):**
* This is the first attempt at creating a concrete implementation plan.
* Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
* Determine the intended code changes (diffs) and their locations.
* Gather *all* relevant details from this exploration phase.
- **Command Reference: complexity-report**
- CLI Syntax: `task-master complexity-report [options]`
- Description: Displays the task complexity analysis report in a formatted, easy-to-read way
- Parameters:
- `--file=<path>, -f`: Path to the complexity report file (default: 'scripts/task-complexity-report.json')
- Example: `task-master complexity-report`
- Notes:
- Shows tasks organized by complexity score with recommended actions
- Provides complexity distribution statistics
- Displays ready-to-use expansion commands for complex tasks
- If no report exists, offers to generate one interactively
3. **Log the Plan:**
* Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
* Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
- **Command Reference: add-task**
- CLI Syntax: `task-master add-task [options]`
- Description: Add a new task to tasks.json using AI
- Parameters:
- `--file=<path>, -f`: Path to the tasks file (default: 'tasks/tasks.json')
- `--prompt=<text>, -p`: Description of the task to add (required)
- `--dependencies=<ids>, -d`: Comma-separated list of task IDs this task depends on
- `--priority=<priority>`: Task priority (high, medium, low) (default: 'medium')
- Example: `task-master add-task --prompt="Create user authentication using Auth0"`
- Notes: Uses AI to convert description into structured task with appropriate details
4. **Verify the Plan:**
* Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
- **Command Reference: init**
- CLI Syntax: `task-master init`
- Description: Initialize a new project with Task Master structure
- Parameters: None
- Example: `task-master init`
- Notes:
- Creates initial project structure with required files
- Prompts for project settings if not provided
- Merges with existing files when appropriate
- Can be used to bootstrap a new Task Master project quickly
5. **Begin Implementation:**
* Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
* Start coding based on the logged plan.
- **Code Analysis & Refactoring Techniques**
- **Top-Level Function Search**
- Use grep pattern matching to find all exported functions across the codebase
- Command: `grep -E "export (function|const) \w+|function \w+\(|const \w+ = \(|module\.exports" --include="*.js" -r ./`
- Benefits:
- Quickly identify all public API functions without reading implementation details
- Compare functions between files during refactoring (e.g., monolithic to modular structure)
- Verify all expected functions exist in refactored modules
- Identify duplicate functionality or naming conflicts
- Usage examples:
- When migrating from `scripts/dev.js` to modular structure: `grep -E "function \w+\(" scripts/dev.js`
- Check function exports in a directory: `grep -E "export (function|const)" scripts/modules/`
- Find potential naming conflicts: `grep -E "function (get|set|create|update)\w+\(" -r ./`
- Variations:
- Add `-n` flag to include line numbers
- Add `--include="*.ts"` to filter by file extension
- Use with `| sort` to alphabetize results
- Integration with refactoring workflow:
- Start by mapping all functions in the source file
- Create target module files based on function grouping
- Verify all functions were properly migrated
- Check for any unintentional duplications or omissions
6. **Refine and Log Progress (Iteration 2+):**
* As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
* **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
* **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
* **Crucially, log:**
* What worked ("fundamental truths" discovered).
* What didn't work and why (to avoid repeating mistakes).
* Specific code snippets or configurations that were successful.
* Decisions made, especially if confirmed with user input.
* Any deviations from the initial plan and the reasoning.
* The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
7. **Review & Update Rules (Post-Implementation):**
* Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
* Identify any new or modified code patterns, conventions, or best practices established during the implementation.
* Create new or update existing Cursor rules in the `.cursor/rules/` directory to capture these patterns, following the guidelines in [`cursor_rules.mdc`](mdc:.cursor/rules/cursor_rules.mdc) and [`self_improve.mdc`](mdc:.cursor/rules/self_improve.mdc).
8. **Mark Task Complete:**
* After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
9. **Commit Changes (If using Git):**
* Stage the relevant code changes and any updated/new rule files (`git add .`).
* Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
* Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
* Consider if a Changeset is needed according to [`changeset.mdc`](mdc:.cursor/rules/changeset.mdc). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
10. **Proceed to Next Subtask:**
* Identify the next subtask in the dependency chain (e.g., using `next_task` / `task-master next`) and repeat this iterative process starting from step 1.
## Code Analysis & Refactoring Techniques
- **Top-Level Function Search**:
- Useful for understanding module structure or planning refactors.
- Use grep/ripgrep to find exported functions/constants:
`rg "export (async function|function|const) \w+"` or similar patterns.
- Can help compare functions between files during migrations or identify potential naming conflicts.
---
*This workflow provides a general guideline. Adapt it based on your specific project needs and team practices.*

View File

@@ -0,0 +1,26 @@
---
description: Glossary of other Cursor rules
globs: **/*
alwaysApply: true
---
# Glossary of Task Master Cursor Rules
This file provides a quick reference to the purpose of each rule file located in the `.cursor/rules` directory.
- **[`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)**: Describes the high-level architecture of the Task Master CLI application.
- **[`changeset.mdc`](mdc:.cursor/rules/changeset.mdc)**: Guidelines for using Changesets (npm run changeset) to manage versioning and changelogs.
- **[`commands.mdc`](mdc:.cursor/rules/commands.mdc)**: Guidelines for implementing CLI commands using Commander.js.
- **[`cursor_rules.mdc`](mdc:.cursor/rules/cursor_rules.mdc)**: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
- **[`dependencies.mdc`](mdc:.cursor/rules/dependencies.mdc)**: Guidelines for managing task dependencies and relationships.
- **[`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)**: Guide for using Task Master to manage task-driven development workflows.
- **[`glossary.mdc`](mdc:.cursor/rules/glossary.mdc)**: This file; provides a glossary of other Cursor rules.
- **[`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)**: Guidelines for implementing and interacting with the Task Master MCP Server.
- **[`new_features.mdc`](mdc:.cursor/rules/new_features.mdc)**: Guidelines for integrating new features into the Task Master CLI.
- **[`self_improve.mdc`](mdc:.cursor/rules/self_improve.mdc)**: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
- **[`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)**: Comprehensive reference for Taskmaster MCP tools and CLI commands.
- **[`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)**: Guidelines for implementing task management operations.
- **[`tests.mdc`](mdc:.cursor/rules/tests.mdc)**: Guidelines for implementing and maintaining tests for Task Master CLI.
- **[`ui.mdc`](mdc:.cursor/rules/ui.mdc)**: Guidelines for implementing and maintaining user interface components.
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions.

View File

@@ -12,76 +12,633 @@ This document outlines the architecture and implementation patterns for the Task
The MCP server acts as a bridge between external tools (like Cursor) and the core Task Master CLI logic. It leverages FastMCP for the server framework.
- **Flow**: `External Tool (Cursor)` <-> `FastMCP Server` <-> `MCP Tools` (`mcp-server/src/tools/*.js`) <-> `Core Logic Wrappers` (`mcp-server/src/core/task-master-core.js`) <-> `Core Modules` (`scripts/modules/*.js`)
- **Flow**: `External Tool (Cursor)` <-> `FastMCP Server` <-> `MCP Tools` (`mcp-server/src/tools/*.js`) <-> `Core Logic Wrappers` (`mcp-server/src/core/direct-functions/*.js`, exported via `task-master-core.js`) <-> `Core Modules` (`scripts/modules/*.js`)
- **Goal**: Provide a performant and reliable way for external tools to interact with Task Master functionality without directly invoking the CLI for every operation.
## Direct Function Implementation Best Practices
When implementing a new direct function in `mcp-server/src/core/direct-functions/`, follow these critical guidelines:
1. **Verify Function Dependencies**:
- ✅ **DO**: Check that all helper functions your direct function needs are properly exported from their source modules
- ✅ **DO**: Import these dependencies explicitly at the top of your file
- ❌ **DON'T**: Assume helper functions like `findTaskById` or `taskExists` are automatically available
- **Example**:
```javascript
// At top of direct-function file
import { removeTask, findTaskById, taskExists } from '../../../../scripts/modules/task-manager.js';
```
2. **Parameter Verification and Completeness**:
- ✅ **DO**: Verify the signature of core functions you're calling and ensure all required parameters are provided
- ✅ **DO**: Pass explicit values for required parameters rather than relying on defaults
- ✅ **DO**: Double-check parameter order against function definition
- ❌ **DON'T**: Omit parameters assuming they have default values
- **Example**:
```javascript
// Correct parameter handling in direct function
async function generateTaskFilesDirect(args, log) {
const tasksPath = findTasksJsonPath(args, log);
const outputDir = args.output || path.dirname(tasksPath);
try {
// Pass all required parameters
const result = await generateTaskFiles(tasksPath, outputDir);
return { success: true, data: result, fromCache: false };
} catch (error) {
// Error handling...
}
}
```
3. **Consistent File Path Handling**:
- ✅ **DO**: Use `path.join()` instead of string concatenation for file paths
- ✅ **DO**: Follow established file naming conventions (`task_001.txt` not `1.md`)
- ✅ **DO**: Use `path.dirname()` and other path utilities for manipulating paths
- ✅ **DO**: When paths relate to task files, follow the standard format: `task_${id.toString().padStart(3, '0')}.txt`
- ❌ **DON'T**: Create custom file path handling logic that diverges from established patterns
- **Example**:
```javascript
// Correct file path handling
const taskFilePath = path.join(
path.dirname(tasksPath),
`task_${taskId.toString().padStart(3, '0')}.txt`
);
```
4. **Comprehensive Error Handling**:
- ✅ **DO**: Wrap core function calls *and AI calls* in try/catch blocks
- ✅ **DO**: Log errors with appropriate severity and context
- ✅ **DO**: Return standardized error objects with code and message (`{ success: false, error: { code: '...', message: '...' } }`)
- ✅ **DO**: Handle file system errors, AI client errors, AI processing errors, and core function errors distinctly with appropriate codes.
- **Example**:
```javascript
try {
// Core function call or AI logic
} catch (error) {
log.error(`Failed to execute direct function logic: ${error.message}`);
return {
success: false,
error: {
code: error.code || 'DIRECT_FUNCTION_ERROR', // Use specific codes like AI_CLIENT_ERROR, etc.
message: error.message,
details: error.stack // Optional: Include stack in debug mode
},
fromCache: false // Ensure this is included if applicable
};
}
```
5. **Handling Logging Context (`mcpLog`)**:
- **Requirement**: Core functions that use the internal `report` helper function (common in `task-manager.js`, `dependency-manager.js`, etc.) expect the `options` object to potentially contain an `mcpLog` property. This `mcpLog` object **must** have callable methods for each log level (e.g., `mcpLog.info(...)`, `mcpLog.error(...)`).
- **Challenge**: The `log` object provided by FastMCP to the direct function's context, while functional, might not perfectly match this expected structure or could change in the future. Passing it directly can lead to runtime errors like `mcpLog[level] is not a function`.
- **Solution: The Logger Wrapper Pattern**: To reliably bridge the FastMCP `log` object and the core function's `mcpLog` expectation, use a simple wrapper object within the direct function:
```javascript
// Standard logWrapper pattern within a Direct Function
const logWrapper = {
info: (message, ...args) => log.info(message, ...args),
warn: (message, ...args) => log.warn(message, ...args),
error: (message, ...args) => log.error(message, ...args),
debug: (message, ...args) => log.debug && log.debug(message, ...args), // Handle optional debug
success: (message, ...args) => log.info(message, ...args) // Map success to info if needed
};
// ... later when calling the core function ...
await coreFunction(
// ... other arguments ...
tasksPath,
taskId,
{
mcpLog: logWrapper, // Pass the wrapper object
session
},
'json' // Pass 'json' output format if supported by core function
);
```
- **Critical For JSON Output Format**: Passing the `logWrapper` as `mcpLog` serves a dual purpose:
1. **Prevents Runtime Errors**: It ensures the `mcpLog[level](...)` calls within the core function succeed
2. **Controls Output Format**: In functions like `updateTaskById` and `updateSubtaskById`, the presence of `mcpLog` in the options triggers setting `outputFormat = 'json'` (instead of 'text'). This prevents UI elements (spinners, boxes) from being generated, which would break the JSON response.
- **Proven Solution**: This pattern has successfully fixed multiple issues in our MCP tools (including `update-task` and `update-subtask`), where direct passing of the `log` object or omitting `mcpLog` led to either runtime errors or JSON parsing failures from UI output.
- **When To Use**: Implement this wrapper in any direct function that calls a core function with an `options` object that might use `mcpLog` for logging or output format control.
- **Why it Works**: The `logWrapper` explicitly defines the `.info()`, `.warn()`, `.error()`, etc., methods that the core function's `report` helper needs, ensuring the `mcpLog[level](...)` call succeeds. It simply forwards the logging calls to the actual FastMCP `log` object.
- **Combined with Silent Mode**: Remember that using the `logWrapper` for `mcpLog` is **necessary *in addition* to using `enableSilentMode()` / `disableSilentMode()`** (see next point). The wrapper handles structured logging *within* the core function, while silent mode suppresses direct `console.log` and UI elements (spinners, boxes) that would break the MCP JSON response.
6. **Silent Mode Implementation**:
- ✅ **DO**: Import silent mode utilities at the top: `import { enableSilentMode, disableSilentMode, isSilentMode } from '../../../../scripts/modules/utils.js';`
- ✅ **DO**: Ensure core Task Master functions called from direct functions do **not** pollute `stdout` with console output (banners, spinners, logs) that would break MCP's JSON communication.
- **Preferred**: Modify the core function to accept an `outputFormat: 'json'` parameter and check it internally before printing UI elements. Pass `'json'` from the direct function.
- **Required Fallback/Guarantee**: If the core function cannot be modified or its output suppression is unreliable, **wrap the core function call** within the direct function using `enableSilentMode()` / `disableSilentMode()` in a `try/finally` block. This guarantees no console output interferes with the MCP response.
- ✅ **DO**: Use `isSilentMode()` function to check global silent mode status if needed (rare in direct functions), NEVER access the global `silentMode` variable directly.
- ❌ **DON'T**: Wrap AI client initialization or AI API calls in `enable/disableSilentMode`; their logging is controlled via the `log` object (passed potentially within the `logWrapper` for core functions).
- ❌ **DON'T**: Assume a core function is silent just because it *should* be. Verify or use the `enable/disableSilentMode` wrapper.
- **Example (Direct Function Guaranteeing Silence and using Log Wrapper)**:
```javascript
export async function coreWrapperDirect(args, log, context = {}) {
const { session } = context;
const tasksPath = findTasksJsonPath(args, log);
// Create the logger wrapper
const logWrapper = { /* ... as defined above ... */ };
enableSilentMode(); // Ensure silence for direct console output
try {
// Call core function, passing wrapper and 'json' format
const result = await coreFunction(
tasksPath,
args.param1,
{ mcpLog: logWrapper, session },
'json' // Explicitly request JSON format if supported
);
return { success: true, data: result };
} catch (error) {
log.error(`Error: ${error.message}`);
// Return standardized error object
return { success: false, error: { /* ... */ } };
} finally {
disableSilentMode(); // Critical: Always disable in finally
}
}
```
7. **Debugging MCP/Core Logic Interaction**:
- ✅ **DO**: If an MCP tool fails with unclear errors (like JSON parsing failures), run the equivalent `task-master` CLI command in the terminal. The CLI often provides more detailed error messages originating from the core logic (e.g., `ReferenceError`, stack traces) that are obscured by the MCP layer.
### Specific Guidelines for AI-Based Direct Functions
Direct functions that interact with AI (e.g., `addTaskDirect`, `expandTaskDirect`) have additional responsibilities:
- **Context Parameter**: These functions receive an additional `context` object as their third parameter. **Critically, this object should only contain `{ session }`**. Do NOT expect or use `reportProgress` from this context.
```javascript
export async function yourAIDirect(args, log, context = {}) {
const { session } = context; // Only expect session
// ...
}
```
- **AI Client Initialization**:
- ✅ **DO**: Use the utilities from [`mcp-server/src/core/utils/ai-client-utils.js`](mdc:mcp-server/src/core/utils/ai-client-utils.js) (e.g., `getAnthropicClientForMCP(session, log)`) to get AI client instances. These correctly use the `session` object to resolve API keys.
- ✅ **DO**: Wrap client initialization in a try/catch block and return a specific `AI_CLIENT_ERROR` on failure.
- **AI Interaction**:
- ✅ **DO**: Build prompts using helper functions where appropriate (e.g., from `ai-prompt-helpers.js`).
- ✅ **DO**: Make the AI API call using appropriate helpers (e.g., `_handleAnthropicStream`). Pass the `log` object to these helpers for internal logging. **Do NOT pass `reportProgress`**.
- ✅ **DO**: Parse the AI response using helpers (e.g., `parseTaskJsonResponse`) and handle parsing errors with a specific code (e.g., `RESPONSE_PARSING_ERROR`).
- **Calling Core Logic**:
- ✅ **DO**: After successful AI interaction, call the relevant core Task Master function (from `scripts/modules/`) if needed (e.g., `addTaskDirect` calls `addTask`).
- ✅ **DO**: Pass necessary data, including potentially the parsed AI results, to the core function.
- ✅ **DO**: If the core function can produce console output, call it with an `outputFormat: 'json'` argument (or similar, depending on the function) to suppress CLI output. Ensure the core function is updated to respect this. Use `enableSilentMode/disableSilentMode` around the core function call as a fallback if `outputFormat` is not supported or insufficient.
- **Progress Indication**:
- ❌ **DON'T**: Call `reportProgress` within the direct function.
- ✅ **DO**: If intermediate progress status is needed *within* the long-running direct function, use standard logging: `log.info('Progress: Processing AI response...')`.
## Tool Definition and Execution
### Tool Structure
MCP tools must follow a specific structure to properly interact with the FastMCP framework:
```javascript
server.addTool({
name: "tool_name", // Use snake_case for tool names
description: "Description of what the tool does",
parameters: z.object({
// Define parameters using Zod
param1: z.string().describe("Parameter description"),
param2: z.number().optional().describe("Optional parameter description"),
// IMPORTANT: For file operations, always include these optional parameters
file: z.string().optional().describe("Path to the tasks file"),
projectRoot: z.string().optional().describe("Root directory of the project (typically derived from session)")
}),
// The execute function is the core of the tool implementation
execute: async (args, context) => {
// Implementation goes here
// Return response in the appropriate format
}
});
```
### Execute Function Signature
The `execute` function receives validated arguments and the FastMCP context:
```javascript
// Standard signature
execute: async (args, context) => {
// Tool implementation
}
// Destructured signature (recommended)
execute: async (args, { log, reportProgress, session }) => {
// Tool implementation
}
```
- **args**: The first parameter contains all the validated parameters defined in the tool's schema.
- **context**: The second parameter is an object containing `{ log, reportProgress, session }` provided by FastMCP.
- ✅ **DO**: Use `{ log, session }` when calling direct functions.
- ⚠️ **WARNING**: Avoid passing `reportProgress` down to direct functions due to client compatibility issues. See Progress Reporting Convention below.
### Standard Tool Execution Pattern
The `execute` method within each MCP tool (in `mcp-server/src/tools/*.js`) should follow this standard pattern:
1. **Log Entry**: Log the start of the tool execution with relevant arguments.
2. **Get Project Root**: Use the `getProjectRootFromSession(session, log)` utility (from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js)) to extract the project root path from the client session. Fall back to `args.projectRoot` if the session doesn't provide a root.
3. **Call Direct Function**: Invoke the corresponding `*Direct` function wrapper (e.g., `listTasksDirect` from [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js)), passing an updated `args` object that includes the resolved `projectRoot`. Crucially, the third argument (context) passed to the direct function should **only include `{ log, session }`**. **Do NOT pass `reportProgress`**.
```javascript
// Example call to a non-AI direct function
const result = await someDirectFunction({ ...args, projectRoot }, log);
// Example call to an AI-based direct function
const resultAI = await someAIDirect({ ...args, projectRoot }, log, { session });
```
4. **Handle Result**: Receive the result object (`{ success, data/error, fromCache }`) from the `*Direct` function.
5. **Format Response**: Pass this result object to the `handleApiResult` utility (from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js)) for standardized MCP response formatting and error handling.
6. **Return**: Return the formatted response object provided by `handleApiResult`.
```javascript
// Example execute method structure for a tool calling an AI-based direct function
import { getProjectRootFromSession, handleApiResult, createErrorResponse } from './utils.js';
import { someAIDirectFunction } from '../core/task-master-core.js';
// ... inside server.addTool({...})
execute: async (args, { log, session }) => { // Note: reportProgress is omitted here
try {
log.info(`Starting AI tool execution with args: ${JSON.stringify(args)}`);
// 1. Get Project Root
let rootFolder = getProjectRootFromSession(session, log);
if (!rootFolder && args.projectRoot) { // Fallback if needed
rootFolder = args.projectRoot;
log.info(`Using project root from args as fallback: ${rootFolder}`);
}
// 2. Call AI-Based Direct Function (passing only log and session in context)
const result = await someAIDirectFunction({
...args,
projectRoot: rootFolder // Ensure projectRoot is explicitly passed
}, log, { session }); // Pass session here, NO reportProgress
// 3. Handle and Format Response
return handleApiResult(result, log);
} catch (error) {
log.error(`Error during AI tool execution: ${error.message}`);
return createErrorResponse(error.message);
}
}
```
### Using AsyncOperationManager for Background Tasks
For tools that execute potentially long-running operations *where the AI call is just one part* (e.g., `expand-task`, `update`), use the AsyncOperationManager. The `add-task` command, as refactored, does *not* require this in the MCP tool layer because the direct function handles the primary AI work and returns the final result synchronously from the perspective of the MCP tool.
For tools that *do* use `AsyncOperationManager`:
```javascript
import { AsyncOperationManager } from '../utils/async-operation-manager.js'; // Correct path assuming utils location
import { getProjectRootFromSession, createContentResponse, createErrorResponse } from './utils.js';
import { someIntensiveDirect } from '../core/task-master-core.js';
// ... inside server.addTool({...})
execute: async (args, { log, session }) => { // Note: reportProgress omitted
try {
log.info(`Starting background operation with args: ${JSON.stringify(args)}`);
// 1. Get Project Root
let rootFolder = getProjectRootFromSession(session, log);
if (!rootFolder && args.projectRoot) {
rootFolder = args.projectRoot;
log.info(`Using project root from args as fallback: ${rootFolder}`);
}
// Create operation description
const operationDescription = `Expanding task ${args.id}...`; // Example
// 2. Start async operation using AsyncOperationManager
const operation = AsyncOperationManager.createOperation(
operationDescription,
async (reportProgressCallback) => { // This callback is provided by AsyncOperationManager
// This runs in the background
try {
// Report initial progress *from the manager's callback*
reportProgressCallback({ progress: 0, status: 'Starting operation...' });
// Call the direct function (passing only session context)
const result = await someIntensiveDirect(
{ ...args, projectRoot: rootFolder },
log,
{ session } // Pass session, NO reportProgress
);
// Report final progress *from the manager's callback*
reportProgressCallback({
progress: 100,
status: result.success ? 'Operation completed' : 'Operation failed',
result: result.data, // Include final data if successful
error: result.error // Include error object if failed
});
return result; // Return the direct function's result
} catch (error) {
// Handle errors within the async task
reportProgressCallback({
progress: 100,
status: 'Operation failed critically',
error: { message: error.message, code: error.code || 'ASYNC_OPERATION_FAILED' }
});
throw error; // Re-throw for the manager to catch
}
}
);
// 3. Return immediate response with operation ID
return {
status: 202, // StatusCodes.ACCEPTED
body: {
success: true,
message: 'Operation started',
operationId: operation.id
}
};
} catch (error) {
log.error(`Error starting background operation: ${error.message}`);
return createErrorResponse(`Failed to start operation: ${error.message}`); // Use standard error response
}
}
```
### Project Initialization Tool
The `initialize_project` tool allows integrated clients like Cursor to set up a new Task Master project:
```javascript
// In initialize-project.js
import { z } from "zod";
import { initializeProjectDirect } from "../core/task-master-core.js";
import { handleApiResult, createErrorResponse } from "./utils.js";
export function registerInitializeProjectTool(server) {
server.addTool({
name: "initialize_project",
description: "Initialize a new Task Master project",
parameters: z.object({
projectName: z.string().optional().describe("The name for the new project"),
projectDescription: z.string().optional().describe("A brief description"),
projectVersion: z.string().optional().describe("Initial version (e.g., '0.1.0')"),
authorName: z.string().optional().describe("The author's name"),
skipInstall: z.boolean().optional().describe("Skip installing dependencies"),
addAliases: z.boolean().optional().describe("Add shell aliases"),
yes: z.boolean().optional().describe("Skip prompts and use defaults")
}),
execute: async (args, { log, reportProgress }) => {
try {
// Since we're initializing, we don't need project root
const result = await initializeProjectDirect(args, log);
return handleApiResult(result, log, 'Error initializing project');
} catch (error) {
log.error(`Error in initialize_project: ${error.message}`);
return createErrorResponse(`Failed to initialize project: ${error.message}`);
}
}
});
}
```
### Logging Convention
The `log` object (destructured from `context`) provides standardized logging methods. Use it within both the `execute` method and the `*Direct` functions. **If progress indication is needed within a direct function, use `log.info()` instead of `reportProgress`**.
```javascript
// Proper logging usage
log.info(`Starting ${toolName} with parameters: ${JSON.stringify(sanitizedArgs)}`);
log.debug("Detailed operation info", { data });
log.warn("Potential issue detected");
log.error(`Error occurred: ${error.message}`, { stack: error.stack });
log.info('Progress: 50% - AI call initiated...'); // Example progress logging
```
### Progress Reporting Convention
- ⚠️ **DEPRECATED within Direct Functions**: The `reportProgress` function passed in the `context` object should **NOT** be called from within `*Direct` functions. Doing so can cause client-side validation errors due to missing/incorrect `progressToken` handling.
- ✅ **DO**: For tools using `AsyncOperationManager`, use the `reportProgressCallback` function *provided by the manager* within the background task definition (as shown in the `AsyncOperationManager` example above) to report progress updates for the *overall operation*.
- ✅ **DO**: If finer-grained progress needs to be indicated *during* the execution of a `*Direct` function (whether called directly or via `AsyncOperationManager`), use `log.info()` statements (e.g., `log.info('Progress: Parsing AI response...')`).
### Session Usage Convention
The `session` object (destructured from `context`) contains authenticated session data and client information.
- **Authentication**: Access user-specific data (`session.userId`, etc.) if authentication is implemented.
- **Project Root**: The primary use in Task Master is accessing `session.roots` to determine the client's project root directory via the `getProjectRootFromSession` utility (from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js)). See the Standard Tool Execution Pattern above.
- **Environment Variables**: The `session.env` object is critical for AI tools. Pass the `session` object to the `*Direct` function's context, and then to AI client utility functions (like `getAnthropicClientForMCP`) which will extract API keys and other relevant environment settings (e.g., `MODEL`, `MAX_TOKENS`) from `session.env`.
- **Capabilities**: Can be used to check client capabilities (`session.clientCapabilities`).
## Direct Function Wrappers (`*Direct`)
These functions, located in `mcp-server/src/core/direct-functions/`, form the core logic execution layer for MCP tools.
- **Purpose**: Bridge MCP tools and core Task Master modules (`scripts/modules/*`). Handle AI interactions if applicable.
- **Responsibilities**:
- Receive `args` (including the `projectRoot` determined by the tool), `log` object, and optionally a `context` object (containing **only `{ session }` if needed).
- **Find `tasks.json`**: Use `findTasksJsonPath(args, log)` from [`core/utils/path-utils.js`](mdc:mcp-server/src/core/utils/path-utils.js).
- Validate arguments specific to the core logic.
- **Handle AI Logic (if applicable)**: Initialize AI clients (using `session` from context), build prompts, make AI calls, parse responses.
- **Implement Caching (if applicable)**: Use `getCachedOrExecute` from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) for read operations.
- **Call Core Logic**: Call the underlying function from the core Task Master modules, passing necessary data (including AI results if applicable).
- ✅ **DO**: Pass `outputFormat: 'json'` (or similar) to the core function if it might produce console output.
- ✅ **DO**: Wrap the core function call with `enableSilentMode/disableSilentMode` if necessary.
- Handle errors gracefully (AI errors, core logic errors, file errors).
- Return a standardized result object: `{ success: boolean, data?: any, error?: { code: string, message: string }, fromCache?: boolean }`.
- ❌ **DON'T**: Call `reportProgress`. Use `log.info` for progress indication if needed.
## Key Principles
- **Prefer Direct Function Calls**: For optimal performance and error handling, MCP tools should utilize direct function wrappers defined in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js). These wrappers call the underlying logic from the core modules (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
- **Use `executeMCPToolAction`**: This utility function in [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) is the standard wrapper for executing the main logic within an MCP tool's `execute` function. It handles common boilerplate like logging, argument processing, calling the core action (`*Direct` function), and formatting the response.
- **CLI Execution as Fallback**: The `executeTaskMasterCommand` utility in [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) allows executing commands via the CLI (`task-master ...`). This should **only** be used as a fallback if a direct function wrapper is not yet implemented or if a specific command intrinsically requires CLI execution.
- **Centralized Utilities** (See also: [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)):
- Use `findTasksJsonPath` (in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js)) within direct function wrappers to locate the `tasks.json` file consistently.
- **Leverage MCP Utilities**: The file [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) contains essential helpers for MCP tool implementation:
- `getProjectRoot`: Normalizes project paths (used internally by other utils).
- `handleApiResult`: Standardizes handling results from direct function calls (success/error).
- `createContentResponse`/`createErrorResponse`: Formats successful/error MCP responses.
- `processMCPResponseData`: Filters/cleans data for MCP responses (e.g., removing `details`, `testStrategy`). This is the default processor used by `executeMCPToolAction`.
- `executeMCPToolAction`: The primary wrapper function for tool execution logic.
- `executeTaskMasterCommand`: Fallback for executing CLI commands.
- **Caching**: To improve performance for frequently called read operations (like `listTasks`), a caching layer using `lru-cache` is implemented.
- Caching logic should be added *inside* the direct function wrappers in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js) using the `getCachedOrExecute` utility from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
- Generate unique cache keys based on function arguments that define a distinct call.
- Responses will include a `fromCache` flag.
- Cache statistics can be monitored using the `cacheStats` MCP tool (implemented via `getCacheStatsDirect`).
- **Prefer Direct Function Calls**: MCP tools should always call `*Direct` wrappers instead of `executeTaskMasterCommand`.
- **Standardized Execution Flow**: Follow the pattern: MCP Tool -> `getProjectRootFromSession` -> `*Direct` Function -> Core Logic / AI Logic.
- **Path Resolution via Direct Functions**: The `*Direct` function is responsible for finding the exact `tasks.json` path using `findTasksJsonPath`, relying on the `projectRoot` passed in `args`.
- **AI Logic in Direct Functions**: For AI-based tools, the `*Direct` function handles AI client initialization, calls, and parsing, using the `session` object passed in its context.
- **Silent Mode in Direct Functions**: Wrap *core function* calls (from `scripts/modules`) with `enableSilentMode()` and `disableSilentMode()` if they produce console output not handled by `outputFormat`. Do not wrap AI calls.
- **Selective Async Processing**: Use `AsyncOperationManager` in the *MCP Tool layer* for operations involving multiple steps or long waits beyond a single AI call (e.g., file processing + AI call + file writing). Simple AI calls handled entirely within the `*Direct` function (like `addTaskDirect`) may not need it at the tool layer.
- **No `reportProgress` in Direct Functions**: Do not pass or use `reportProgress` within `*Direct` functions. Use `log.info()` for internal progress or report progress from the `AsyncOperationManager` callback in the MCP tool layer.
- **Output Formatting**: Ensure core functions called by `*Direct` functions can suppress CLI output, ideally via an `outputFormat` parameter.
- **Project Initialization**: Use the initialize_project tool for setting up new projects in integrated environments.
- **Centralized Utilities**: Use helpers from `mcp-server/src/tools/utils.js`, `mcp-server/src/core/utils/path-utils.js`, and `mcp-server/src/core/utils/ai-client-utils.js`. See [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc).
- **Caching in Direct Functions**: Caching logic resides *within* the `*Direct` functions using `getCachedOrExecute`.
## Resources and Resource Templates
Resources provide LLMs with static or dynamic data without executing tools.
- **Implementation**: Use `@mcp.resource()` decorator pattern or `server.addResource`/`server.addResourceTemplate` in `mcp-server/src/core/resources/`.
- **Registration**: Register resources during server initialization in [`mcp-server/src/index.js`](mdc:mcp-server/src/index.js).
- **Best Practices**: Organize resources, validate parameters, use consistent URIs, handle errors. See [`fastmcp-core.txt`](docs/fastmcp-core.txt) for underlying SDK details.
*(Self-correction: Removed detailed Resource implementation examples as they were less relevant to the current user focus on tool execution flow and project roots. Kept the overview.)*
## Implementing MCP Support for a Command
Follow these steps to add MCP support for an existing Task Master command (see [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for more detail):
1. **Ensure Core Logic Exists**: Verify the core functionality is implemented and exported from the relevant module in `scripts/modules/`.
2. **Create Direct Wrapper**: In [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js):
- Import the core function.
- Import `getCachedOrExecute` from `../tools/utils.js`.
- Create an `async function yourCommandDirect(args, log)` wrapper.
- Inside the wrapper:
- Determine arguments needed for both the core logic and the cache key (e.g., `tasksPath`, filters). Use `findTasksJsonPath(args, log)` if needed.
- **Generate a unique `cacheKey`** based on the arguments that define a distinct operation (e.g., `\`yourCommand:${tasksPath}:${filter}\``).
- **Define the `coreActionFn`**: An `async` function that contains the actual call to the imported core logic function, handling its specific errors and returning `{ success: true/false, data/error }`.
- **Call `getCachedOrExecute`**:
```javascript
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreActionFn, // The function wrapping the core logic call
log
});
return result; // Returns { success, data/error, fromCache }
```
- Export the wrapper function and add it to the `directFunctions` map.
3. **Create MCP Tool**: In `mcp-server/src/tools/`:
- Create a new file (e.g., `yourCommand.js`).
- Import `z` for parameter schema definition.
- Import `executeMCPToolAction` from [`./utils.js`](mdc:mcp-server/src/tools/utils.js).
- Import the `yourCommandDirect` wrapper function from `../core/task-master-core.js`.
- Implement `registerYourCommandTool(server)`:
- Call `server.addTool`.
- Define `name`, `description`, and `parameters` using `zod`. Include `projectRoot` and `file` as optional parameters if relevant.
- Define the `async execute(args, log)` function.
- Inside `execute`, call `executeMCPToolAction`:
```javascript
return executeMCPToolAction({
actionFn: yourCommandDirect, // The direct function wrapper
args, // Arguments from the tool call
log, // MCP logger instance
actionName: 'Your Command Description', // For logging
// processResult: customProcessor // Optional: if default filtering isn't enough
});
```
4. **Register Tool**: Import and call `registerYourCommandTool` in [`mcp-server/src/tools/index.js`](mdc:mcp-server/src/tools/index.js).
5. **Update `mcp.json`**: Add the new tool definition to the `tools` array in `.cursor/mcp.json`.
1. **Ensure Core Logic Exists**: Verify the core functionality is implemented and exported from the relevant module in `scripts/modules/`. Ensure the core function can suppress console output (e.g., via an `outputFormat` parameter).
2. **Create Direct Function File in `mcp-server/src/core/direct-functions/`**:
- Create a new file (e.g., `your-command.js`) using **kebab-case** naming.
- Import necessary core functions, `findTasksJsonPath`, silent mode utilities, and potentially AI client/prompt utilities.
- Implement `async function yourCommandDirect(args, log, context = {})` using **camelCase** with `Direct` suffix. **Remember `context` should only contain `{ session }` if needed (for AI keys/config).**
- **Path Resolution**: Obtain `tasksPath` using `findTasksJsonPath(args, log)`.
- Parse other `args` and perform necessary validation.
- **Handle AI (if applicable)**: Initialize clients using `get*ClientForMCP(session, log)`, build prompts, call AI, parse response. Handle AI-specific errors.
- **Implement Caching (if applicable)**: Use `getCachedOrExecute`.
- **Call Core Logic**:
- Wrap with `enableSilentMode/disableSilentMode` if necessary.
- Pass `outputFormat: 'json'` (or similar) if applicable.
- Handle errors from the core function.
- Format the return as `{ success: true/false, data/error, fromCache?: boolean }`.
- ❌ **DON'T**: Call `reportProgress`.
- Export the wrapper function.
3. **Update `task-master-core.js` with Import/Export**: Import and re-export your `*Direct` function and add it to the `directFunctions` map.
4. **Create MCP Tool (`mcp-server/src/tools/`)**:
- Create a new file (e.g., `your-command.js`) using **kebab-case**.
- Import `zod`, `handleApiResult`, `createErrorResponse`, `getProjectRootFromSession`, and your `yourCommandDirect` function. Import `AsyncOperationManager` if needed.
- Implement `registerYourCommandTool(server)`.
- Define the tool `name` using **snake_case** (e.g., `your_command`).
- Define the `parameters` using `zod`. Include `projectRoot: z.string().optional()`.
- Implement the `async execute(args, { log, session })` method (omitting `reportProgress` from destructuring).
- Get `rootFolder` using `getProjectRootFromSession(session, log)`.
- **Determine Execution Strategy**:
- **If using `AsyncOperationManager`**: Create the operation, call the `*Direct` function from within the async task callback (passing `log` and `{ session }`), report progress *from the callback*, and return the initial `ACCEPTED` response.
- **If calling `*Direct` function synchronously** (like `add-task`): Call `await yourCommandDirect({ ...args, projectRoot }, log, { session });`. Handle the result with `handleApiResult`.
- ❌ **DON'T**: Pass `reportProgress` down to the direct function in either case.
5. **Register Tool**: Import and call `registerYourCommandTool` in `mcp-server/src/tools/index.js`.
6. **Update `mcp.json`**: Add the new tool definition to the `tools` array in `.cursor/mcp.json`.
## Handling Responses
- MCP tools should return data formatted by `createContentResponse` (which stringifies objects) or `createErrorResponse`.
- The `processMCPResponseData` utility automatically removes potentially large fields like `details` and `testStrategy` from task objects before they are returned. This is the default behavior when using `executeMCPToolAction`. If specific fields need to be preserved or different fields removed, a custom `processResult` function can be passed to `executeMCPToolAction`.
- The `handleApiResult` utility (used by `executeMCPToolAction`) now expects the result object from the direct function wrapper to include a `fromCache` boolean flag. This flag is included in the final JSON response sent to the MCP client, nested alongside the actual data (e.g., `{ "fromCache": true, "data": { ... } }`).
- MCP tools should return the object generated by `handleApiResult`.
- `handleApiResult` uses `createContentResponse` or `createErrorResponse` internally.
- `handleApiResult` also uses `processMCPResponseData` by default to filter potentially large fields (`details`, `testStrategy`) from task data. Provide a custom processor function to `handleApiResult` if different filtering is needed.
- The final JSON response sent to the MCP client will include the `fromCache` boolean flag (obtained from the `*Direct` function's result) alongside the actual data (e.g., `{ "fromCache": true, "data": { ... } }` or `{ "fromCache": false, "data": { ... } }`).
## Parameter Type Handling
- **Prefer Direct Function Calls**: For optimal performance and error handling, MCP tools should utilize direct function wrappers defined in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js). These wrappers call the underlying logic from the core modules (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
- **Standard Tool Execution Pattern**:
- The `execute` method within each MCP tool (in `mcp-server/src/tools/*.js`) should:
1. Call the corresponding `*Direct` function wrapper (e.g., `listTasksDirect`) from [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js), passing necessary arguments and the logger.
2. Receive the result object (typically `{ success, data/error, fromCache }`).
3. Pass this result object to the `handleApiResult` utility (from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js)) for standardized response formatting and error handling.
4. Return the formatted response object provided by `handleApiResult`.
- **CLI Execution as Fallback**: The `executeTaskMasterCommand` utility in [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) allows executing commands via the CLI (`task-master ...`). This should **only** be used as a fallback if a direct function wrapper is not yet implemented or if a specific command intrinsically requires CLI execution.
- **Centralized Utilities** (See also: [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)):
- Use `findTasksJsonPath` (in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js)) *within direct function wrappers* to locate the `tasks.json` file consistently.
- **Leverage MCP Utilities**: The file [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js) contains essential helpers for MCP tool implementation:
- `getProjectRoot`: Normalizes project paths.
- `handleApiResult`: Takes the raw result from a `*Direct` function and formats it into a standard MCP success or error response, automatically handling data processing via `processMCPResponseData`. This is called by the tool's `execute` method.
- `createContentResponse`/`createErrorResponse`: Used by `handleApiResult` to format successful/error MCP responses.
- `processMCPResponseData`: Filters/cleans data (e.g., removing `details`, `testStrategy`) before it's sent in the MCP response. Called by `handleApiResult`.
- `getCachedOrExecute`: **Used inside `*Direct` functions** in `task-master-core.js` to implement caching logic.
- `executeTaskMasterCommand`: Fallback for executing CLI commands.
- **Caching**: To improve performance for frequently called read operations (like `listTasks`, `showTask`, `nextTask`), a caching layer using `lru-cache` is implemented.
- **Caching logic resides *within* the direct function wrappers** in [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js) using the `getCachedOrExecute` utility from [`tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
- Generate unique cache keys based on function arguments that define a distinct call (e.g., file path, filters).
- The `getCachedOrExecute` utility handles checking the cache, executing the core logic function on a cache miss, storing the result, and returning the data along with a `fromCache` flag.
- Cache statistics can be monitored using the `cacheStats` MCP tool (implemented via `getCacheStatsDirect`).
- **Caching should generally be applied to read-only operations** that don't modify the `tasks.json` state. Commands like `set-status`, `add-task`, `update-task`, `parse-prd`, `add-dependency` should *not* be cached as they change the underlying data.
**MCP Tool Implementation Checklist**:
1. **Core Logic Verification**:
- [ ] Confirm the core function is properly exported from its module (e.g., `task-manager.js`)
- [ ] Identify all required parameters and their types
2. **Direct Function Wrapper**:
- [ ] Create the `*Direct` function in the appropriate file in `mcp-server/src/core/direct-functions/`
- [ ] Import silent mode utilities and implement them around core function calls
- [ ] Handle all parameter validations and type conversions
- [ ] Implement path resolving for relative paths
- [ ] Add appropriate error handling with standardized error codes
- [ ] Add to imports/exports in `task-master-core.js`
3. **MCP Tool Implementation**:
- [ ] Create new file in `mcp-server/src/tools/` with kebab-case naming
- [ ] Define zod schema for all parameters
- [ ] Implement the `execute` method following the standard pattern
- [ ] Consider using AsyncOperationManager for long-running operations
- [ ] Register tool in `mcp-server/src/tools/index.js`
4. **Testing**:
- [ ] Write unit tests for the direct function wrapper
- [ ] Write integration tests for the MCP tool
## Standard Error Codes
- **Standard Error Codes**: Use consistent error codes across direct function wrappers
- `INPUT_VALIDATION_ERROR`: For missing or invalid required parameters
- `FILE_NOT_FOUND_ERROR`: For file system path issues
- `CORE_FUNCTION_ERROR`: For errors thrown by the core function
- `UNEXPECTED_ERROR`: For all other unexpected errors
- **Error Object Structure**:
```javascript
{
success: false,
error: {
code: 'ERROR_CODE',
message: 'Human-readable error message'
},
fromCache: false
}
```
- **MCP Tool Logging Pattern**:
- ✅ DO: Log the start of execution with arguments (sanitized if sensitive)
- ✅ DO: Log successful completion with result summary
- ✅ DO: Log all error conditions with appropriate log levels
- ✅ DO: Include the cache status in result logs
- ❌ DON'T: Log entire large data structures or sensitive information
- The MCP server integrates with Task Master core functions through three layers:
1. Tool Definitions (`mcp-server/src/tools/*.js`) - Define parameters and validation
2. Direct Functions (`mcp-server/src/core/direct-functions/*.js`) - Handle core logic integration
3. Core Functions (`scripts/modules/*.js`) - Implement the actual functionality
- This layered approach provides:
- Clear separation of concerns
- Consistent parameter validation
- Centralized error handling
- Performance optimization through caching (for read operations)
- Standardized response formatting
## MCP Naming Conventions
- **Files and Directories**:
- ✅ DO: Use **kebab-case** for all file names: `list-tasks.js`, `set-task-status.js`
- ✅ DO: Use consistent directory structure: `mcp-server/src/tools/` for tool definitions, `mcp-server/src/core/direct-functions/` for direct function implementations
- **JavaScript Functions**:
- ✅ DO: Use **camelCase** with `Direct` suffix for direct function implementations: `listTasksDirect`, `setTaskStatusDirect`
- ✅ DO: Use **camelCase** with `Tool` suffix for tool registration functions: `registerListTasksTool`, `registerSetTaskStatusTool`
- ✅ DO: Use consistent action function naming inside direct functions: `coreActionFn` or similar descriptive name
- **MCP Tool Names**:
- ✅ DO: Use **snake_case** for tool names exposed to MCP clients: `list_tasks`, `set_task_status`, `parse_prd_document`
- ✅ DO: Include the core action in the tool name without redundant words: Use `list_tasks` instead of `list_all_tasks`
- **Examples**:
- File: `list-tasks.js`
- Direct Function: `listTasksDirect`
- Tool Registration: `registerListTasksTool`
- MCP Tool Name: `list_tasks`
- **Mapping**:
- The `directFunctions` map in `task-master-core.js` maps the core function name (in camelCase) to its direct implementation:
```javascript
export const directFunctions = {
list: listTasksDirect,
setStatus: setTaskStatusDirect,
// Add more functions as implemented
};
```

View File

@@ -31,6 +31,165 @@ The standard pattern for adding a feature follows this workflow:
5. **Configuration**: Update any configuration in [`utils.js`](mdc:scripts/modules/utils.js) if needed, following [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc).
6. **Documentation**: Update help text and documentation in [dev_workflow.mdc](mdc:scripts/modules/dev_workflow.mdc)
## Critical Checklist for New Features
- **Comprehensive Function Exports**:
- ✅ **DO**: Export **all core functions, helper functions (like `generateSubtaskPrompt`), and utility methods** needed by your new function or command from their respective modules.
- ✅ **DO**: **Explicitly review the module's `export { ... }` block** at the bottom of the file to ensure every required dependency (even seemingly minor helpers like `findTaskById`, `taskExists`, specific prompt generators, AI call handlers, etc.) is included.
- ❌ **DON'T**: Assume internal functions are already exported - **always verify**. A missing export will cause runtime errors (e.g., `ReferenceError: generateSubtaskPrompt is not defined`).
- **Example**: If implementing a feature that checks task existence, ensure the helper function is in exports:
```javascript
// At the bottom of your module file:
export {
// ... existing exports ...
yourNewFunction,
taskExists, // Helper function used by yourNewFunction
findTaskById, // Helper function used by yourNewFunction
generateSubtaskPrompt, // Helper needed by expand/add features
getSubtasksFromAI, // Helper needed by expand/add features
};
```
- **Parameter Completeness and Matching**:
- ✅ **DO**: Pass all required parameters to functions you call within your implementation
- ✅ **DO**: Check function signatures before implementing calls to them
- ✅ **DO**: Verify that direct function parameters match their core function counterparts
- ✅ **DO**: When implementing a direct function for MCP, ensure it only accepts parameters that exist in the core function
- ✅ **DO**: Verify the expected *internal structure* of complex object parameters (like the `mcpLog` object, see mcp.mdc for the required logger wrapper pattern)
- ❌ **DON'T**: Add parameters to direct functions that don't exist in core functions
- ❌ **DON'T**: Assume default parameter values will handle missing arguments
- ❌ **DON'T**: Assume object parameters will work without verifying their required internal structure or methods.
- **Example**: When calling file generation, pass all required parameters:
```javascript
// ✅ DO: Pass all required parameters
await generateTaskFiles(tasksPath, path.dirname(tasksPath));
// ❌ DON'T: Omit required parameters
await generateTaskFiles(tasksPath); // Error - missing outputDir parameter
```
**Example**: Properly match direct function parameters to core function:
```javascript
// Core function signature
async function expandTask(tasksPath, taskId, numSubtasks, useResearch = false, additionalContext = '', options = {}) {
// Implementation...
}
// ✅ DO: Match direct function parameters to core function
export async function expandTaskDirect(args, log, context = {}) {
// Extract only parameters that exist in the core function
const taskId = parseInt(args.id, 10);
const numSubtasks = args.num ? parseInt(args.num, 10) : undefined;
const useResearch = args.research === true;
const additionalContext = args.prompt || '';
// Call core function with matched parameters
const result = await expandTask(
tasksPath,
taskId,
numSubtasks,
useResearch,
additionalContext,
{ mcpLog: log, session: context.session }
);
// Return result
return { success: true, data: result, fromCache: false };
}
// ❌ DON'T: Use parameters that don't exist in the core function
export async function expandTaskDirect(args, log, context = {}) {
// DON'T extract parameters that don't exist in the core function!
const force = args.force === true; // ❌ WRONG - 'force' doesn't exist in core function
// DON'T pass non-existent parameters to core functions
const result = await expandTask(
tasksPath,
args.id,
args.num,
args.research,
args.prompt,
force, // ❌ WRONG - this parameter doesn't exist in the core function
{ mcpLog: log }
);
}
```
- **Consistent File Path Handling**:
- ✅ DO: Use consistent file naming conventions: `task_${id.toString().padStart(3, '0')}.txt`
- ✅ DO: Use `path.join()` for composing file paths
- ✅ DO: Use appropriate file extensions (.txt for tasks, .json for data)
- ❌ DON'T: Hardcode path separators or inconsistent file extensions
- **Example**: Creating file paths for tasks:
```javascript
// ✅ DO: Use consistent file naming and path.join
const taskFileName = path.join(
path.dirname(tasksPath),
`task_${taskId.toString().padStart(3, '0')}.txt`
);
// ❌ DON'T: Use inconsistent naming or string concatenation
const taskFileName = path.dirname(tasksPath) + '/' + taskId + '.md';
```
- **Error Handling and Reporting**:
- ✅ DO: Use structured error objects with code and message properties
- ✅ DO: Include clear error messages identifying the specific problem
- ✅ DO: Handle both function-specific errors and potential file system errors
- ✅ DO: Log errors at appropriate severity levels
- **Example**: Structured error handling in core functions:
```javascript
try {
// Implementation...
} catch (error) {
log('error', `Error removing task: ${error.message}`);
throw {
code: 'REMOVE_TASK_ERROR',
message: error.message,
details: error.stack
};
}
```
- **Silent Mode Implementation**:
- ✅ **DO**: Import all silent mode utilities together:
```javascript
import { enableSilentMode, disableSilentMode, isSilentMode } from '../../../../scripts/modules/utils.js';
```
- ✅ **DO**: Always use `isSilentMode()` function to check global silent mode status, never reference global variables.
- ✅ **DO**: Wrap core function calls **within direct functions** using `enableSilentMode()` and `disableSilentMode()` in a `try/finally` block if the core function might produce console output (like banners, spinners, direct `console.log`s) that isn't reliably controlled by an `outputFormat` parameter.
```javascript
// Direct Function Example:
try {
// Prefer passing 'json' if the core function reliably handles it
const result = await coreFunction(...args, 'json');
// OR, if outputFormat is not enough/unreliable:
// enableSilentMode(); // Enable *before* the call
// const result = await coreFunction(...args);
// disableSilentMode(); // Disable *after* the call (typically in finally)
return { success: true, data: result };
} catch (error) {
log.error(`Error: ${error.message}`);
return { success: false, error: { message: error.message } };
} finally {
// If you used enable/disable, ensure disable is called here
// disableSilentMode();
}
```
- ✅ **DO**: Core functions themselves *should* ideally check `outputFormat === 'text'` before displaying UI elements (banners, spinners, boxes) and use internal logging (`log`/`report`) that respects silent mode. The `enable/disableSilentMode` wrapper in the direct function is a safety net.
- ✅ **DO**: Handle mixed parameter/global silent mode correctly for functions accepting both (less common now, prefer `outputFormat`):
```javascript
// Check both the passed parameter and global silent mode
const isSilent = silentMode || (typeof silentMode === 'undefined' && isSilentMode());
```
- ❌ **DON'T**: Forget to disable silent mode in a `finally` block if you enabled it.
- ❌ **DON'T**: Access the global `silentMode` flag directly.
- **Debugging Strategy**:
- ✅ **DO**: If an MCP tool fails with vague errors (e.g., JSON parsing issues like `Unexpected token ... is not valid JSON`), **try running the equivalent CLI command directly in the terminal** (e.g., `task-master expand --all`). CLI output often provides much more specific error messages (like missing function definitions or stack traces from the core logic) that pinpoint the root cause.
- ❌ **DON'T**: Rely solely on MCP logs if the error is unclear; use the CLI as a complementary debugging tool for core logic issues.
```javascript
// 1. CORE LOGIC: Add function to appropriate module (example in task-manager.js)
/**
@@ -312,48 +471,122 @@ For more information on module structure, see [`MODULE_PLAN.md`](mdc:scripts/mod
## Adding MCP Server Support for Commands
Integrating Task Master commands with the MCP server (for use by tools like Cursor) follows a specific pattern distinct from the CLI command implementation.
Integrating Task Master commands with the MCP server (for use by tools like Cursor) follows a specific pattern distinct from the CLI command implementation, prioritizing performance and reliability.
- **Goal**: Leverage direct function calls for performance and reliability, avoiding CLI overhead.
- **Goal**: Leverage direct function calls to core logic, avoiding CLI overhead.
- **Reference**: See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for full details.
**MCP Integration Workflow**:
1. **Core Logic**: Ensure the command's core logic exists in the appropriate module (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
2. **Direct Function Wrapper**:
- In [`task-master-core.js`](mdc:mcp-server/src/core/task-master-core.js), create an `async function yourCommandDirect(args, log)`.
- This function imports and calls the core logic.
- It uses utilities like `findTasksJsonPath` if needed.
- It handles argument parsing and validation specific to the direct call.
- **Implement Caching (if applicable)**: For read operations that benefit from caching, use the `getCachedOrExecute` utility here to wrap the core logic call. Generate a unique cache key based on relevant arguments.
- It returns a standard `{ success: true/false, data/error, fromCache: boolean }` object.
- Export the function and add it to the `directFunctions` map.
3. **MCP Tool File**:
- Create a new file in `mcp-server/src/tools/` (e.g., `yourCommand.js`).
- Import `zod`, `executeMCPToolAction` from `./utils.js`, and your `yourCommandDirect` function.
- Implement `registerYourCommandTool(server)` which calls `server.addTool`:
- Define the tool `name`, `description`, and `parameters` using `zod`. Include optional `projectRoot` and `file` if relevant, following patterns in existing tools.
- Define the `async execute(args, log)` method for the tool.
- **Crucially**, the `execute` method should primarily call `executeMCPToolAction`:
```javascript
// In mcp-server/src/tools/yourCommand.js
import { executeMCPToolAction } from "./utils.js";
import { yourCommandDirect } from "../core/task-master-core.js";
import { z } from "zod";
1. **Core Logic**: Ensure the command's core logic exists and is exported from the appropriate module (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
2. **Direct Function Wrapper (`mcp-server/src/core/direct-functions/`)**:
- Create a new file (e.g., `your-command.js`) in `mcp-server/src/core/direct-functions/` using **kebab-case** naming.
- Import the core logic function, necessary MCP utilities like **`findTasksJsonPath` from `../utils/path-utils.js`**, and **silent mode utilities**: `import { enableSilentMode, disableSilentMode } from '../../../../scripts/modules/utils.js';`
- Implement an `async function yourCommandDirect(args, log)` using **camelCase** with `Direct` suffix.
- **Path Finding**: Inside this function, obtain the `tasksPath` by calling `const tasksPath = findTasksJsonPath(args, log);`. This relies on `args.projectRoot` (derived from the session) being passed correctly.
- Perform validation on other arguments received in `args`.
- **Implement Silent Mode**: Wrap core function calls with `enableSilentMode()` and `disableSilentMode()` to prevent logs from interfering with JSON responses.
- **If Caching**: Implement caching using `getCachedOrExecute` from `../../tools/utils.js`.
- **If Not Caching**: Directly call the core logic function within a try/catch block.
- Format the return as `{ success: true/false, data/error, fromCache: boolean }`.
- Export the wrapper function.
export function registerYourCommandTool(server) {
server.addTool({
name: "yourCommand",
description: "Description of your command.",
parameters: z.object({ /* zod schema */ }),
async execute(args, log) {
return executeMCPToolAction({
actionFn: yourCommandDirect, // Pass the direct function wrapper
args, log, actionName: "Your Command Description"
3. **Update `task-master-core.js` with Import/Export**: Import and re-export your `*Direct` function and add it to the `directFunctions` map.
4. **Create MCP Tool (`mcp-server/src/tools/`)**:
- Create a new file (e.g., `your-command.js`) using **kebab-case**.
- Import `zod`, `handleApiResult`, `createErrorResponse`, **`getProjectRootFromSession`**, and your `yourCommandDirect` function.
- Implement `registerYourCommandTool(server)`.
- Define the tool `name` using **snake_case** (e.g., `your_command`).
- Define the `parameters` using `zod`. **Crucially, define `projectRoot` as optional**: `projectRoot: z.string().optional().describe(...)`. Include `file` if applicable.
- Implement the standard `async execute(args, { log, reportProgress, session })` method:
- Get `rootFolder` using `getProjectRootFromSession` (with fallback to `args.projectRoot`).
- Call `yourCommandDirect({ ...args, projectRoot: rootFolder }, log)`.
- Pass the result to `handleApiResult(result, log, 'Error Message')`.
5. **Register Tool**: Import and call `registerYourCommandTool` in `mcp-server/src/tools/index.js`.
6. **Update `mcp.json`**: Add the new tool definition to the `tools` array in `.cursor/mcp.json`.
## Implementing Background Operations
For long-running operations that should not block the client, use the AsyncOperationManager:
1. **Identify Background-Appropriate Operations**:
- ✅ **DO**: Use async operations for CPU-intensive tasks like task expansion or PRD parsing
- ✅ **DO**: Consider async operations for tasks that may take more than 1-2 seconds
- ❌ **DON'T**: Use async operations for quick read/status operations
- ❌ **DON'T**: Use async operations when immediate feedback is critical
2. **Use AsyncOperationManager in MCP Tools**:
```javascript
import { asyncOperationManager } from '../core/utils/async-manager.js';
// In execute method:
const operationId = asyncOperationManager.addOperation(
expandTaskDirect, // The direct function to run in background
{ ...args, projectRoot: rootFolder }, // Args to pass to the function
{ log, reportProgress, session } // Context to preserve for the operation
);
// Return immediate response with operation ID
return createContentResponse({
message: "Operation started successfully",
operationId,
status: "pending"
});
```
3. **Implement Progress Reporting**:
- ✅ **DO**: Use the reportProgress function in direct functions:
```javascript
// In your direct function:
if (reportProgress) {
await reportProgress({ progress: 50 }); // 50% complete
}
```
- AsyncOperationManager will forward progress updates to the client
4. **Check Operation Status**:
- Implement a way for clients to check status using the `get_operation_status` MCP tool
- Return appropriate status codes and messages
## Project Initialization
When implementing project initialization commands:
1. **Support Programmatic Initialization**:
- ✅ **DO**: Design initialization to work with both CLI and MCP
- ✅ **DO**: Support non-interactive modes with sensible defaults
- ✅ **DO**: Handle project metadata like name, description, version
- ✅ **DO**: Create necessary files and directories
2. **In MCP Tool Implementation**:
```javascript
// In initialize-project.js MCP tool:
import { z } from "zod";
import { initializeProjectDirect } from "../core/task-master-core.js";
export function registerInitializeProjectTool(server) {
server.addTool({
name: "initialize_project",
description: "Initialize a new Task Master project",
parameters: z.object({
projectName: z.string().optional().describe("The name for the new project"),
projectDescription: z.string().optional().describe("A brief description"),
projectVersion: z.string().optional().describe("Initial version (e.g., '0.1.0')"),
// Add other parameters as needed
}),
execute: async (args, { log, reportProgress, session }) => {
try {
// No need for project root since we're creating a new project
const result = await initializeProjectDirect(args, log);
return handleApiResult(result, log, 'Error initializing project');
} catch (error) {
log.error(`Error in initialize_project: ${error.message}`);
return createErrorResponse(`Failed to initialize project: ${error.message}`);
}
}
});
}
```
4. **Register in Tool Index**: Import and call `registerYourCommandTool` in [`mcp-server/src/tools/index.js`](mdc:mcp-server/src/tools/index.js).
5. **Update `mcp.json`**: Add the tool definition to `.cursor/mcp.json`.

View File

@@ -0,0 +1,353 @@
---
description: Comprehensive reference for Taskmaster MCP tools and CLI commands.
globs: **/*
alwaysApply: true
---
# Taskmaster Tool & Command Reference
This document provides a detailed reference for interacting with Taskmaster, covering both the recommended MCP tools (for integrations like Cursor) and the corresponding `task-master` CLI commands (for direct user interaction or fallback).
**Note:** For interacting with Taskmaster programmatically or via integrated tools, using the **MCP tools is strongly recommended** due to better performance, structured data, and error handling. The CLI commands serve as a user-friendly alternative and fallback. See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for MCP implementation details and [`commands.mdc`](mdc:.cursor/rules/commands.mdc) for CLI implementation guidelines.
**Important:** Several MCP tools involve AI processing and are long-running operations that may take up to a minute to complete. When using these tools, always inform users that the operation is in progress and to wait patiently for results. The AI-powered tools include: `parse_prd`, `analyze_project_complexity`, `update_subtask`, `update_task`, `update`, `expand_all`, `expand_task`, and `add_task`.
---
## Initialization & Setup
### 1. Initialize Project (`init`)
* **MCP Tool:** `initialize_project`
* **CLI Command:** `task-master init [options]`
* **Description:** `Set up the basic Taskmaster file structure and configuration in the current directory for a new project.`
* **Key CLI Options:**
* `--name <name>`: `Set the name for your project in Taskmaster's configuration.`
* `--description <text>`: `Provide a brief description for your project.`
* `--version <version>`: `Set the initial version for your project (e.g., '0.1.0').`
* `-y, --yes`: `Initialize Taskmaster quickly using default settings without interactive prompts.`
* **Usage:** Run this once at the beginning of a new project.
* **MCP Variant Description:** `Set up the basic Taskmaster file structure and configuration in the current directory for a new project by running the 'task-master init' command.`
* **Key MCP Parameters/Options:**
* `projectName`: `Set the name for your project.` (CLI: `--name <name>`)
* `projectDescription`: `Provide a brief description for your project.` (CLI: `--description <text>`)
* `projectVersion`: `Set the initial version for your project (e.g., '0.1.0').` (CLI: `--version <version>`)
* `authorName`: `Author name.` (CLI: `--author <author>`)
* `skipInstall`: `Skip installing dependencies (default: false).` (CLI: `--skip-install`)
* `addAliases`: `Add shell aliases (tm, taskmaster) (default: false).` (CLI: `--aliases`)
* `yes`: `Skip prompts and use defaults/provided arguments (default: false).` (CLI: `-y, --yes`)
* **Usage:** Run this once at the beginning of a new project, typically via an integrated tool like Cursor. Operates on the current working directory of the MCP server.
* **Important:** Once complete, you *MUST* parse a prd in order to generate tasks. There will be no tasks files until then. The next step after initializing should be to create a PRD using the example PRD in scripts/example_prd.txt.
### 2. Parse PRD (`parse_prd`)
* **MCP Tool:** `parse_prd`
* **CLI Command:** `task-master parse-prd [file] [options]`
* **Description:** `Parse a Product Requirements Document (PRD) or text file with Taskmaster to automatically generate an initial set of tasks in tasks.json.`
* **Key Parameters/Options:**
* `input`: `Path to your PRD or requirements text file that Taskmaster should parse for tasks.` (CLI: `[file]` positional or `-i, --input <file>`)
* `output`: `Specify where Taskmaster should save the generated 'tasks.json' file (default: 'tasks/tasks.json').` (CLI: `-o, --output <file>`)
* `numTasks`: `Approximate number of top-level tasks Taskmaster should aim to generate from the document.` (CLI: `-n, --num-tasks <number>`)
* `force`: `Use this to allow Taskmaster to overwrite an existing 'tasks.json' without asking for confirmation.` (CLI: `-f, --force`)
* **Usage:** Useful for bootstrapping a project from an existing requirements document.
* **Notes:** Task Master will strictly adhere to any specific requirements mentioned in the PRD (libraries, database schemas, frameworks, tech stacks, etc.) while filling in any gaps where the PRD isn't fully specified. Tasks are designed to provide the most direct implementation path while avoiding over-engineering.
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress. If the user does not have a PRD, suggest discussing their idea and then use the example PRD in scripts/example_prd.txt as a template for creating the PRD based on their idea, for use with parse-prd.
---
## Task Listing & Viewing
### 3. Get Tasks (`get_tasks`)
* **MCP Tool:** `get_tasks`
* **CLI Command:** `task-master list [options]`
* **Description:** `List your Taskmaster tasks, optionally filtering by status and showing subtasks.`
* **Key Parameters/Options:**
* `status`: `Show only Taskmaster tasks matching this status (e.g., 'pending', 'done').` (CLI: `-s, --status <status>`)
* `withSubtasks`: `Include subtasks indented under their parent tasks in the list.` (CLI: `--with-subtasks`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Get an overview of the project status, often used at the start of a work session.
### 4. Get Next Task (`next_task`)
* **MCP Tool:** `next_task`
* **CLI Command:** `task-master next [options]`
* **Description:** `Ask Taskmaster to show the next available task you can work on, based on status and completed dependencies.`
* **Key Parameters/Options:**
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Identify what to work on next according to the plan.
### 5. Get Task Details (`get_task`)
* **MCP Tool:** `get_task`
* **CLI Command:** `task-master show [id] [options]`
* **Description:** `Display detailed information for a specific Taskmaster task or subtask by its ID.`
* **Key Parameters/Options:**
* `id`: `Required. The ID of the Taskmaster task (e.g., '15') or subtask (e.g., '15.2') you want to view.` (CLI: `[id]` positional or `-i, --id <id>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Understand the full details, implementation notes, and test strategy for a specific task before starting work.
---
## Task Creation & Modification
### 6. Add Task (`add_task`)
* **MCP Tool:** `add_task`
* **CLI Command:** `task-master add-task [options]`
* **Description:** `Add a new task to Taskmaster by describing it; AI will structure it.`
* **Key Parameters/Options:**
* `prompt`: `Required. Describe the new task you want Taskmaster to create (e.g., "Implement user authentication using JWT").` (CLI: `-p, --prompt <text>`)
* `dependencies`: `Specify the IDs of any Taskmaster tasks that must be completed before this new one can start (e.g., '12,14').` (CLI: `-d, --dependencies <ids>`)
* `priority`: `Set the priority for the new task ('high', 'medium', 'low'; default: 'medium').` (CLI: `--priority <priority>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Quickly add newly identified tasks during development.
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 7. Add Subtask (`add_subtask`)
* **MCP Tool:** `add_subtask`
* **CLI Command:** `task-master add-subtask [options]`
* **Description:** `Add a new subtask to a Taskmaster parent task, or convert an existing task into a subtask.`
* **Key Parameters/Options:**
* `id` / `parent`: `Required. The ID of the Taskmaster task that will be the parent.` (MCP: `id`, CLI: `-p, --parent <id>`)
* `taskId`: `Use this if you want to convert an existing top-level Taskmaster task into a subtask of the specified parent.` (CLI: `-i, --task-id <id>`)
* `title`: `Required (if not using taskId). The title for the new subtask Taskmaster should create.` (CLI: `-t, --title <title>`)
* `description`: `A brief description for the new subtask.` (CLI: `-d, --description <text>`)
* `details`: `Provide implementation notes or details for the new subtask.` (CLI: `--details <text>`)
* `dependencies`: `Specify IDs of other tasks or subtasks (e.g., '15', '16.1') that must be done before this new subtask.` (CLI: `--dependencies <ids>`)
* `status`: `Set the initial status for the new subtask (default: 'pending').` (CLI: `-s, --status <status>`)
* `skipGenerate`: `Prevent Taskmaster from automatically regenerating markdown task files after adding the subtask.` (CLI: `--skip-generate`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Break down tasks manually or reorganize existing tasks.
### 8. Update Tasks (`update`)
* **MCP Tool:** `update`
* **CLI Command:** `task-master update [options]`
* **Description:** `Update multiple upcoming tasks in Taskmaster based on new context or changes, starting from a specific task ID.`
* **Key Parameters/Options:**
* `from`: `Required. The ID of the first task Taskmaster should update. All tasks with this ID or higher (and not 'done') will be considered.` (CLI: `--from <id>`)
* `prompt`: `Required. Explain the change or new context for Taskmaster to apply to the tasks (e.g., "We are now using React Query instead of Redux Toolkit for data fetching").` (CLI: `-p, --prompt <text>`)
* `research`: `Enable Taskmaster to use Perplexity AI for more informed updates based on external knowledge (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Handle significant implementation changes or pivots that affect multiple future tasks. Example CLI: `task-master update --from='18' --prompt='Switching to React Query.\nNeed to refactor data fetching...'`
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 9. Update Task (`update_task`)
* **MCP Tool:** `update_task`
* **CLI Command:** `task-master update-task [options]`
* **Description:** `Modify a specific Taskmaster task (or subtask) by its ID, incorporating new information or changes.`
* **Key Parameters/Options:**
* `id`: `Required. The specific ID of the Taskmaster task (e.g., '15') or subtask (e.g., '15.2') you want to update.` (CLI: `-i, --id <id>`)
* `prompt`: `Required. Explain the specific changes or provide the new information Taskmaster should incorporate into this task.` (CLI: `-p, --prompt <text>`)
* `research`: `Enable Taskmaster to use Perplexity AI for more informed updates (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Refine a specific task based on new understanding or feedback. Example CLI: `task-master update-task --id='15' --prompt='Clarification: Use PostgreSQL instead of MySQL.\nUpdate schema details...'`
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 10. Update Subtask (`update_subtask`)
* **MCP Tool:** `update_subtask`
* **CLI Command:** `task-master update-subtask [options]`
* **Description:** `Append timestamped notes or details to a specific Taskmaster subtask without overwriting existing content. Intended for iterative implementation logging.`
* **Key Parameters/Options:**
* `id`: `Required. The specific ID of the Taskmaster subtask (e.g., '15.2') you want to add information to.` (CLI: `-i, --id <id>`)
* `prompt`: `Required. Provide the information or notes Taskmaster should append to the subtask's details. Ensure this adds *new* information not already present.` (CLI: `-p, --prompt <text>`)
* `research`: `Enable Taskmaster to use Perplexity AI for more informed updates (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Add implementation notes, code snippets, or clarifications to a subtask during development. Before calling, review the subtask's current details to append only fresh insights, helping to build a detailed log of the implementation journey and avoid redundancy. Example CLI: `task-master update-subtask --id='15.2' --prompt='Discovered that the API requires header X.\nImplementation needs adjustment...'`
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 11. Set Task Status (`set_task_status`)
* **MCP Tool:** `set_task_status`
* **CLI Command:** `task-master set-status [options]`
* **Description:** `Update the status of one or more Taskmaster tasks or subtasks (e.g., 'pending', 'in-progress', 'done').`
* **Key Parameters/Options:**
* `id`: `Required. The ID(s) of the Taskmaster task(s) or subtask(s) (e.g., '15', '15.2', '16,17.1') to update.` (CLI: `-i, --id <id>`)
* `status`: `Required. The new status to set (e.g., 'done', 'pending', 'in-progress', 'review', 'cancelled').` (CLI: `-s, --status <status>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Mark progress as tasks move through the development cycle.
### 12. Remove Task (`remove_task`)
* **MCP Tool:** `remove_task`
* **CLI Command:** `task-master remove-task [options]`
* **Description:** `Permanently remove a task or subtask from the Taskmaster tasks list.`
* **Key Parameters/Options:**
* `id`: `Required. The ID of the Taskmaster task (e.g., '5') or subtask (e.g., '5.2') to permanently remove.` (CLI: `-i, --id <id>`)
* `yes`: `Skip the confirmation prompt and immediately delete the task.` (CLI: `-y, --yes`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Permanently delete tasks or subtasks that are no longer needed in the project.
* **Notes:** Use with caution as this operation cannot be undone. Consider using 'blocked', 'cancelled', or 'deferred' status instead if you just want to exclude a task from active planning but keep it for reference. The command automatically cleans up dependency references in other tasks.
---
## Task Structure & Breakdown
### 13. Expand Task (`expand_task`)
* **MCP Tool:** `expand_task`
* **CLI Command:** `task-master expand [options]`
* **Description:** `Use Taskmaster's AI to break down a complex task (or all tasks) into smaller, manageable subtasks.`
* **Key Parameters/Options:**
* `id`: `The ID of the specific Taskmaster task you want to break down into subtasks.` (CLI: `-i, --id <id>`)
* `num`: `Suggests how many subtasks Taskmaster should aim to create (uses complexity analysis by default).` (CLI: `-n, --num <number>`)
* `research`: `Enable Taskmaster to use Perplexity AI for more informed subtask generation (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `prompt`: `Provide extra context or specific instructions to Taskmaster for generating the subtasks.` (CLI: `-p, --prompt <text>`)
* `force`: `Use this to make Taskmaster replace existing subtasks with newly generated ones.` (CLI: `--force`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Generate a detailed implementation plan for a complex task before starting coding.
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 14. Expand All Tasks (`expand_all`)
* **MCP Tool:** `expand_all`
* **CLI Command:** `task-master expand --all [options]` (Note: CLI uses the `expand` command with the `--all` flag)
* **Description:** `Tell Taskmaster to automatically expand all 'pending' tasks based on complexity analysis.`
* **Key Parameters/Options:**
* `num`: `Suggests how many subtasks Taskmaster should aim to create per task.` (CLI: `-n, --num <number>`)
* `research`: `Enable Perplexity AI for more informed subtask generation (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `prompt`: `Provide extra context for Taskmaster to apply generally during expansion.` (CLI: `-p, --prompt <text>`)
* `force`: `Make Taskmaster replace existing subtasks.` (CLI: `--force`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Useful after initial task generation or complexity analysis to break down multiple tasks at once.
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 15. Clear Subtasks (`clear_subtasks`)
* **MCP Tool:** `clear_subtasks`
* **CLI Command:** `task-master clear-subtasks [options]`
* **Description:** `Remove all subtasks from one or more specified Taskmaster parent tasks.`
* **Key Parameters/Options:**
* `id`: `The ID(s) of the Taskmaster parent task(s) whose subtasks you want to remove (e.g., '15', '16,18').` (Required unless using `all`) (CLI: `-i, --id <ids>`)
* `all`: `Tell Taskmaster to remove subtasks from all parent tasks.` (CLI: `--all`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Used before regenerating subtasks with `expand_task` if the previous breakdown needs replacement.
### 16. Remove Subtask (`remove_subtask`)
* **MCP Tool:** `remove_subtask`
* **CLI Command:** `task-master remove-subtask [options]`
* **Description:** `Remove a subtask from its Taskmaster parent, optionally converting it into a standalone task.`
* **Key Parameters/Options:**
* `id`: `Required. The ID(s) of the Taskmaster subtask(s) to remove (e.g., '15.2', '16.1,16.3').` (CLI: `-i, --id <id>`)
* `convert`: `If used, Taskmaster will turn the subtask into a regular top-level task instead of deleting it.` (CLI: `-c, --convert`)
* `skipGenerate`: `Prevent Taskmaster from automatically regenerating markdown task files after removing the subtask.` (CLI: `--skip-generate`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Delete unnecessary subtasks or promote a subtask to a top-level task.
---
## Dependency Management
### 17. Add Dependency (`add_dependency`)
* **MCP Tool:** `add_dependency`
* **CLI Command:** `task-master add-dependency [options]`
* **Description:** `Define a dependency in Taskmaster, making one task a prerequisite for another.`
* **Key Parameters/Options:**
* `id`: `Required. The ID of the Taskmaster task that will depend on another.` (CLI: `-i, --id <id>`)
* `dependsOn`: `Required. The ID of the Taskmaster task that must be completed first (the prerequisite).` (CLI: `-d, --depends-on <id>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Establish the correct order of execution between tasks.
### 18. Remove Dependency (`remove_dependency`)
* **MCP Tool:** `remove_dependency`
* **CLI Command:** `task-master remove-dependency [options]`
* **Description:** `Remove a dependency relationship between two Taskmaster tasks.`
* **Key Parameters/Options:**
* `id`: `Required. The ID of the Taskmaster task you want to remove a prerequisite from.` (CLI: `-i, --id <id>`)
* `dependsOn`: `Required. The ID of the Taskmaster task that should no longer be a prerequisite.` (CLI: `-d, --depends-on <id>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Update task relationships when the order of execution changes.
### 19. Validate Dependencies (`validate_dependencies`)
* **MCP Tool:** `validate_dependencies`
* **CLI Command:** `task-master validate-dependencies [options]`
* **Description:** `Check your Taskmaster tasks for dependency issues (like circular references or links to non-existent tasks) without making changes.`
* **Key Parameters/Options:**
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Audit the integrity of your task dependencies.
### 20. Fix Dependencies (`fix_dependencies`)
* **MCP Tool:** `fix_dependencies`
* **CLI Command:** `task-master fix-dependencies [options]`
* **Description:** `Automatically fix dependency issues (like circular references or links to non-existent tasks) in your Taskmaster tasks.`
* **Key Parameters/Options:**
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Clean up dependency errors automatically.
---
## Analysis & Reporting
### 21. Analyze Project Complexity (`analyze_project_complexity`)
* **MCP Tool:** `analyze_project_complexity`
* **CLI Command:** `task-master analyze-complexity [options]`
* **Description:** `Have Taskmaster analyze your tasks to determine their complexity and suggest which ones need to be broken down further.`
* **Key Parameters/Options:**
* `output`: `Where to save the complexity analysis report (default: 'scripts/task-complexity-report.json').` (CLI: `-o, --output <file>`)
* `threshold`: `The minimum complexity score (1-10) that should trigger a recommendation to expand a task.` (CLI: `-t, --threshold <number>`)
* `research`: `Enable Perplexity AI for more accurate complexity analysis (requires PERPLEXITY_API_KEY).` (CLI: `-r, --research`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Used before breaking down tasks to identify which ones need the most attention.
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
### 22. View Complexity Report (`complexity_report`)
* **MCP Tool:** `complexity_report`
* **CLI Command:** `task-master complexity-report [options]`
* **Description:** `Display the task complexity analysis report in a readable format.`
* **Key Parameters/Options:**
* `file`: `Path to the complexity report (default: 'scripts/task-complexity-report.json').` (CLI: `-f, --file <file>`)
* **Usage:** Review and understand the complexity analysis results after running analyze-complexity.
---
## File Management
### 23. Generate Task Files (`generate`)
* **MCP Tool:** `generate`
* **CLI Command:** `task-master generate [options]`
* **Description:** `Create or update individual Markdown files for each task based on your tasks.json.`
* **Key Parameters/Options:**
* `output`: `The directory where Taskmaster should save the task files (default: in a 'tasks' directory).` (CLI: `-o, --output <directory>`)
* `file`: `Path to your Taskmaster 'tasks.json' file (default relies on auto-detection).` (CLI: `-f, --file <file>`)
* **Usage:** Run this after making changes to tasks.json to keep individual task files up to date.
---
## Environment Variables Configuration
Taskmaster's behavior can be customized via environment variables. These affect both CLI and MCP server operation:
* **ANTHROPIC_API_KEY** (Required): Your Anthropic API key for Claude.
* **MODEL**: Claude model to use (default: `claude-3-opus-20240229`).
* **MAX_TOKENS**: Maximum tokens for AI responses (default: 8192).
* **TEMPERATURE**: Temperature for AI model responses (default: 0.7).
* **DEBUG**: Enable debug logging (`true`/`false`, default: `false`).
* **LOG_LEVEL**: Console output level (`debug`, `info`, `warn`, `error`, default: `info`).
* **DEFAULT_SUBTASKS**: Default number of subtasks for `expand` (default: 5).
* **DEFAULT_PRIORITY**: Default priority for new tasks (default: `medium`).
* **PROJECT_NAME**: Project name used in metadata.
* **PROJECT_VERSION**: Project version used in metadata.
* **PERPLEXITY_API_KEY**: API key for Perplexity AI (for `--research` flags).
* **PERPLEXITY_MODEL**: Perplexity model to use (default: `sonar-medium-online`).
Set these in your `.env` file in the project root or in your environment before running Taskmaster.
---
For implementation details:
* CLI commands: See [`commands.mdc`](mdc:.cursor/rules/commands.mdc)
* MCP server: See [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)
* Task structure: See [`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)
* Workflow: See [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)

View File

@@ -5,6 +5,8 @@ globs: "**/*.test.js,tests/**/*"
# Testing Guidelines for Task Master CLI
*Note:* Never use asynchronous operations in tests. Always mock tests properly based on the way the tested functions are defined and used. Do not arbitrarily create tests. Based them on the low-level details and execution of the underlying code being tested.
## Test Organization Structure
- **Unit Tests** (See [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for module breakdown)
@@ -88,6 +90,122 @@ describe('Feature or Function Name', () => {
});
```
## Commander.js Command Testing Best Practices
When testing CLI commands built with Commander.js, several special considerations must be made to avoid common pitfalls:
- **Direct Action Handler Testing**
- ✅ **DO**: Test the command action handlers directly rather than trying to mock the entire Commander.js chain
- ✅ **DO**: Create simplified test-specific implementations of command handlers that match the original behavior
- ✅ **DO**: Explicitly handle all options, including defaults and shorthand flags (e.g., `-p` for `--prompt`)
- ✅ **DO**: Include null/undefined checks in test implementations for parameters that might be optional
- ✅ **DO**: Use fixtures from `tests/fixtures/` for consistent sample data across tests
```javascript
// ✅ DO: Create a simplified test version of the command handler
const testAddTaskAction = async (options) => {
options = options || {}; // Ensure options aren't undefined
// Validate parameters
const isManualCreation = options.title && options.description;
const prompt = options.prompt || options.p; // Handle shorthand flags
if (!prompt && !isManualCreation) {
throw new Error('Expected error message');
}
// Call the mocked task manager
return mockTaskManager.addTask(/* parameters */);
};
test('should handle required parameters correctly', async () => {
// Call the test implementation directly
await expect(async () => {
await testAddTaskAction({ file: 'tasks.json' });
}).rejects.toThrow('Expected error message');
});
```
- **Commander Chain Mocking (If Necessary)**
- ✅ **DO**: Mock ALL chainable methods (`option`, `argument`, `action`, `on`, etc.)
- ✅ **DO**: Return `this` (or the mock object) from all chainable method mocks
- ✅ **DO**: Remember to mock not only the initial object but also all objects returned by methods
- ✅ **DO**: Implement a mechanism to capture the action handler for direct testing
```javascript
// If you must mock the Commander.js chain:
const mockCommand = {
command: jest.fn().mockReturnThis(),
description: jest.fn().mockReturnThis(),
option: jest.fn().mockReturnThis(),
argument: jest.fn().mockReturnThis(), // Don't forget this one
action: jest.fn(fn => {
actionHandler = fn; // Capture the handler for testing
return mockCommand;
}),
on: jest.fn().mockReturnThis() // Don't forget this one
};
```
- **Parameter Handling**
- ✅ **DO**: Check for both main flag and shorthand flags (e.g., `prompt` and `p`)
- ✅ **DO**: Handle parameters like Commander would (comma-separated lists, etc.)
- ✅ **DO**: Set proper default values as defined in the command
- ✅ **DO**: Validate that required parameters are actually required in tests
```javascript
// Parse dependencies like Commander would
const dependencies = options.dependencies
? options.dependencies.split(',').map(id => id.trim())
: [];
```
- **Environment and Session Handling**
- ✅ **DO**: Properly mock session objects when required by functions
- ✅ **DO**: Reset environment variables between tests if modified
- ✅ **DO**: Use a consistent pattern for environment-dependent tests
```javascript
// Session parameter mock pattern
const sessionMock = { session: process.env };
// In test:
expect(mockAddTask).toHaveBeenCalledWith(
expect.any(String),
'Test prompt',
[],
'medium',
sessionMock,
false,
null,
null
);
```
- **Common Pitfalls to Avoid**
- ❌ **DON'T**: Try to use the real action implementation without proper mocking
- ❌ **DON'T**: Mock Commander partially - either mock it completely or test the action directly
- ❌ **DON'T**: Forget to handle optional parameters that may be undefined
- ❌ **DON'T**: Neglect to test shorthand flag functionality (e.g., `-p`, `-r`)
- ❌ **DON'T**: Create circular dependencies in your test mocks
- ❌ **DON'T**: Access variables before initialization in your test implementations
- ❌ **DON'T**: Include actual command execution in unit tests
- ❌ **DON'T**: Overwrite the same file path in multiple tests
```javascript
// ❌ DON'T: Create circular references in mocks
const badMock = {
method: jest.fn().mockImplementation(() => badMock.method())
};
// ❌ DON'T: Access uninitialized variables
const badImplementation = () => {
const result = uninitialized;
let uninitialized = 'value';
return result;
};
```
## Jest Module Mocking Best Practices
- **Mock Hoisting Behavior**
@@ -552,6 +670,102 @@ npm test -- -t "pattern to match"
});
```
## Testing AI Service Integrations
- **DO NOT import real AI service clients**
- ❌ DON'T: Import actual AI clients from their libraries
- ✅ DO: Create fully mocked versions that return predictable responses
```javascript
// ❌ DON'T: Import and instantiate real AI clients
import { Anthropic } from '@anthropic-ai/sdk';
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
// ✅ DO: Mock the entire module with controlled behavior
jest.mock('@anthropic-ai/sdk', () => ({
Anthropic: jest.fn().mockImplementation(() => ({
messages: {
create: jest.fn().mockResolvedValue({
content: [{ type: 'text', text: 'Mocked AI response' }]
})
}
}))
}));
```
- **DO NOT rely on environment variables for API keys**
- ❌ DON'T: Assume environment variables are set in tests
- ✅ DO: Set mock environment variables in test setup
```javascript
// In tests/setup.js or at the top of test file
process.env.ANTHROPIC_API_KEY = 'test-mock-api-key-for-tests';
process.env.PERPLEXITY_API_KEY = 'test-mock-perplexity-key-for-tests';
```
- **DO NOT use real AI client initialization logic**
- ❌ DON'T: Use code that attempts to initialize or validate real AI clients
- ✅ DO: Create test-specific paths that bypass client initialization
```javascript
// ❌ DON'T: Test functions that require valid AI client initialization
// This will fail without proper API keys or network access
test('should use AI client', async () => {
const result = await functionThatInitializesAIClient();
expect(result).toBeDefined();
});
// ✅ DO: Test with bypassed initialization or manual task paths
test('should handle manual task creation without AI', () => {
// Using a path that doesn't require AI client initialization
const result = addTaskDirect({
title: 'Manual Task',
description: 'Test Description'
}, mockLogger);
expect(result.success).toBe(true);
});
```
## Testing Asynchronous Code
- **DO NOT rely on asynchronous operations in tests**
- ❌ DON'T: Use real async/await or Promise resolution in tests
- ✅ DO: Make all mocks return synchronous values when possible
```javascript
// ❌ DON'T: Use real async functions that might fail unpredictably
test('should handle async operation', async () => {
const result = await realAsyncFunction(); // Can time out or fail for external reasons
expect(result).toBe(expectedValue);
});
// ✅ DO: Make async operations synchronous in tests
test('should handle operation', () => {
mockAsyncFunction.mockReturnValue({ success: true, data: 'test' });
const result = functionUnderTest();
expect(result).toEqual({ success: true, data: 'test' });
});
```
- **DO NOT test exact error messages**
- ❌ DON'T: Assert on exact error message text that might change
- ✅ DO: Test for error presence and general properties
```javascript
// ❌ DON'T: Test for exact error message text
expect(result.error).toBe('Could not connect to API: Network error');
// ✅ DO: Test for general error properties or message patterns
expect(result.success).toBe(false);
expect(result.error).toContain('Could not connect');
// Or even better:
expect(result).toMatchObject({
success: false,
error: expect.stringContaining('connect')
});
```
## Reliable Testing Techniques
- **Create Simplified Test Functions**
@@ -564,99 +778,125 @@ npm test -- -t "pattern to match"
const setTaskStatus = async (taskId, newStatus) => {
const tasksPath = 'tasks/tasks.json';
const data = await readJSON(tasksPath);
// Update task status logic
// [implementation]
await writeJSON(tasksPath, data);
return data;
return { success: true };
};
// Test-friendly simplified function (easy to test)
const testSetTaskStatus = (tasksData, taskIdInput, newStatus) => {
// Same core logic without file operations
// Update task status logic on provided tasksData object
return tasksData; // Return updated data for assertions
// Test-friendly version (easier to test)
const updateTaskStatus = (tasks, taskId, newStatus) => {
// Pure logic without side effects
const updatedTasks = [...tasks];
const taskIndex = findTaskById(updatedTasks, taskId);
if (taskIndex === -1) return { success: false, error: 'Task not found' };
updatedTasks[taskIndex].status = newStatus;
return { success: true, tasks: updatedTasks };
};
```
- **Avoid Real File System Operations**
- Never write to real files during tests
- Create test-specific versions of file operation functions
- Mock all file system operations including read, write, exists, etc.
- Verify function behavior using the in-memory data structures
```javascript
// Mock file operations
const mockReadJSON = jest.fn();
const mockWriteJSON = jest.fn();
jest.mock('../../scripts/modules/utils.js', () => ({
readJSON: mockReadJSON,
writeJSON: mockWriteJSON,
}));
test('should update task status correctly', () => {
// Setup mock data
const testData = JSON.parse(JSON.stringify(sampleTasks));
mockReadJSON.mockReturnValue(testData);
// Call the function that would normally modify files
const result = testSetTaskStatus(testData, '1', 'done');
// Assert on the in-memory data structure
expect(result.tasks[0].status).toBe('done');
});
```
- **Data Isolation Between Tests**
- Always create fresh copies of test data for each test
- Use `JSON.parse(JSON.stringify(original))` for deep cloning
- Reset all mocks before each test with `jest.clearAllMocks()`
- Avoid state that persists between tests
```javascript
beforeEach(() => {
jest.clearAllMocks();
// Deep clone the test data
testTasksData = JSON.parse(JSON.stringify(sampleTasks));
});
```
- **Test All Path Variations**
- Regular tasks and subtasks
- Single items and multiple items
- Success paths and error paths
- Edge cases (empty data, invalid inputs, etc.)
```javascript
// Multiple test cases covering different scenarios
test('should update regular task status', () => {
/* test implementation */
});
test('should update subtask status', () => {
/* test implementation */
});
test('should update multiple tasks when given comma-separated IDs', () => {
/* test implementation */
});
test('should throw error for non-existent task ID', () => {
/* test implementation */
});
```
- **Stabilize Tests With Predictable Input/Output**
- Use consistent, predictable test fixtures
- Avoid random values or time-dependent data
- Make tests deterministic for reliable CI/CD
- Control all variables that might affect test outcomes
```javascript
// Use a specific known date instead of current date
const fixedDate = new Date('2023-01-01T12:00:00Z');
jest.spyOn(global, 'Date').mockImplementation(() => fixedDate);
```
See [tests/README.md](mdc:tests/README.md) for more details on the testing approach.
Refer to [jest.config.js](mdc:jest.config.js) for Jest configuration options.
## Variable Hoisting and Module Initialization Issues
When testing ES modules or working with complex module imports, you may encounter variable hoisting and initialization issues. These can be particularly tricky to debug and often appear as "Cannot access 'X' before initialization" errors.
- **Understanding Module Initialization Order**
- ✅ **DO**: Declare and initialize global variables at the top of modules
- ✅ **DO**: Use proper function declarations to avoid hoisting issues
- ✅ **DO**: Initialize variables before they are referenced, especially in imported modules
- ✅ **DO**: Be aware that imports are hoisted to the top of the file
```javascript
// ✅ DO: Define global state variables at the top of the module
let silentMode = false; // Declare and initialize first
const CONFIG = { /* configuration */ };
function isSilentMode() {
return silentMode; // Reference variable after it's initialized
}
function log(level, message) {
if (isSilentMode()) return; // Use the function instead of accessing variable directly
// ...
}
```
- **Testing Modules with Initialization-Dependent Functions**
- ✅ **DO**: Create test-specific implementations that initialize all variables correctly
- ✅ **DO**: Use factory functions in mocks to ensure proper initialization order
- ✅ **DO**: Be careful with how you mock or stub functions that depend on module state
```javascript
// ✅ DO: Test-specific implementation that avoids initialization issues
const testLog = (level, ...args) => {
// Local implementation with proper initialization
const isSilent = false; // Explicit initialization
if (isSilent) return;
// Test implementation...
};
```
- **Common Hoisting-Related Errors to Avoid**
- ❌ **DON'T**: Reference variables before their declaration in module scope
- ❌ **DON'T**: Create circular dependencies between modules
- ❌ **DON'T**: Rely on variable initialization order across module boundaries
- ❌ **DON'T**: Define functions that use hoisted variables before they're initialized
```javascript
// ❌ DON'T: Create reference-before-initialization patterns
function badFunction() {
if (silentMode) { /* ... */ } // ReferenceError if silentMode is declared later
}
let silentMode = false;
// ❌ DON'T: Create cross-module references that depend on initialization order
// module-a.js
import { getSetting } from './module-b.js';
export const config = { value: getSetting() };
// module-b.js
import { config } from './module-a.js';
export function getSetting() {
return config.value; // Circular dependency causing initialization issues
}
```
- **Dynamic Imports as a Solution**
- ✅ **DO**: Use dynamic imports (`import()`) to avoid initialization order issues
- ✅ **DO**: Structure modules to avoid circular dependencies that cause initialization issues
- ✅ **DO**: Consider factory functions for modules with complex state
```javascript
// ✅ DO: Use dynamic imports to avoid initialization issues
async function getTaskManager() {
return import('./task-manager.js');
}
async function someFunction() {
const taskManager = await getTaskManager();
return taskManager.someMethod();
}
```
- **Testing Approach for Modules with Initialization Issues**
- ✅ **DO**: Create self-contained test implementations rather than using real implementations
- ✅ **DO**: Mock dependencies at module boundaries instead of trying to mock deep dependencies
- ✅ **DO**: Isolate module-specific state in tests
```javascript
// ✅ DO: Create isolated test implementation instead of reusing module code
test('should log messages when not in silent mode', () => {
// Local test implementation instead of importing from module
const testLog = (level, message) => {
if (false) return; // Always non-silent for this test
mockConsole(level, message);
};
testLog('info', 'test message');
expect(mockConsole).toHaveBeenCalledWith('info', 'test message');
});
```

View File

@@ -44,6 +44,12 @@ alwaysApply: false
}
```
- **Location**:
- **Core CLI Utilities**: Place utilities used primarily by the core `task-master` CLI logic and command modules (`scripts/modules/*`) into [`scripts/modules/utils.js`](mdc:scripts/modules/utils.js).
- **MCP Server Utilities**: Place utilities specifically designed to support the MCP server implementation into the appropriate subdirectories within `mcp-server/src/`.
- Path/Core Logic Helpers: [`mcp-server/src/core/utils/`](mdc:mcp-server/src/core/utils/) (e.g., `path-utils.js`).
- Tool Execution/Response Helpers: [`mcp-server/src/tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
## Documentation Standards
- **JSDoc Format**:
@@ -73,7 +79,7 @@ alwaysApply: false
}
```
## Configuration Management
## Configuration Management (in `scripts/modules/utils.js`)
- **Environment Variables**:
- ✅ DO: Provide default values for all configuration
@@ -84,25 +90,48 @@ alwaysApply: false
```javascript
// ✅ DO: Set up configuration with defaults and environment overrides
const CONFIG = {
model: process.env.MODEL || 'claude-3-7-sonnet-20250219',
model: process.env.MODEL || 'claude-3-opus-20240229', // Updated default model
maxTokens: parseInt(process.env.MAX_TOKENS || '4000'),
temperature: parseFloat(process.env.TEMPERATURE || '0.7'),
debug: process.env.DEBUG === "true",
logLevel: process.env.LOG_LEVEL || "info",
defaultSubtasks: parseInt(process.env.DEFAULT_SUBTASKS || "3"),
defaultPriority: process.env.DEFAULT_PRIORITY || "medium",
projectName: process.env.PROJECT_NAME || "Task Master",
projectVersion: "1.5.0" // Version should be hardcoded
projectName: process.env.PROJECT_NAME || "Task Master Project", // Generic project name
projectVersion: "1.5.0" // Version should be updated via release process
};
```
## Logging Utilities
## Logging Utilities (in `scripts/modules/utils.js`)
- **Log Levels**:
- ✅ DO: Support multiple log levels (debug, info, warn, error)
- ✅ DO: Use appropriate icons for different log levels
- ✅ DO: Respect the configured log level
- ❌ DON'T: Add direct console.log calls outside the logging utility
- **Note on Passed Loggers**: When a logger object (like the FastMCP `log` object) is passed *as a parameter* (e.g., as `mcpLog`) into core Task Master functions, the receiving function often expects specific methods (`.info`, `.warn`, `.error`, etc.) to be directly callable on that object (e.g., `mcpLog[level](...)`). If the passed logger doesn't have this exact structure, a wrapper object may be needed. See the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for the standard pattern used in direct functions.
- **Logger Wrapper Pattern**:
- ✅ DO: Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors:
```javascript
// Standard logWrapper pattern to wrap FastMCP's log object
const logWrapper = {
info: (message, ...args) => log.info(message, ...args),
warn: (message, ...args) => log.warn(message, ...args),
error: (message, ...args) => log.error(message, ...args),
debug: (message, ...args) => log.debug && log.debug(message, ...args),
success: (message, ...args) => log.info(message, ...args) // Map success to info
};
// Pass this wrapper as mcpLog to ensure consistent method availability
// This also ensures output format is set to 'json' in many core functions
const options = { mcpLog: logWrapper, session };
```
- ✅ DO: Implement this pattern in any direct function that calls core functions expecting `mcpLog`
- ✅ DO: Use this solution in conjunction with silent mode for complete output control
- ❌ DON'T: Pass the FastMCP `log` object directly as `mcpLog` to core functions
- **Important**: This pattern has successfully fixed multiple issues in MCP tools (e.g., `update-task`, `update-subtask`) where using or omitting `mcpLog` incorrectly led to runtime errors or JSON parsing failures.
- For complete implementation details, see the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc).
```javascript
// ✅ DO: Implement a proper logging utility
@@ -129,18 +158,124 @@ alwaysApply: false
}
```
## File Operations
## Silent Mode Utilities (in `scripts/modules/utils.js`)
- **Silent Mode Control**:
- ✅ DO: Use the exported silent mode functions rather than accessing global variables
- ✅ DO: Always use `isSilentMode()` to check the current silent mode state
- ✅ DO: Ensure silent mode is disabled in a `finally` block to prevent it from staying enabled
- ❌ DON'T: Access the global `silentMode` variable directly
- ❌ DON'T: Forget to disable silent mode after enabling it
```javascript
// ✅ DO: Use the silent mode control functions properly
// Example of proper implementation in utils.js:
// Global silent mode flag (private to the module)
let silentMode = false;
// Enable silent mode
function enableSilentMode() {
silentMode = true;
}
// Disable silent mode
function disableSilentMode() {
silentMode = false;
}
// Check if silent mode is enabled
function isSilentMode() {
return silentMode;
}
// Example of proper usage in another module:
import { enableSilentMode, disableSilentMode, isSilentMode } from './utils.js';
// Check current status
if (!isSilentMode()) {
console.log('Silent mode is not enabled');
}
// Use try/finally pattern to ensure silent mode is disabled
try {
enableSilentMode();
// Do something that should suppress console output
performOperation();
} finally {
disableSilentMode();
}
```
- **Integration with Logging**:
- ✅ DO: Make the `log` function respect silent mode
```javascript
function log(level, ...args) {
// Skip logging if silent mode is enabled
if (isSilentMode()) {
return;
}
// Rest of logging logic...
}
```
- **Common Patterns for Silent Mode**:
- ✅ DO: In **direct functions** (`mcp-server/src/core/direct-functions/*`) that call **core functions** (`scripts/modules/*`), ensure console output from the core function is suppressed to avoid breaking MCP JSON responses.
- **Preferred Method**: Update the core function to accept an `outputFormat` parameter (e.g., `outputFormat = 'text'`) and make it check `outputFormat === 'text'` before displaying any UI elements (banners, spinners, boxes, direct `console.log`s). Pass `'json'` from the direct function.
- **Necessary Fallback/Guarantee**: If the core function *cannot* be modified or its output suppression via `outputFormat` is unreliable, **wrap the core function call within the direct function** using `enableSilentMode()` and `disableSilentMode()` in a `try/finally` block. This acts as a safety net.
```javascript
// Example in a direct function
export async function someOperationDirect(args, log) {
let result;
const tasksPath = findTasksJsonPath(args, log); // Get path first
// Option 1: Core function handles 'json' format (Preferred)
try {
result = await coreFunction(tasksPath, ...otherArgs, 'json'); // Pass 'json'
return { success: true, data: result, fromCache: false };
} catch (error) {
// Handle error...
}
// Option 2: Core function output unreliable (Fallback/Guarantee)
try {
enableSilentMode(); // Enable before call
result = await coreFunction(tasksPath, ...otherArgs); // Call without format param
} catch (error) {
// Handle error...
log.error(`Failed: ${error.message}`);
return { success: false, error: { /* ... */ } };
} finally {
disableSilentMode(); // ALWAYS disable in finally
}
return { success: true, data: result, fromCache: false }; // Assuming success if no error caught
}
```
- ✅ DO: For functions that accept a silent mode parameter but also need to check global state (less common):
```javascript
// Check both the passed parameter and global silent mode
const isSilent = options.silentMode || (typeof options.silentMode === 'undefined' && isSilentMode());
```
## File Operations (in `scripts/modules/utils.js`)
- **Error Handling**:
- ✅ DO: Use try/catch blocks for all file operations
- ✅ DO: Return null or a default value on failure
- ✅ DO: Log detailed error information
- ❌ DON'T: Allow exceptions to propagate unhandled
- ✅ DO: Log detailed error information using the `log` utility
- ❌ DON'T: Allow exceptions to propagate unhandled from simple file reads/writes
```javascript
// ✅ DO: Handle file operation errors properly
// ✅ DO: Handle file operation errors properly in core utils
function writeJSON(filepath, data) {
try {
// Ensure directory exists (example)
const dir = path.dirname(filepath);
if (!fs.existsSync(dir)) {
fs.mkdirSync(dir, { recursive: true });
}
fs.writeFileSync(filepath, JSON.stringify(data, null, 2));
} catch (error) {
log('error', `Error writing JSON file ${filepath}:`, error.message);
@@ -151,7 +286,7 @@ alwaysApply: false
}
```
## Task-Specific Utilities
## Task-Specific Utilities (in `scripts/modules/utils.js`)
- **Task ID Formatting**:
- ✅ DO: Create utilities for consistent ID handling
@@ -224,7 +359,7 @@ alwaysApply: false
}
```
## Cycle Detection
## Cycle Detection (in `scripts/modules/utils.js`)
- **Graph Algorithms**:
- ✅ DO: Implement cycle detection using graph traversal
@@ -273,84 +408,68 @@ alwaysApply: false
}
```
## MCP Server Utilities (`mcp-server/src/tools/utils.js`)
## MCP Server Core Utilities (`mcp-server/src/core/utils/`)
- **Purpose**: These utilities specifically support the MCP server tools, handling communication patterns and data formatting for MCP clients. Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for usage patterns.
### Project Root and Task File Path Detection (`path-utils.js`)
-(See also: [`tests.mdc`](mdc:.cursor/rules/tests.mdc) for testing these utilities)
- **Purpose**: This module ([`mcp-server/src/core/utils/path-utils.js`](mdc:mcp-server/src/core/utils/path-utils.js)) provides the mechanism for locating the user's `tasks.json` file, used by direct functions.
- **`findTasksJsonPath(args, log)`**:
- ✅ **DO**: Call this function from within **direct function wrappers** (e.g., `listTasksDirect` in `mcp-server/src/core/direct-functions/`) to get the absolute path to the relevant `tasks.json`.
- Pass the *entire `args` object* received by the MCP tool (which should include `projectRoot` derived from the session) and the `log` object.
- Implements a **simplified precedence system** for finding the `tasks.json` path:
1. Explicit `projectRoot` passed in `args` (Expected from MCP tools).
2. Cached `lastFoundProjectRoot` (CLI fallback).
3. Search upwards from `process.cwd()` (CLI fallback).
- Throws a specific error if the `tasks.json` file cannot be located.
- Updates the `lastFoundProjectRoot` cache on success.
- **`PROJECT_MARKERS`**: An exported array of common file/directory names used to identify a likely project root during the CLI fallback search.
- **`getPackagePath()`**: Utility to find the installation path of the `task-master-ai` package itself (potentially removable).
- **`getProjectRoot(projectRootRaw, log)`**:
- Normalizes a potentially relative project root path into an absolute path.
- Defaults to `process.cwd()` if `projectRootRaw` is not provided.
- Primarily used *internally* by `executeMCPToolAction` and `executeTaskMasterCommand`. Tools usually don't need to call this directly.
## MCP Server Tool Utilities (`mcp-server/src/tools/utils.js`)
- **`executeMCPToolAction({ actionFn, args, log, actionName, processResult })`**:
- ✅ **DO**: Use this as the main wrapper inside an MCP tool's `execute` method when calling a direct function wrapper.
- Handles standard workflow: logs action start, normalizes `projectRoot`, calls the `actionFn` (e.g., `listTasksDirect`), processes the result (using `handleApiResult`), logs success/error, and returns a formatted MCP response (`createContentResponse`/`createErrorResponse`).
- Simplifies tool implementation significantly by handling boilerplate.
- Accepts an optional `processResult` function to customize data filtering/transformation before sending the response (defaults to `processMCPResponseData`).
- **Purpose**: These utilities specifically support the MCP server tools ([`mcp-server/src/tools/*.js`](mdc:mcp-server/src/tools/*.js)), handling MCP communication patterns, response formatting, caching integration, and the CLI fallback mechanism.
- **Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)** for detailed usage patterns within the MCP tool `execute` methods and direct function wrappers.
- **`getProjectRootFromSession(session, log)`**:
- ✅ **DO**: Call this utility **within the MCP tool's `execute` method** to extract the project root path from the `session` object.
- Decodes the `file://` URI and handles potential errors.
- Returns the project path string or `null`.
- The returned path should then be passed in the `args` object when calling the corresponding `*Direct` function (e.g., `yourDirectFunction({ ...args, projectRoot: rootFolder }, log)`).
- **`handleApiResult(result, log, errorPrefix, processFunction)`**:
- Takes the standard `{ success, data/error }` object returned by direct function wrappers (like `listTasksDirect`).
- Checks the `success` flag.
- If successful, processes the `data` using `processFunction` (defaults to `processMCPResponseData`).
- Returns a formatted MCP response object using `createContentResponse` or `createErrorResponse`.
- Typically called *internally* by `executeMCPToolAction`.
- ✅ **DO**: Call this from the MCP tool's `execute` method after receiving the result from the `*Direct` function wrapper.
- Takes the standard `{ success, data/error, fromCache }` object.
- Formats the standard MCP success or error response, including the `fromCache` flag.
- Uses `processMCPResponseData` by default to filter response data.
- **`executeTaskMasterCommand(command, log, args, projectRootRaw)`**:
- Executes a Task Master command using `child_process.spawnSync`.
- Tries the global `task-master` command first, then falls back to `node scripts/dev.js`.
- Handles project root normalization internally.
- Returns `{ success, stdout, stderr }` or `{ success: false, error }`.
- ❌ **DON'T**: Use this as the primary method for MCP tools. Prefer `executeMCPToolAction` with direct function calls. Use only as a fallback for commands not yet refactored or those requiring CLI execution.
- Executes a Task Master CLI command as a child process.
- Handles fallback between global `task-master` and local `node scripts/dev.js`.
- ❌ **DON'T**: Use this as the primary method for MCP tools. Prefer direct function calls via `*Direct` wrappers.
- **`processMCPResponseData(taskOrData, fieldsToRemove = ['details', 'testStrategy'])`**:
- Filters task data before sending it to the MCP client.
- By default, removes the `details` and `testStrategy` fields from task objects and their subtasks to reduce payload size.
- Can handle single task objects or data structures containing a `tasks` array (like from `listTasks`).
- This is the default processor used by `executeMCPToolAction`.
- **`processMCPResponseData(taskOrData, fieldsToRemove)`**:
- Filters task data (e.g., removing `details`, `testStrategy`) before sending to the MCP client. Called by `handleApiResult`.
```javascript
// Example usage (typically done inside executeMCPToolAction):
const rawResult = { success: true, data: { tasks: [ { id: 1, title: '...', details: '...', subtasks: [...] } ] } };
const filteredData = processMCPResponseData(rawResult.data);
// filteredData.tasks[0] will NOT have the 'details' field.
```
- **`createContentResponse(content)`**:
- ✅ **DO**: Use this (usually via `handleApiResult` or `executeMCPToolAction`) to format successful MCP responses.
- Wraps the `content` (stringifies objects to JSON) in the standard FastMCP `{ content: [{ type: "text", text: ... }] }` structure.
- **`createErrorResponse(errorMessage)`**:
- ✅ **DO**: Use this (usually via `handleApiResult` or `executeMCPToolAction`) to format error responses for MCP.
- Wraps the `errorMessage` in the standard FastMCP error structure, including `isError: true`.
- **`createContentResponse(content)` / `createErrorResponse(errorMessage)`**:
- Formatters for standard MCP success/error responses.
- **`getCachedOrExecute({ cacheKey, actionFn, log })`**:
- ✅ **DO**: Use this utility *inside direct function wrappers* (like `listTasksDirect` in `task-master-core.js`) to implement caching for MCP operations.
- Checks the `ContextManager` cache using `cacheKey`.
- If a hit occurs, returns the cached result directly.
- If a miss occurs, it executes the provided `actionFn` (which should be an async function returning `{ success, data/error }`).
- If `actionFn` succeeds, its result is stored in the cache under `cacheKey`.
- Returns the result (either cached or fresh) wrapped in the standard structure `{ success, data/error, fromCache: boolean }`.
- **`executeMCPToolAction({ actionFn, args, log, actionName, processResult })`**:
- Update: While this function *can* technically coordinate caching if provided a `cacheKeyGenerator`, the current preferred pattern involves implementing caching *within* the `actionFn` (the direct wrapper) using `getCachedOrExecute`. `executeMCPToolAction` primarily orchestrates the call to `actionFn` and handles processing its result (including the `fromCache` flag) via `handleApiResult`.
- **`handleApiResult(result, log, errorPrefix, processFunction)`**:
- Update: Now expects the `result` object to potentially contain a `fromCache` boolean flag. If present, this flag is included in the final response payload generated by `createContentResponse` (e.g., `{ fromCache: true, data: ... }`).
- ✅ **DO**: Use this utility *inside direct function wrappers* to implement caching.
- Checks cache, executes `actionFn` on miss, stores result.
- Returns standard `{ success, data/error, fromCache: boolean }`.
## Export Organization
- **Grouping Related Functions**:
- ✅ DO: Keep utilities relevant to their location (e.g., core utils in `scripts/modules/utils.js`, MCP utils in `mcp-server/src/tools/utils.js`).
- ✅ DO: Keep utilities relevant to their location (e.g., core CLI utils in `scripts/modules/utils.js`, MCP path utils in `mcp-server/src/core/utils/path-utils.js`, MCP tool utils in `mcp-server/src/tools/utils.js`).
- ✅ DO: Export all utility functions in a single statement per file.
- ✅ DO: Group related exports together.
- ✅ DO: Export configuration constants.
- ✅ DO: Export configuration constants (from `scripts/modules/utils.js`).
- ❌ DON'T: Use default exports.
- ❌ DON'T: Create circular dependencies between utility files or between utilities and the modules that use them (See [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)).
- ❌ DON'T: Create circular dependencies (See [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)).
```javascript
// ✅ DO: Organize exports logically
// Example export from scripts/modules/utils.js
export {
// Configuration
CONFIG,
@@ -368,15 +487,31 @@ alwaysApply: false
truncate,
// Task utilities
readComplexityReport,
findTaskInComplexityReport,
taskExists,
formatTaskId,
findTaskById,
// ... (taskExists, formatTaskId, findTaskById, etc.)
// Graph algorithms
findCycles,
};
// Example export from mcp-server/src/core/utils/path-utils.js
export {
findTasksJsonPath,
getPackagePath,
PROJECT_MARKERS,
lastFoundProjectRoot // Exporting for potential direct use/reset if needed
};
// Example export from mcp-server/src/tools/utils.js
export {
getProjectRoot,
getProjectRootFromSession,
handleApiResult,
executeTaskMasterCommand,
processMCPResponseData,
createContentResponse,
createErrorResponse,
getCachedOrExecute
};
```
Refer to [`utils.js`](mdc:scripts/modules/utils.js) for implementation examples and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines. Use [`commands.mdc`](mdc:.cursor/rules/commands.mdc) for CLI integration details.
Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.

View File

@@ -6,14 +6,14 @@ PERPLEXITY_API_KEY=your_perplexity_api_key_here # Format: pplx-...
MODEL=claude-3-7-sonnet-20250219 # Recommended models: claude-3-7-sonnet-20250219, claude-3-opus-20240229
PERPLEXITY_MODEL=sonar-pro # Perplexity model for research-backed subtasks
MAX_TOKENS=64000 # Maximum tokens for model responses
TEMPERATURE=0.4 # Temperature for model responses (0.0-1.0)
TEMPERATURE=0.2 # Temperature for model responses (0.0-1.0)
# Logging Configuration
DEBUG=false # Enable debug logging (true/false)
LOG_LEVEL=info # Log level (debug, info, warn, error)
# Task Generation Settings
DEFAULT_SUBTASKS=4 # Default number of subtasks when expanding
DEFAULT_SUBTASKS=5 # Default number of subtasks when expanding
DEFAULT_PRIORITY=medium # Default priority for generated tasks (high, medium, low)
# Project Metadata (Optional)

39
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

@@ -0,0 +1,39 @@
---
name: Bug report
about: Create a report to help us improve
title: 'bug: '
labels: bug
assignees: ''
---
### Description
Detailed description of the problem, including steps to reproduce the issue.
### Steps to Reproduce
1. Step-by-step instructions to reproduce the issue
2. Include command examples or UI interactions
### Expected Behavior
Describe clearly what the expected outcome or behavior should be.
### Actual Behavior
Describe clearly what the actual outcome or behavior is.
### Screenshots or Logs
Provide screenshots, logs, or error messages if applicable.
### Environment
- Task Master version:
- Node.js version:
- Operating system:
- IDE (if applicable):
### Additional Context
Any additional information or context that might help diagnose the issue.

View File

@@ -0,0 +1,51 @@
---
name: Enhancements & feature requests
about: Suggest an idea for this project
title: 'feat: '
labels: enhancement
assignees: ''
---
> "Direct quote or clear summary of user request or need or user story."
### Motivation
Detailed explanation of why this feature is important. Describe the problem it solves or the benefit it provides.
### Proposed Solution
Clearly describe the proposed feature, including:
- High-level overview of the feature
- Relevant technologies or integrations
- How it fits into the existing workflow or architecture
### High-Level Workflow
1. Step-by-step description of how the feature will be implemented
2. Include necessary intermediate milestones
### Key Elements
- Bullet-point list of technical or UX/UI enhancements
- Mention specific integrations or APIs
- Highlight changes needed in existing data models or commands
### Example Workflow
Provide a clear, concrete example demonstrating the feature:
```shell
$ task-master [action]
→ Expected response/output
```
### Implementation Considerations
- Dependencies on external components or APIs
- Backward compatibility requirements
- Potential performance impacts or resource usage
### Out of Scope (Future Considerations)
Clearly list any features or improvements not included but relevant for future iterations.

31
.github/ISSUE_TEMPLATE/feedback.md vendored Normal file
View File

@@ -0,0 +1,31 @@
---
name: Feedback
about: Give us specific feedback on the product/approach/tech
title: 'feedback: '
labels: feedback
assignees: ''
---
### Feedback Summary
Provide a clear summary or direct quote from user feedback.
### User Context
Explain the user's context or scenario in which this feedback was provided.
### User Impact
Describe how this feedback affects the user experience or workflow.
### Suggestions
Provide any initial thoughts, potential solutions, or improvements based on the feedback.
### Relevant Screenshots or Examples
Attach screenshots, logs, or examples that illustrate the feedback.
### Additional Notes
Any additional context or related information.

95
.github/workflows/ci.yml vendored Normal file
View File

@@ -0,0 +1,95 @@
name: CI
on:
push:
branches:
- main
- next
pull_request:
branches:
- main
- next
permissions:
contents: read
jobs:
setup:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- name: Install Dependencies
id: install
run: npm ci
timeout-minutes: 2
- name: Cache node_modules
uses: actions/cache@v4
with:
path: node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json') }}
format-check:
needs: setup
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- name: Restore node_modules
uses: actions/cache@v4
with:
path: node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json') }}
- name: Format Check
run: npm run format-check
env:
FORCE_COLOR: 1
test:
needs: setup
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- name: Restore node_modules
uses: actions/cache@v4
with:
path: node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json') }}
- name: Run Tests
run: |
npm run test:coverage -- --coverageThreshold '{"global":{"branches":0,"functions":0,"lines":0,"statements":0}}' --detectOpenHandles --forceExit
env:
NODE_ENV: test
CI: true
FORCE_COLOR: 1
timeout-minutes: 10
- name: Upload Test Results
if: always()
uses: actions/upload-artifact@v4
with:
name: test-results
path: |
test-results
coverage
junit.xml
retention-days: 30

View File

@@ -14,9 +14,21 @@ jobs:
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- name: Cache node_modules
uses: actions/cache@v4
with:
path: |
node_modules
*/*/node_modules
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- name: Install Dependencies
run: npm install
run: npm ci
timeout-minutes: 2
- name: Create Release Pull Request or Publish to npm
uses: changesets/action@v1

3
.gitignore vendored
View File

@@ -9,6 +9,9 @@ jspm_packages/
.env.test.local
.env.production.local
# Cursor configuration -- might have ENV variables. Included by default
# .cursor/mcp.json
# Logs
logs
*.log

7
.prettierignore Normal file
View File

@@ -0,0 +1,7 @@
# Ignore artifacts:
build
coverage
.changeset
tasks
package-lock.json
tests/fixture/*.json

11
.prettierrc Normal file
View File

@@ -0,0 +1,11 @@
{
"printWidth": 80,
"tabWidth": 2,
"useTabs": true,
"semi": true,
"singleQuote": true,
"trailingComma": "none",
"bracketSpacing": true,
"arrowParens": "always",
"endOfLine": "lf"
}

3
.vscode/extensions.json vendored Normal file
View File

@@ -0,0 +1,3 @@
{
"recommendations": ["esbenp.prettier-vscode"]
}

View File

@@ -1,5 +1,68 @@
# task-master-ai
## 0.11.0
### Minor Changes
- [#71](https://github.com/eyaltoledano/claude-task-master/pull/71) [`7141062`](https://github.com/eyaltoledano/claude-task-master/commit/71410629ba187776d92a31ea0729b2ff341b5e38) Thanks [@eyaltoledano](https://github.com/eyaltoledano)! - - **Easier Ways to Use Taskmaster (CLI & MCP):**
- You can now use Taskmaster either by installing it as a standard command-line tool (`task-master`) or as an MCP server directly within integrated development tools like Cursor (using its built-in features). **This makes Taskmaster accessible regardless of your preferred workflow.**
- Setting up a new project is simpler in integrated tools, thanks to the new `initialize_project` capability.
- **Complete MCP Implementation:**
- NOTE: Many MCP clients charge on a per tool basis. In that regard, the most cost-efficient way to use Taskmaster is through the CLI directly. Otherwise, the MCP offers the smoothest and most recommended user experience.
- All MCP tools now follow a standardized output format that mimicks RESTful API responses. They are lean JSON responses that are context-efficient. This is a net improvement over the last version which sent the whole CLI output directly, which needlessly wasted tokens.
- Added a `remove-task` command to permanently delete tasks you no longer need.
- Many new MCP tools are available for managing tasks (updating details, adding/removing subtasks, generating task files, setting status, finding the next task, breaking down complex tasks, handling dependencies, analyzing complexity, etc.), usable both from the command line and integrated tools. **(See the `taskmaster.mdc` reference guide and improved readme for a full list).**
- **Better Task Tracking:**
- Added a "cancelled" status option for tasks, providing more ways to categorize work.
- **Smoother Experience in Integrated Tools:**
- Long-running operations (like breaking down tasks or analysis) now run in the background **via an Async Operation Manager** with progress updates, so you know what's happening without waiting and can check status later.
- **Improved Documentation:**
- Added a comprehensive reference guide (`taskmaster.mdc`) detailing all commands and tools with examples, usage tips, and troubleshooting info. This is mostly for use by the AI but can be useful for human users as well.
- Updated the main README with clearer instructions and added a new tutorial/examples guide.
- Added documentation listing supported integrated tools (like Cursor).
- **Increased Stability & Reliability:**
- Using Taskmaster within integrated tools (like Cursor) is now **more stable and the recommended approach.**
- Added automated testing (CI) to catch issues earlier, leading to a more reliable tool.
- Fixed release process issues to ensure users get the correct package versions when installing or updating via npm.
- **Better Command-Line Experience:**
- Fixed bugs in the `expand-all` command that could cause **NaN errors or JSON formatting issues (especially when using `--research`).**
- Fixed issues with parameter validation in the `analyze-complexity` command (specifically related to the `threshold` parameter).
- Made the `add-task` command more consistent by adding standard flags like `--title`, `--description` for manual task creation so you don't have to use `--prompt` and can quickly drop new ideas and stay in your flow.
- Improved error messages for incorrect commands or flags, making them easier to understand.
- Added confirmation warnings before permanently deleting tasks (`remove-task`) to prevent mistakes. There's a known bug for deleting multiple tasks with comma-separated values. It'll be fixed next release.
- Renamed some background tool names used by integrated tools (e.g., `list-tasks` is now `get_tasks`) to be more intuitive if seen in logs or AI interactions.
- Smoother project start: **Improved the guidance provided to AI assistants immediately after setup** (related to `init` and `parse-prd` steps). This ensures the AI doesn't go on a tangent deciding its own workflow, and follows the exact process outlined in the Taskmaster workflow.
- **Clearer Error Messages:**
- When generating subtasks fails, error messages are now clearer, **including specific task IDs and potential suggestions.**
- AI fallback from Claude to Perplexity now also works the other way around. If Perplexity is down, will switch to Claude.
- **Simplified Setup & Configuration:**
- Made it clearer how to configure API keys depending on whether you're using the command-line tool (`.env` file) or an integrated tool (`.cursor/mcp.json` file).
- Taskmaster is now better at automatically finding your project files, especially in integrated tools, reducing the need for manual path settings.
- Fixed an issue that could prevent Taskmaster from working correctly immediately after initialization in integrated tools (related to how the MCP server was invoked). This should solve the issue most users were experiencing with the last release (0.10.x)
- Updated setup templates with clearer examples for API keys.
- \*\*For advanced users setting up the MCP server manually, the command is now `npx -y task-master-ai task-master-mcp`.
- **Enhanced Performance & AI:**
- Updated underlying AI model settings:
- **Increased Context Window:** Can now handle larger projects/tasks due to an increased Claude context window (64k -> 128k tokens).
- **Reduced AI randomness:** More consistent and predictable AI outputs (temperature 0.4 -> 0.2).
- **Updated default AI models:** Uses newer models like `claude-3-7-sonnet-20250219` and Perplexity `sonar-pro` by default.
- **More granular breakdown:** Increased the default number of subtasks generated by `expand` to 5 (from 4).
- **Consistent defaults:** Set the default priority for new tasks consistently to "medium".
- Improved performance when viewing task details in integrated tools by sending less redundant data.
- **Documentation Clarity:**
- Clarified in documentation that Markdown files (`.md`) can be used for Product Requirements Documents (`parse_prd`).
- Improved the description for the `numTasks` option in `parse_prd` for better guidance.
- **Improved Visuals (CLI):**
- Enhanced the look and feel of progress bars and status updates in the command line.
- Added a helpful color-coded progress bar to the task details view (`show` command) to visualize subtask completion.
- Made progress bars show a breakdown of task statuses (e.g., how many are pending vs. done).
- Made status counts clearer with text labels next to icons.
- Prevented progress bars from messing up the display on smaller terminal windows.
- Adjusted how progress is calculated for 'deferred' and 'cancelled' tasks in the progress bar, while still showing their distinct status visually.
- **Fixes for Integrated Tools:**
- Fixed how progress updates are sent to integrated tools, ensuring they display correctly.
- Fixed internal issues that could cause errors or invalid JSON responses when using Taskmaster with integrated tools.
## 0.10.1
### Patch Changes

View File

@@ -1,90 +0,0 @@
# Dual License
This project is licensed under two separate licenses:
1. [Business Source License 1.1](#business-source-license-11) (BSL 1.1) for commercial use of Task Master itself
2. [Apache License 2.0](#apache-license-20) for all other uses
## Business Source License 1.1
Terms: https://mariadb.com/bsl11/
Licensed Work: Task Master AI
Additional Use Grant: You may use Task Master AI to create and commercialize your own projects and products.
Change Date: 2025-03-30
Change License: None
The Licensed Work is subject to the Business Source License 1.1. If you are interested in using the Licensed Work in a way that competes directly with Task Master, please contact the licensors.
### Licensor
- Eyal Toledano (GitHub: @eyaltoledano)
- Ralph (GitHub: @Crunchyman-ralph)
### Commercial Use Restrictions
This license explicitly restricts certain commercial uses of Task Master AI to the Licensors listed above. Restricted commercial uses include:
1. Creating commercial products or services that directly compete with Task Master AI
2. Selling Task Master AI itself as a service
3. Offering Task Master AI's functionality as a commercial managed service
4. Reselling or redistributing Task Master AI for a fee
### Explicitly Permitted Uses
The following uses are explicitly allowed under this license:
1. Using Task Master AI to create and commercialize your own projects
2. Using Task Master AI in commercial environments for internal development
3. Building and selling products or services that were created using Task Master AI
4. Using Task Master AI for commercial development as long as you're not selling Task Master AI itself
### Additional Terms
1. The right to commercialize Task Master AI itself is exclusively reserved for the Licensors
2. No party may create commercial products that directly compete with Task Master AI without explicit written permission
3. Forks of this repository are subject to the same restrictions regarding direct competition
4. Contributors agree that their contributions will be subject to this same dual licensing structure
## Apache License 2.0
For all uses other than those restricted above. See [APACHE-LICENSE](./APACHE-LICENSE) for the full license text.
### Permitted Use Definition
You may use Task Master AI for any purpose, including commercial purposes, as long as you are not:
1. Creating a direct competitor to Task Master AI
2. Selling Task Master AI itself as a service
3. Redistributing Task Master AI for a fee
### Requirements for Use
1. You must include appropriate copyright notices
2. You must state significant changes made to the software
3. You must preserve all license notices
## Questions and Commercial Licensing
For questions about licensing or to inquire about commercial use that may compete with Task Master, please contact:
- Eyal Toledano (GitHub: @eyaltoledano)
- Ralph (GitHub: @Crunchyman-ralph)
## Examples
### ✅ Allowed Uses
- Using Task Master to create a commercial SaaS product
- Using Task Master in your company for development
- Creating and selling products that were built using Task Master
- Using Task Master to generate code for commercial projects
- Offering consulting services where you use Task Master
### ❌ Restricted Uses
- Creating a competing AI task management tool
- Selling access to Task Master as a service
- Creating a hosted version of Task Master
- Reselling Task Master's functionality

View File

@@ -57,7 +57,17 @@ This will prompt you for project details and set up a new project with the neces
### Important Notes
1. This package uses ES modules. Your package.json should include `"type": "module"`.
1. **ES Modules Configuration:**
- This project uses ES Modules (ESM) instead of CommonJS.
- This is set via `"type": "module"` in your package.json.
- Use `import/export` syntax instead of `require()`.
- Files should use `.js` or `.mjs` extensions.
- To use a CommonJS module, either:
- Rename it with `.cjs` extension
- Use `await import()` for dynamic imports
- If you need CommonJS throughout your project, remove `"type": "module"` from package.json, but Task Master scripts expect ESM.
2. The Anthropic SDK version should be 0.39.0 or higher.
## Quick Start with Global Commands
@@ -136,7 +146,7 @@ To enable enhanced task management capabilities directly within Cursor using the
4. Configure with the following details:
- Name: "Task Master"
- Type: "Command"
- Command: "npx -y --package task-master-ai task-master-mcp"
- Command: "npx -y task-master-mcp"
5. Save the settings
Once configured, you can interact with Task Master's task management commands directly through Cursor's interface, providing a more integrated experience.

684
README.md
View File

@@ -1,58 +1,74 @@
# Task Master
# Task Master [![GitHub stars](https://img.shields.io/github/stars/eyaltoledano/claude-task-master?style=social)](https://github.com/eyaltoledano/claude-task-master/stargazers)
### by [@eyaltoledano](https://x.com/eyaltoledano)
[![CI](https://github.com/eyaltoledano/claude-task-master/actions/workflows/ci.yml/badge.svg)](https://github.com/eyaltoledano/claude-task-master/actions/workflows/ci.yml) [![npm version](https://badge.fury.io/js/task-master-ai.svg)](https://badge.fury.io/js/task-master-ai) ![Discord Follow](https://dcbadge.limes.pink/api/server/https://discord.gg/2ms58QJjqp?style=flat) [![License: MIT with Commons Clause](https://img.shields.io/badge/license-MIT%20with%20Commons%20Clause-blue.svg)](LICENSE)
### By [@eyaltoledano](https://x.com/eyaltoledano) & [@RalphEcom](https://x.com/RalphEcom)
[![Twitter Follow](https://img.shields.io/twitter/follow/eyaltoledano?style=flat)](https://x.com/eyaltoledano)
[![Twitter Follow](https://img.shields.io/twitter/follow/RalphEcom?style=flat)](https://x.com/RalphEcom)
A task management system for AI-driven development with Claude, designed to work seamlessly with Cursor AI.
## Licensing
Task Master is licensed under the MIT License with Commons Clause. This means you can:
**Allowed**:
- Use Task Master for any purpose (personal, commercial, academic)
- Modify the code
- Distribute copies
- Create and sell products built using Task Master
**Not Allowed**:
- Sell Task Master itself
- Offer Task Master as a hosted service
- Create competing products based on Task Master
See the [LICENSE](LICENSE) file for the complete license text.
## Requirements
- Node.js 14.0.0 or higher
- Anthropic API key (Claude API)
- Anthropic SDK version 0.39.0 or higher
- OpenAI SDK (for Perplexity API integration, optional)
## Configuration
## Quick Start
The script can be configured through environment variables in a `.env` file at the root of the project:
### Option 1 | MCP (Recommended):
### Required Configuration
MCP (Model Control Protocol) provides the easiest way to get started with Task Master directly in your editor.
- `ANTHROPIC_API_KEY`: Your Anthropic API key for Claude
1. **Install the package**
### Optional Configuration
```bash
npm i -g task-master-ai
```
- `MODEL`: Specify which Claude model to use (default: "claude-3-7-sonnet-20250219")
- `MAX_TOKENS`: Maximum tokens for model responses (default: 4000)
- `TEMPERATURE`: Temperature for model responses (default: 0.7)
- `PERPLEXITY_API_KEY`: Your Perplexity API key for research-backed subtask generation
- `PERPLEXITY_MODEL`: Specify which Perplexity model to use (default: "sonar-medium-online")
- `DEBUG`: Enable debug logging (default: false)
- `LOG_LEVEL`: Log level - debug, info, warn, error (default: info)
- `DEFAULT_SUBTASKS`: Default number of subtasks when expanding (default: 3)
- `DEFAULT_PRIORITY`: Default priority for generated tasks (default: medium)
- `PROJECT_NAME`: Override default project name in tasks.json
- `PROJECT_VERSION`: Override default version in tasks.json
2. **Add the MCP config to your editor** (Cursor recommended, but it works with other text editors):
## Installation
```json
{
"mcpServers": {
"taskmaster-ai": {
"command": "npx",
"args": ["-y", "task-master-mcp"],
"env": {
"ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
"PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
"MODEL": "claude-3-7-sonnet-20250219",
"PERPLEXITY_MODEL": "sonar-pro",
"MAX_TOKENS": 64000,
"TEMPERATURE": 0.2,
"DEFAULT_SUBTASKS": 5,
"DEFAULT_PRIORITY": "medium"
}
}
}
}
```
2. **Enable the MCP** in your editor
3. **Prompt the AI** to initialize Task Master:
```
Can you please initialize taskmaster-ai into my project?
```
4. **Use common commands** directly through your AI assistant:
```txt
Can you parse my PRD at scripts/prd.txt?
What's the next task I should work on?
Can you help me implement task 3?
Can you help me expand task 4?
```
### Option 2: Using Command Line
#### Installation
```bash
# Install globally
@@ -62,7 +78,7 @@ npm install -g task-master-ai
npm install task-master-ai
```
### Initialize a new project
#### Initialize a new project
```bash
# If installed globally
@@ -74,14 +90,7 @@ npx task-master-init
This will prompt you for project details and set up a new project with the necessary files and structure.
### Important Notes
1. This package uses ES modules. Your package.json should include `"type": "module"`.
2. The Anthropic SDK version should be 0.39.0 or higher.
## Quick Start with Global Commands
After installing the package globally, you can use these CLI commands from any directory:
#### Common Commands
```bash
# Initialize a new project
@@ -100,6 +109,16 @@ task-master next
task-master generate
```
## Documentation
For more detailed information, check out the documentation in the `docs` directory:
- [Configuration Guide](docs/configuration.md) - Set up environment variables and customize Task Master
- [Tutorial](docs/tutorial.md) - Step-by-step guide to getting started with Task Master
- [Command Reference](docs/command-reference.md) - Complete list of all available commands
- [Task Structure](docs/task-structure.md) - Understanding the task format and features
- [Example Interactions](docs/examples.md) - Common Cursor AI interaction examples
## Troubleshooting
### If `task-master init` doesn't respond:
@@ -118,562 +137,31 @@ cd claude-task-master
node scripts/init.js
```
## Task Structure
## Contributors
Tasks in tasks.json have the following structure:
<a href="https://github.com/eyaltoledano/claude-task-master/graphs/contributors">
<img src="https://contrib.rocks/image?repo=eyaltoledano/claude-task-master" alt="Task Master project contributors" />
</a>
- `id`: Unique identifier for the task (Example: `1`)
- `title`: Brief, descriptive title of the task (Example: `"Initialize Repo"`)
- `description`: Concise description of what the task involves (Example: `"Create a new repository, set up initial structure."`)
- `status`: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
- `dependencies`: IDs of tasks that must be completed before this task (Example: `[1, 2]`)
- Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
- This helps quickly identify which prerequisite tasks are blocking work
- `priority`: Importance level of the task (Example: `"high"`, `"medium"`, `"low"`)
- `details`: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
- `testStrategy`: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
- `subtasks`: List of smaller, more specific tasks that make up the main task (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
## Star History
## Integrating with Cursor AI
[![Star History Chart](https://api.star-history.com/svg?repos=eyaltoledano/claude-task-master&type=Timeline)](https://www.star-history.com/#eyaltoledano/claude-task-master&Timeline)
Claude Task Master is designed to work seamlessly with [Cursor AI](https://www.cursor.so/), providing a structured workflow for AI-driven development.
## Licensing
### Setup with Cursor
Task Master is licensed under the MIT License with Commons Clause. This means you can:
1. After initializing your project, open it in Cursor
2. The `.cursor/rules/dev_workflow.mdc` file is automatically loaded by Cursor, providing the AI with knowledge about the task management system
3. Place your PRD document in the `scripts/` directory (e.g., `scripts/prd.txt`)
4. Open Cursor's AI chat and switch to Agent mode
**Allowed**:
### Setting up MCP in Cursor
- Use Task Master for any purpose (personal, commercial, academic)
- Modify the code
- Distribute copies
- Create and sell products built using Task Master
To enable enhanced task management capabilities directly within Cursor using the Model Control Protocol (MCP):
**Not Allowed**:
1. Go to Cursor settings
2. Navigate to the MCP section
3. Click on "Add New MCP Server"
4. Configure with the following details:
- Name: "Task Master"
- Type: "Command"
- Command: "npx -y --package task-master-ai task-master-mcp"
5. Save the settings
- Sell Task Master itself
- Offer Task Master as a hosted service
- Create competing products based on Task Master
Once configured, you can interact with Task Master's task management commands directly through Cursor's interface, providing a more integrated experience.
### Initial Task Generation
In Cursor's AI chat, instruct the agent to generate tasks from your PRD:
```
Please use the task-master parse-prd command to generate tasks from my PRD. The PRD is located at scripts/prd.txt.
```
The agent will execute:
```bash
task-master parse-prd scripts/prd.txt
```
This will:
- Parse your PRD document
- Generate a structured `tasks.json` file with tasks, dependencies, priorities, and test strategies
- The agent will understand this process due to the Cursor rules
### Generate Individual Task Files
Next, ask the agent to generate individual task files:
```
Please generate individual task files from tasks.json
```
The agent will execute:
```bash
task-master generate
```
This creates individual task files in the `tasks/` directory (e.g., `task_001.txt`, `task_002.txt`), making it easier to reference specific tasks.
## AI-Driven Development Workflow
The Cursor agent is pre-configured (via the rules file) to follow this workflow:
### 1. Task Discovery and Selection
Ask the agent to list available tasks:
```
What tasks are available to work on next?
```
The agent will:
- Run `task-master list` to see all tasks
- Run `task-master next` to determine the next task to work on
- Analyze dependencies to determine which tasks are ready to be worked on
- Prioritize tasks based on priority level and ID order
- Suggest the next task(s) to implement
### 2. Task Implementation
When implementing a task, the agent will:
- Reference the task's details section for implementation specifics
- Consider dependencies on previous tasks
- Follow the project's coding standards
- Create appropriate tests based on the task's testStrategy
You can ask:
```
Let's implement task 3. What does it involve?
```
### 3. Task Verification
Before marking a task as complete, verify it according to:
- The task's specified testStrategy
- Any automated tests in the codebase
- Manual verification if required
### 4. Task Completion
When a task is completed, tell the agent:
```
Task 3 is now complete. Please update its status.
```
The agent will execute:
```bash
task-master set-status --id=3 --status=done
```
### 5. Handling Implementation Drift
If during implementation, you discover that:
- The current approach differs significantly from what was planned
- Future tasks need to be modified due to current implementation choices
- New dependencies or requirements have emerged
Tell the agent:
```
We've changed our approach. We're now using Express instead of Fastify. Please update all future tasks to reflect this change.
```
The agent will execute:
```bash
task-master update --from=4 --prompt="Now we are using Express instead of Fastify."
```
This will rewrite or re-scope subsequent tasks in tasks.json while preserving completed work.
### 6. Breaking Down Complex Tasks
For complex tasks that need more granularity:
```
Task 5 seems complex. Can you break it down into subtasks?
```
The agent will execute:
```bash
task-master expand --id=5 --num=3
```
You can provide additional context:
```
Please break down task 5 with a focus on security considerations.
```
The agent will execute:
```bash
task-master expand --id=5 --prompt="Focus on security aspects"
```
You can also expand all pending tasks:
```
Please break down all pending tasks into subtasks.
```
The agent will execute:
```bash
task-master expand --all
```
For research-backed subtask generation using Perplexity AI:
```
Please break down task 5 using research-backed generation.
```
The agent will execute:
```bash
task-master expand --id=5 --research
```
## Command Reference
Here's a comprehensive reference of all available commands:
### Parse PRD
```bash
# Parse a PRD file and generate tasks
task-master parse-prd <prd-file.txt>
# Limit the number of tasks generated
task-master parse-prd <prd-file.txt> --num-tasks=10
```
### List Tasks
```bash
# List all tasks
task-master list
# List tasks with a specific status
task-master list --status=<status>
# List tasks with subtasks
task-master list --with-subtasks
# List tasks with a specific status and include subtasks
task-master list --status=<status> --with-subtasks
```
### Show Next Task
```bash
# Show the next task to work on based on dependencies and status
task-master next
```
### Show Specific Task
```bash
# Show details of a specific task
task-master show <id>
# or
task-master show --id=<id>
# View a specific subtask (e.g., subtask 2 of task 1)
task-master show 1.2
```
### Update Tasks
```bash
# Update tasks from a specific ID and provide context
task-master update --from=<id> --prompt="<prompt>"
```
### Update a Specific Task
```bash
# Update a single task by ID with new information
task-master update-task --id=<id> --prompt="<prompt>"
# Use research-backed updates with Perplexity AI
task-master update-task --id=<id> --prompt="<prompt>" --research
```
### Update a Subtask
```bash
# Append additional information to a specific subtask
task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>"
# Example: Add details about API rate limiting to subtask 2 of task 5
task-master update-subtask --id=5.2 --prompt="Add rate limiting of 100 requests per minute"
# Use research-backed updates with Perplexity AI
task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>" --research
```
Unlike the `update-task` command which replaces task information, the `update-subtask` command _appends_ new information to the existing subtask details, marking it with a timestamp. This is useful for iteratively enhancing subtasks while preserving the original content.
### Generate Task Files
```bash
# Generate individual task files from tasks.json
task-master generate
```
### Set Task Status
```bash
# Set status of a single task
task-master set-status --id=<id> --status=<status>
# Set status for multiple tasks
task-master set-status --id=1,2,3 --status=<status>
# Set status for subtasks
task-master set-status --id=1.1,1.2 --status=<status>
```
When marking a task as "done", all of its subtasks will automatically be marked as "done" as well.
### Expand Tasks
```bash
# Expand a specific task with subtasks
task-master expand --id=<id> --num=<number>
# Expand with additional context
task-master expand --id=<id> --prompt="<context>"
# Expand all pending tasks
task-master expand --all
# Force regeneration of subtasks for tasks that already have them
task-master expand --all --force
# Research-backed subtask generation for a specific task
task-master expand --id=<id> --research
# Research-backed generation for all tasks
task-master expand --all --research
```
### Clear Subtasks
```bash
# Clear subtasks from a specific task
task-master clear-subtasks --id=<id>
# Clear subtasks from multiple tasks
task-master clear-subtasks --id=1,2,3
# Clear subtasks from all tasks
task-master clear-subtasks --all
```
### Analyze Task Complexity
```bash
# Analyze complexity of all tasks
task-master analyze-complexity
# Save report to a custom location
task-master analyze-complexity --output=my-report.json
# Use a specific LLM model
task-master analyze-complexity --model=claude-3-opus-20240229
# Set a custom complexity threshold (1-10)
task-master analyze-complexity --threshold=6
# Use an alternative tasks file
task-master analyze-complexity --file=custom-tasks.json
# Use Perplexity AI for research-backed complexity analysis
task-master analyze-complexity --research
```
### View Complexity Report
```bash
# Display the task complexity analysis report
task-master complexity-report
# View a report at a custom location
task-master complexity-report --file=my-report.json
```
### Managing Task Dependencies
```bash
# Add a dependency to a task
task-master add-dependency --id=<id> --depends-on=<id>
# Remove a dependency from a task
task-master remove-dependency --id=<id> --depends-on=<id>
# Validate dependencies without fixing them
task-master validate-dependencies
# Find and fix invalid dependencies automatically
task-master fix-dependencies
```
### Add a New Task
```bash
# Add a new task using AI
task-master add-task --prompt="Description of the new task"
# Add a task with dependencies
task-master add-task --prompt="Description" --dependencies=1,2,3
# Add a task with priority
task-master add-task --prompt="Description" --priority=high
```
## Feature Details
### Analyzing Task Complexity
The `analyze-complexity` command:
- Analyzes each task using AI to assess its complexity on a scale of 1-10
- Recommends optimal number of subtasks based on configured DEFAULT_SUBTASKS
- Generates tailored prompts for expanding each task
- Creates a comprehensive JSON report with ready-to-use commands
- Saves the report to scripts/task-complexity-report.json by default
The generated report contains:
- Complexity analysis for each task (scored 1-10)
- Recommended number of subtasks based on complexity
- AI-generated expansion prompts customized for each task
- Ready-to-run expansion commands directly within each task analysis
### Viewing Complexity Report
The `complexity-report` command:
- Displays a formatted, easy-to-read version of the complexity analysis report
- Shows tasks organized by complexity score (highest to lowest)
- Provides complexity distribution statistics (low, medium, high)
- Highlights tasks recommended for expansion based on threshold score
- Includes ready-to-use expansion commands for each complex task
- If no report exists, offers to generate one on the spot
### Smart Task Expansion
The `expand` command automatically checks for and uses the complexity report:
When a complexity report exists:
- Tasks are automatically expanded using the recommended subtask count and prompts
- When expanding all tasks, they're processed in order of complexity (highest first)
- Research-backed generation is preserved from the complexity analysis
- You can still override recommendations with explicit command-line options
Example workflow:
```bash
# Generate the complexity analysis report with research capabilities
task-master analyze-complexity --research
# Review the report in a readable format
task-master complexity-report
# Expand tasks using the optimized recommendations
task-master expand --id=8
# or expand all tasks
task-master expand --all
```
### Finding the Next Task
The `next` command:
- Identifies tasks that are pending/in-progress and have all dependencies satisfied
- Prioritizes tasks by priority level, dependency count, and task ID
- Displays comprehensive information about the selected task:
- Basic task details (ID, title, priority, dependencies)
- Implementation details
- Subtasks (if they exist)
- Provides contextual suggested actions:
- Command to mark the task as in-progress
- Command to mark the task as done
- Commands for working with subtasks
### Viewing Specific Task Details
The `show` command:
- Displays comprehensive details about a specific task or subtask
- Shows task status, priority, dependencies, and detailed implementation notes
- For parent tasks, displays all subtasks and their status
- For subtasks, shows parent task relationship
- Provides contextual action suggestions based on the task's state
- Works with both regular tasks and subtasks (using the format taskId.subtaskId)
## Best Practices for AI-Driven Development
1. **Start with a detailed PRD**: The more detailed your PRD, the better the generated tasks will be.
2. **Review generated tasks**: After parsing the PRD, review the tasks to ensure they make sense and have appropriate dependencies.
3. **Analyze task complexity**: Use the complexity analysis feature to identify which tasks should be broken down further.
4. **Follow the dependency chain**: Always respect task dependencies - the Cursor agent will help with this.
5. **Update as you go**: If your implementation diverges from the plan, use the update command to keep future tasks aligned with your current approach.
6. **Break down complex tasks**: Use the expand command to break down complex tasks into manageable subtasks.
7. **Regenerate task files**: After any updates to tasks.json, regenerate the task files to keep them in sync.
8. **Communicate context to the agent**: When asking the Cursor agent to help with a task, provide context about what you're trying to achieve.
9. **Validate dependencies**: Periodically run the validate-dependencies command to check for invalid or circular dependencies.
## Example Cursor AI Interactions
### Starting a new project
```
I've just initialized a new project with Claude Task Master. I have a PRD at scripts/prd.txt.
Can you help me parse it and set up the initial tasks?
```
### Working on tasks
```
What's the next task I should work on? Please consider dependencies and priorities.
```
### Implementing a specific task
```
I'd like to implement task 4. Can you help me understand what needs to be done and how to approach it?
```
### Managing subtasks
```
I need to regenerate the subtasks for task 3 with a different approach. Can you help me clear and regenerate them?
```
### Handling changes
```
We've decided to use MongoDB instead of PostgreSQL. Can you update all future tasks to reflect this change?
```
### Completing work
```
I've finished implementing the authentication system described in task 2. All tests are passing.
Please mark it as complete and tell me what I should work on next.
```
### Analyzing complexity
```
Can you analyze the complexity of our tasks to help me understand which ones need to be broken down further?
```
### Viewing complexity report
```
Can you show me the complexity report in a more readable format?
```
See the [LICENSE](LICENSE) file for the complete license text and [licensing details](docs/licensing.md) for more information.

View File

@@ -1,14 +1,14 @@
# Required
ANTHROPIC_API_KEY=your-api-key-here # Format: sk-ant-api03-...
PERPLEXITY_API_KEY=pplx-abcde # For research (recommended but optional)
ANTHROPIC_API_KEY=your-api-key-here # For most AI ops -- Format: sk-ant-api03-... (Required)
PERPLEXITY_API_KEY=pplx-abcde # For research -- Format: pplx-abcde (Optional, Highly Recommended)
# Optional - defaults shown
MODEL=claude-3-7-sonnet-20250219 # Recommended models: claude-3-7-sonnet-20250219, claude-3-opus-20240229
PERPLEXITY_MODEL=sonar-pro # Make sure you have access to sonar-pro otherwise you can use sonar regular.
MAX_TOKENS=4000 # Maximum tokens for model responses
TEMPERATURE=0.7 # Temperature for model responses (0.0-1.0)
MODEL=claude-3-7-sonnet-20250219 # Recommended models: claude-3-7-sonnet-20250219, claude-3-opus-20240229 (Required)
PERPLEXITY_MODEL=sonar-pro # Make sure you have access to sonar-pro otherwise you can use sonar regular (Optional)
MAX_TOKENS=64000 # Maximum tokens for model responses (Required)
TEMPERATURE=0.2 # Temperature for model responses (0.0-1.0) - lower = less creativity and follow your prompt closely (Required)
DEBUG=false # Enable debug logging (true/false)
LOG_LEVEL=info # Log level (debug, info, warn, error)
DEFAULT_SUBTASKS=3 # Default number of subtasks when expanding
DEFAULT_SUBTASKS=5 # Default number of subtasks when expanding
DEFAULT_PRIORITY=medium # Default priority for generated tasks (high, medium, low)
PROJECT_NAME={{projectName}} # Project name for tasks.json metadata

View File

@@ -21,9 +21,11 @@ In an AI-driven development process—particularly with tools like [Cursor](http
The script can be configured through environment variables in a `.env` file at the root of the project:
### Required Configuration
- `ANTHROPIC_API_KEY`: Your Anthropic API key for Claude
### Optional Configuration
- `MODEL`: Specify which Claude model to use (default: "claude-3-7-sonnet-20250219")
- `MAX_TOKENS`: Maximum tokens for model responses (default: 4000)
- `TEMPERATURE`: Temperature for model responses (default: 0.7)
@@ -39,6 +41,7 @@ The script can be configured through environment variables in a `.env` file at t
## How It Works
1. **`tasks.json`**:
- A JSON file at the project root containing an array of tasks (each with `id`, `title`, `description`, `status`, etc.).
- The `meta` field can store additional info like the project's name, version, or reference to the PRD.
- Tasks can have `subtasks` for more detailed implementation steps.
@@ -111,6 +114,7 @@ task-master update --file=custom-tasks.json --from=5 --prompt="Change database f
```
Notes:
- The `--prompt` parameter is required and should explain the changes or new context
- Only tasks that aren't marked as 'done' will be updated
- Tasks with ID >= the specified --from value will be updated
@@ -134,6 +138,7 @@ task-master set-status --id=1,2,3 --status=done
```
Notes:
- When marking a parent task as "done", all of its subtasks will automatically be marked as "done" as well
- Common status values are 'done', 'pending', and 'deferred', but any string is accepted
- You can specify multiple task IDs by separating them with commas
@@ -183,6 +188,7 @@ task-master clear-subtasks --all
```
Notes:
- After clearing subtasks, task files are automatically regenerated
- This is useful when you want to regenerate subtasks with a different approach
- Can be combined with the `expand` command to immediately generate new subtasks
@@ -198,6 +204,7 @@ The script integrates with two AI services:
The Perplexity integration uses the OpenAI client to connect to Perplexity's API, which provides enhanced research capabilities for generating more informed subtasks. If the Perplexity API is unavailable or encounters an error, the script will automatically fall back to using Anthropic's Claude.
To use the Perplexity integration:
1. Obtain a Perplexity API key
2. Add `PERPLEXITY_API_KEY` to your `.env` file
3. Optionally specify `PERPLEXITY_MODEL` in your `.env` file (default: "sonar-medium-online")
@@ -206,6 +213,7 @@ To use the Perplexity integration:
## Logging
The script supports different logging levels controlled by the `LOG_LEVEL` environment variable:
- `debug`: Detailed information, typically useful for troubleshooting
- `info`: Confirmation that things are working as expected (default)
- `warn`: Warning messages that don't prevent execution
@@ -228,17 +236,20 @@ task-master remove-dependency --id=<id> --depends-on=<id>
These commands:
1. **Allow precise dependency management**:
- Add dependencies between tasks with automatic validation
- Remove dependencies when they're no longer needed
- Update task files automatically after changes
2. **Include validation checks**:
- Prevent circular dependencies (a task depending on itself)
- Prevent duplicate dependencies
- Verify that both tasks exist before adding/removing dependencies
- Check if dependencies exist before attempting to remove them
3. **Provide clear feedback**:
- Success messages confirm when dependencies are added/removed
- Error messages explain why operations failed (if applicable)
@@ -263,6 +274,7 @@ task-master validate-dependencies --file=custom-tasks.json
```
This command:
- Scans all tasks and subtasks for non-existent dependencies
- Identifies potential self-dependencies (tasks referencing themselves)
- Reports all found issues without modifying files
@@ -284,6 +296,7 @@ task-master fix-dependencies --file=custom-tasks.json
```
This command:
1. **Validates all dependencies** across tasks and subtasks
2. **Automatically removes**:
- References to non-existent tasks and subtasks
@@ -321,6 +334,7 @@ task-master analyze-complexity --research
```
Notes:
- The command uses Claude to analyze each task's complexity (or Perplexity with --research flag)
- Tasks are scored on a scale of 1-10
- Each task receives a recommended number of subtasks based on DEFAULT_SUBTASKS configuration
@@ -345,12 +359,14 @@ task-master expand --id=8 --num=5 --prompt="Custom prompt"
```
When a complexity report exists:
- The `expand` command will use the recommended subtask count from the report (unless overridden)
- It will use the tailored expansion prompt from the report (unless a custom prompt is provided)
- When using `--all`, tasks are sorted by complexity score (highest first)
- The `--research` flag is preserved from the complexity analysis to expansion
The output report structure is:
```json
{
"meta": {
@@ -369,7 +385,7 @@ The output report structure is:
"expansionPrompt": "Create subtasks that handle detecting...",
"reasoning": "This task requires sophisticated logic...",
"expansionCommand": "task-master expand --id=8 --num=6 --prompt=\"Create subtasks...\" --research"
},
}
// More tasks sorted by complexity score (highest first)
]
}

View File

@@ -1,30 +0,0 @@
#!/usr/bin/env node
/**
* Claude Task Master Init
* Direct executable for the init command
*/
import { spawn } from 'child_process';
import { fileURLToPath } from 'url';
import { dirname, resolve } from 'path';
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
// Get the path to the init script
const initScriptPath = resolve(__dirname, '../scripts/init.js');
// Pass through all arguments
const args = process.argv.slice(2);
// Spawn the init script with all arguments
const child = spawn('node', [initScriptPath, ...args], {
stdio: 'inherit',
cwd: process.cwd()
});
// Handle exit
child.on('close', (code) => {
process.exit(code);
});

View File

@@ -49,7 +49,13 @@ function runDevScript(args) {
console.error('\nDEBUG - CLI Wrapper Analysis:');
console.error('- Original command: ' + process.argv.join(' '));
console.error('- Transformed args: ' + args.join(' '));
console.error('- dev.js will receive: node ' + devScriptPath + ' ' + args.join(' ') + '\n');
console.error(
'- dev.js will receive: node ' +
devScriptPath +
' ' +
args.join(' ') +
'\n'
);
}
// For testing: If TEST_MODE is set, just print args and exit
@@ -86,11 +92,13 @@ function createDevScriptAction(commandName) {
// If camelCase flags were found, show error and exit
if (camelCaseFlags.length > 0) {
console.error('\nError: Please use kebab-case for CLI flags:');
camelCaseFlags.forEach(flag => {
camelCaseFlags.forEach((flag) => {
console.error(` Instead of: --${flag.original}`);
console.error(` Use: --${flag.kebabCase}`);
});
console.error('\nExample: task-master parse-prd --num-tasks=5 instead of --numTasks=5\n');
console.error(
'\nExample: task-master parse-prd --num-tasks=5 instead of --numTasks=5\n'
);
process.exit(1);
}
@@ -113,9 +121,11 @@ function createDevScriptAction(commandName) {
// It's a flag - pass through as is
commandArgs.push(arg);
// Skip the next arg if this is a flag with a value (not --flag=value format)
if (!arg.includes('=') &&
if (
!arg.includes('=') &&
i + 1 < process.argv.length &&
!process.argv[i+1].startsWith('--')) {
!process.argv[i + 1].startsWith('--')
) {
commandArgs.push(process.argv[++i]);
}
} else if (!positionals.has(arg)) {
@@ -143,7 +153,9 @@ function createDevScriptAction(commandName) {
userOptions.add(kebabName);
// Add the camelCase version as well
const camelName = kebabName.replace(/-([a-z])/g, (_, letter) => letter.toUpperCase());
const camelName = kebabName.replace(/-([a-z])/g, (_, letter) =>
letter.toUpperCase()
);
userOptions.add(camelName);
}
}
@@ -167,7 +179,10 @@ function createDevScriptAction(commandName) {
}
// Skip built-in Commander properties and options the user provided
if (['parent', 'commands', 'options', 'rawArgs'].includes(key) || userOptions.has(key)) {
if (
['parent', 'commands', 'options', 'rawArgs'].includes(key) ||
userOptions.has(key)
) {
return;
}
@@ -210,39 +225,47 @@ function createDevScriptAction(commandName) {
};
}
// Special case for the 'init' command which uses a different script
function registerInitCommand(program) {
program
.command('init')
.description('Initialize a new project')
.option('-y, --yes', 'Skip prompts and use default values')
.option('-n, --name <name>', 'Project name')
.option('-d, --description <description>', 'Project description')
.option('-v, --version <version>', 'Project version')
.option('-a, --author <author>', 'Author name')
.option('--skip-install', 'Skip installing dependencies')
.option('--dry-run', 'Show what would be done without making changes')
.action((options) => {
// Pass through any options to the init script
const args = ['--yes', 'name', 'description', 'version', 'author', 'skip-install', 'dry-run']
.filter(opt => options[opt])
.map(opt => {
if (opt === 'yes' || opt === 'skip-install' || opt === 'dry-run') {
return `--${opt}`;
}
return `--${opt}=${options[opt]}`;
});
// // Special case for the 'init' command which uses a different script
// function registerInitCommand(program) {
// program
// .command('init')
// .description('Initialize a new project')
// .option('-y, --yes', 'Skip prompts and use default values')
// .option('-n, --name <name>', 'Project name')
// .option('-d, --description <description>', 'Project description')
// .option('-v, --version <version>', 'Project version')
// .option('-a, --author <author>', 'Author name')
// .option('--skip-install', 'Skip installing dependencies')
// .option('--dry-run', 'Show what would be done without making changes')
// .action((options) => {
// // Pass through any options to the init script
// const args = [
// '--yes',
// 'name',
// 'description',
// 'version',
// 'author',
// 'skip-install',
// 'dry-run'
// ]
// .filter((opt) => options[opt])
// .map((opt) => {
// if (opt === 'yes' || opt === 'skip-install' || opt === 'dry-run') {
// return `--${opt}`;
// }
// return `--${opt}=${options[opt]}`;
// });
const child = spawn('node', [initScriptPath, ...args], {
stdio: 'inherit',
cwd: process.cwd()
});
// const child = spawn('node', [initScriptPath, ...args], {
// stdio: 'inherit',
// cwd: process.cwd()
// });
child.on('close', (code) => {
process.exit(code);
});
});
}
// child.on('close', (code) => {
// process.exit(code);
// });
// });
// }
// Set up the command-line interface
const program = new Command();
@@ -263,8 +286,8 @@ program.on('--help', () => {
displayHelp();
});
// Add special case commands
registerInitCommand(program);
// // Add special case commands
// registerInitCommand(program);
program
.command('dev')
@@ -279,24 +302,18 @@ const tempProgram = new Command();
registerCommands(tempProgram);
// For each command in the temp instance, add a modified version to our actual program
tempProgram.commands.forEach(cmd => {
if (['init', 'dev'].includes(cmd.name())) {
tempProgram.commands.forEach((cmd) => {
if (['dev'].includes(cmd.name())) {
// Skip commands we've already defined specially
return;
}
// Create a new command with the same name and description
const newCmd = program
.command(cmd.name())
.description(cmd.description());
const newCmd = program.command(cmd.name()).description(cmd.description());
// Copy all options
cmd.options.forEach(opt => {
newCmd.option(
opt.flags,
opt.description,
opt.defaultValue
);
cmd.options.forEach((opt) => {
newCmd.option(opt.flags, opt.description, opt.defaultValue);
});
// Set the action to proxy to dev.js
@@ -311,14 +328,21 @@ process.on('uncaughtException', (err) => {
// Check if this is a commander.js unknown option error
if (err.code === 'commander.unknownOption') {
const option = err.message.match(/'([^']+)'/)?.[1];
const commandArg = process.argv.find(arg => !arg.startsWith('-') &&
const commandArg = process.argv.find(
(arg) =>
!arg.startsWith('-') &&
arg !== 'task-master' &&
!arg.includes('/') &&
arg !== 'node');
arg !== 'node'
);
const command = commandArg || 'unknown';
console.error(chalk.red(`Error: Unknown option '${option}'`));
console.error(chalk.yellow(`Run 'task-master ${command} --help' to see available options for this command`));
console.error(
chalk.yellow(
`Run 'task-master ${command} --help' to see available options for this command`
)
);
process.exit(1);
}
@@ -327,7 +351,9 @@ process.on('uncaughtException', (err) => {
const command = err.message.match(/'([^']+)'/)?.[1];
console.error(chalk.red(`Error: Unknown command '${command}'`));
console.error(chalk.yellow(`Run 'task-master --help' to see available commands`));
console.error(
chalk.yellow(`Run 'task-master --help' to see available commands`)
);
process.exit(1);
}

View File

@@ -186,22 +186,22 @@ const commandMap = {
```javascript
// In mcp-server/src/tools/newFeature.js
import { z } from "zod";
import { z } from 'zod';
import {
executeTaskMasterCommand,
createContentResponse,
createErrorResponse,
} from "./utils.js";
createErrorResponse
} from './utils.js';
export function registerNewFeatureTool(server) {
server.addTool({
name: "newFeature",
description: "Run the new feature",
name: 'newFeature',
description: 'Run the new feature',
parameters: z.object({
param1: z.string().describe("First parameter"),
param2: z.number().optional().describe("Second parameter"),
file: z.string().optional().describe("Path to the tasks file"),
projectRoot: z.string().describe("Root directory of the project")
param1: z.string().describe('First parameter'),
param2: z.number().optional().describe('Second parameter'),
file: z.string().optional().describe('Path to the tasks file'),
projectRoot: z.string().describe('Root directory of the project')
}),
execute: async (args, { log }) => {
try {
@@ -216,7 +216,7 @@ export function registerNewFeatureTool(server) {
// Execute the command
const result = await executeTaskMasterCommand(
"new-feature",
'new-feature',
log,
cmdArgs,
projectRoot
@@ -231,7 +231,7 @@ export function registerNewFeatureTool(server) {
log.error(`Error in new feature: ${error.message}`);
return createErrorResponse(`Error in new feature: ${error.message}`);
}
},
}
});
}
```
@@ -240,7 +240,7 @@ export function registerNewFeatureTool(server) {
```javascript
// In mcp-server/src/tools/index.js
import { registerNewFeatureTool } from "./newFeature.js";
import { registerNewFeatureTool } from './newFeature.js';
export function registerTaskMasterTools(server) {
// ... existing registrations

File diff suppressed because it is too large Load Diff

22
docs/README.md Normal file
View File

@@ -0,0 +1,22 @@
# Task Master Documentation
Welcome to the Task Master documentation. Use the links below to navigate to the information you need:
## Getting Started
- [Configuration Guide](configuration.md) - Set up environment variables and customize Task Master
- [Tutorial](tutorial.md) - Step-by-step guide to getting started with Task Master
## Reference
- [Command Reference](command-reference.md) - Complete list of all available commands
- [Task Structure](task-structure.md) - Understanding the task format and features
## Examples & Licensing
- [Example Interactions](examples.md) - Common Cursor AI interaction examples
- [Licensing Information](licensing.md) - Detailed information about the license
## Need More Help?
If you can't find what you're looking for in these docs, please check the [main README](../README.md) or visit our [GitHub repository](https://github.com/eyaltoledano/claude-task-master).

View File

@@ -0,0 +1,257 @@
# AI Client Utilities for MCP Tools
This document provides examples of how to use the new AI client utilities with AsyncOperationManager in MCP tools.
## Basic Usage with Direct Functions
```javascript
// In your direct function implementation:
import {
getAnthropicClientForMCP,
getModelConfig,
handleClaudeError
} from '../utils/ai-client-utils.js';
export async function someAiOperationDirect(args, log, context) {
try {
// Initialize Anthropic client with session from context
const client = getAnthropicClientForMCP(context.session, log);
// Get model configuration with defaults or session overrides
const modelConfig = getModelConfig(context.session);
// Make API call with proper error handling
try {
const response = await client.messages.create({
model: modelConfig.model,
max_tokens: modelConfig.maxTokens,
temperature: modelConfig.temperature,
messages: [{ role: 'user', content: 'Your prompt here' }]
});
return {
success: true,
data: response
};
} catch (apiError) {
// Use helper to get user-friendly error message
const friendlyMessage = handleClaudeError(apiError);
return {
success: false,
error: {
code: 'AI_API_ERROR',
message: friendlyMessage
}
};
}
} catch (error) {
// Handle client initialization errors
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: error.message
}
};
}
}
```
## Integration with AsyncOperationManager
```javascript
// In your MCP tool implementation:
import {
AsyncOperationManager,
StatusCodes
} from '../../utils/async-operation-manager.js';
import { someAiOperationDirect } from '../../core/direct-functions/some-ai-operation.js';
export async function someAiOperation(args, context) {
const { session, mcpLog } = context;
const log = mcpLog || console;
try {
// Create operation description
const operationDescription = `AI operation: ${args.someParam}`;
// Start async operation
const operation = AsyncOperationManager.createOperation(
operationDescription,
async (reportProgress) => {
try {
// Initial progress report
reportProgress({
progress: 0,
status: 'Starting AI operation...'
});
// Call direct function with session and progress reporting
const result = await someAiOperationDirect(args, log, {
reportProgress,
mcpLog: log,
session
});
// Final progress update
reportProgress({
progress: 100,
status: result.success ? 'Operation completed' : 'Operation failed',
result: result.data,
error: result.error
});
return result;
} catch (error) {
// Handle errors in the operation
reportProgress({
progress: 100,
status: 'Operation failed',
error: {
message: error.message,
code: error.code || 'OPERATION_FAILED'
}
});
throw error;
}
}
);
// Return immediate response with operation ID
return {
status: StatusCodes.ACCEPTED,
body: {
success: true,
message: 'Operation started',
operationId: operation.id
}
};
} catch (error) {
// Handle errors in the MCP tool
log.error(`Error in someAiOperation: ${error.message}`);
return {
status: StatusCodes.INTERNAL_SERVER_ERROR,
body: {
success: false,
error: {
code: 'OPERATION_FAILED',
message: error.message
}
}
};
}
}
```
## Using Research Capabilities with Perplexity
```javascript
// In your direct function:
import {
getPerplexityClientForMCP,
getBestAvailableAIModel
} from '../utils/ai-client-utils.js';
export async function researchOperationDirect(args, log, context) {
try {
// Get the best AI model for this operation based on needs
const { type, client } = await getBestAvailableAIModel(
context.session,
{ requiresResearch: true },
log
);
// Report which model we're using
if (context.reportProgress) {
await context.reportProgress({
progress: 10,
status: `Using ${type} model for research...`
});
}
// Make API call based on the model type
if (type === 'perplexity') {
// Call Perplexity
const response = await client.chat.completions.create({
model: context.session?.env?.PERPLEXITY_MODEL || 'sonar-medium-online',
messages: [{ role: 'user', content: args.researchQuery }],
temperature: 0.1
});
return {
success: true,
data: response.choices[0].message.content
};
} else {
// Call Claude as fallback
// (Implementation depends on specific needs)
// ...
}
} catch (error) {
// Handle errors
return {
success: false,
error: {
code: 'RESEARCH_ERROR',
message: error.message
}
};
}
}
```
## Model Configuration Override Example
```javascript
// In your direct function:
import { getModelConfig } from '../utils/ai-client-utils.js';
// Using custom defaults for a specific operation
const operationDefaults = {
model: 'claude-3-haiku-20240307', // Faster, smaller model
maxTokens: 1000, // Lower token limit
temperature: 0.2 // Lower temperature for more deterministic output
};
// Get model config with operation-specific defaults
const modelConfig = getModelConfig(context.session, operationDefaults);
// Now use modelConfig in your API calls
const response = await client.messages.create({
model: modelConfig.model,
max_tokens: modelConfig.maxTokens,
temperature: modelConfig.temperature
// Other parameters...
});
```
## Best Practices
1. **Error Handling**:
- Always use try/catch blocks around both client initialization and API calls
- Use `handleClaudeError` to provide user-friendly error messages
- Return standardized error objects with code and message
2. **Progress Reporting**:
- Report progress at key points (starting, processing, completing)
- Include meaningful status messages
- Include error details in progress reports when failures occur
3. **Session Handling**:
- Always pass the session from the context to the AI client getters
- Use `getModelConfig` to respect user settings from session
4. **Model Selection**:
- Use `getBestAvailableAIModel` when you need to select between different models
- Set `requiresResearch: true` when you need Perplexity capabilities
5. **AsyncOperationManager Integration**:
- Create descriptive operation names
- Handle all errors within the operation function
- Return standardized results from direct functions
- Return immediate responses with operation IDs

205
docs/command-reference.md Normal file
View File

@@ -0,0 +1,205 @@
# Task Master Command Reference
Here's a comprehensive reference of all available commands:
## Parse PRD
```bash
# Parse a PRD file and generate tasks
task-master parse-prd <prd-file.txt>
# Limit the number of tasks generated
task-master parse-prd <prd-file.txt> --num-tasks=10
```
## List Tasks
```bash
# List all tasks
task-master list
# List tasks with a specific status
task-master list --status=<status>
# List tasks with subtasks
task-master list --with-subtasks
# List tasks with a specific status and include subtasks
task-master list --status=<status> --with-subtasks
```
## Show Next Task
```bash
# Show the next task to work on based on dependencies and status
task-master next
```
## Show Specific Task
```bash
# Show details of a specific task
task-master show <id>
# or
task-master show --id=<id>
# View a specific subtask (e.g., subtask 2 of task 1)
task-master show 1.2
```
## Update Tasks
```bash
# Update tasks from a specific ID and provide context
task-master update --from=<id> --prompt="<prompt>"
```
## Update a Specific Task
```bash
# Update a single task by ID with new information
task-master update-task --id=<id> --prompt="<prompt>"
# Use research-backed updates with Perplexity AI
task-master update-task --id=<id> --prompt="<prompt>" --research
```
## Update a Subtask
```bash
# Append additional information to a specific subtask
task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>"
# Example: Add details about API rate limiting to subtask 2 of task 5
task-master update-subtask --id=5.2 --prompt="Add rate limiting of 100 requests per minute"
# Use research-backed updates with Perplexity AI
task-master update-subtask --id=<parentId.subtaskId> --prompt="<prompt>" --research
```
Unlike the `update-task` command which replaces task information, the `update-subtask` command _appends_ new information to the existing subtask details, marking it with a timestamp. This is useful for iteratively enhancing subtasks while preserving the original content.
## Generate Task Files
```bash
# Generate individual task files from tasks.json
task-master generate
```
## Set Task Status
```bash
# Set status of a single task
task-master set-status --id=<id> --status=<status>
# Set status for multiple tasks
task-master set-status --id=1,2,3 --status=<status>
# Set status for subtasks
task-master set-status --id=1.1,1.2 --status=<status>
```
When marking a task as "done", all of its subtasks will automatically be marked as "done" as well.
## Expand Tasks
```bash
# Expand a specific task with subtasks
task-master expand --id=<id> --num=<number>
# Expand with additional context
task-master expand --id=<id> --prompt="<context>"
# Expand all pending tasks
task-master expand --all
# Force regeneration of subtasks for tasks that already have them
task-master expand --all --force
# Research-backed subtask generation for a specific task
task-master expand --id=<id> --research
# Research-backed generation for all tasks
task-master expand --all --research
```
## Clear Subtasks
```bash
# Clear subtasks from a specific task
task-master clear-subtasks --id=<id>
# Clear subtasks from multiple tasks
task-master clear-subtasks --id=1,2,3
# Clear subtasks from all tasks
task-master clear-subtasks --all
```
## Analyze Task Complexity
```bash
# Analyze complexity of all tasks
task-master analyze-complexity
# Save report to a custom location
task-master analyze-complexity --output=my-report.json
# Use a specific LLM model
task-master analyze-complexity --model=claude-3-opus-20240229
# Set a custom complexity threshold (1-10)
task-master analyze-complexity --threshold=6
# Use an alternative tasks file
task-master analyze-complexity --file=custom-tasks.json
# Use Perplexity AI for research-backed complexity analysis
task-master analyze-complexity --research
```
## View Complexity Report
```bash
# Display the task complexity analysis report
task-master complexity-report
# View a report at a custom location
task-master complexity-report --file=my-report.json
```
## Managing Task Dependencies
```bash
# Add a dependency to a task
task-master add-dependency --id=<id> --depends-on=<id>
# Remove a dependency from a task
task-master remove-dependency --id=<id> --depends-on=<id>
# Validate dependencies without fixing them
task-master validate-dependencies
# Find and fix invalid dependencies automatically
task-master fix-dependencies
```
## Add a New Task
```bash
# Add a new task using AI
task-master add-task --prompt="Description of the new task"
# Add a task with dependencies
task-master add-task --prompt="Description" --dependencies=1,2,3
# Add a task with priority
task-master add-task --prompt="Description" --priority=high
```
## Initialize a Project
```bash
# Initialize a new project with Task Master structure
task-master init
```

65
docs/configuration.md Normal file
View File

@@ -0,0 +1,65 @@
# Configuration
Task Master can be configured through environment variables in a `.env` file at the root of your project.
## Required Configuration
- `ANTHROPIC_API_KEY`: Your Anthropic API key for Claude (Example: `ANTHROPIC_API_KEY=sk-ant-api03-...`)
## Optional Configuration
- `MODEL` (Default: `"claude-3-7-sonnet-20250219"`): Claude model to use (Example: `MODEL=claude-3-opus-20240229`)
- `MAX_TOKENS` (Default: `"4000"`): Maximum tokens for responses (Example: `MAX_TOKENS=8000`)
- `TEMPERATURE` (Default: `"0.7"`): Temperature for model responses (Example: `TEMPERATURE=0.5`)
- `DEBUG` (Default: `"false"`): Enable debug logging (Example: `DEBUG=true`)
- `LOG_LEVEL` (Default: `"info"`): Console output level (Example: `LOG_LEVEL=debug`)
- `DEFAULT_SUBTASKS` (Default: `"3"`): Default subtask count (Example: `DEFAULT_SUBTASKS=5`)
- `DEFAULT_PRIORITY` (Default: `"medium"`): Default priority (Example: `DEFAULT_PRIORITY=high`)
- `PROJECT_NAME` (Default: `"MCP SaaS MVP"`): Project name in metadata (Example: `PROJECT_NAME=My Awesome Project`)
- `PROJECT_VERSION` (Default: `"1.0.0"`): Version in metadata (Example: `PROJECT_VERSION=2.1.0`)
- `PERPLEXITY_API_KEY`: For research-backed features (Example: `PERPLEXITY_API_KEY=pplx-...`)
- `PERPLEXITY_MODEL` (Default: `"sonar-medium-online"`): Perplexity model (Example: `PERPLEXITY_MODEL=sonar-large-online`)
## Example .env File
```
# Required
ANTHROPIC_API_KEY=sk-ant-api03-your-api-key
# Optional - Claude Configuration
MODEL=claude-3-7-sonnet-20250219
MAX_TOKENS=4000
TEMPERATURE=0.7
# Optional - Perplexity API for Research
PERPLEXITY_API_KEY=pplx-your-api-key
PERPLEXITY_MODEL=sonar-medium-online
# Optional - Project Info
PROJECT_NAME=My Project
PROJECT_VERSION=1.0.0
# Optional - Application Configuration
DEFAULT_SUBTASKS=3
DEFAULT_PRIORITY=medium
DEBUG=false
LOG_LEVEL=info
```
## Troubleshooting
### If `task-master init` doesn't respond:
Try running it with Node directly:
```bash
node node_modules/claude-task-master/scripts/init.js
```
Or clone the repository and run:
```bash
git clone https://github.com/eyaltoledano/claude-task-master.git
cd claude-task-master
node scripts/init.js
```

53
docs/examples.md Normal file
View File

@@ -0,0 +1,53 @@
# Example Cursor AI Interactions
Here are some common interactions with Cursor AI when using Task Master:
## Starting a new project
```
I've just initialized a new project with Claude Task Master. I have a PRD at scripts/prd.txt.
Can you help me parse it and set up the initial tasks?
```
## Working on tasks
```
What's the next task I should work on? Please consider dependencies and priorities.
```
## Implementing a specific task
```
I'd like to implement task 4. Can you help me understand what needs to be done and how to approach it?
```
## Managing subtasks
```
I need to regenerate the subtasks for task 3 with a different approach. Can you help me clear and regenerate them?
```
## Handling changes
```
We've decided to use MongoDB instead of PostgreSQL. Can you update all future tasks to reflect this change?
```
## Completing work
```
I've finished implementing the authentication system described in task 2. All tests are passing.
Please mark it as complete and tell me what I should work on next.
```
## Analyzing complexity
```
Can you analyze the complexity of our tasks to help me understand which ones need to be broken down further?
```
## Viewing complexity report
```
Can you show me the complexity report in a more readable format?
```

1179
docs/fastmcp-core.txt Normal file

File diff suppressed because it is too large Load Diff

18
docs/licensing.md Normal file
View File

@@ -0,0 +1,18 @@
# Licensing
Task Master is licensed under the MIT License with Commons Clause. This means you can:
## ✅ Allowed:
- Use Task Master for any purpose (personal, commercial, academic)
- Modify the code
- Distribute copies
- Create and sell products built using Task Master
## ❌ Not Allowed:
- Sell Task Master itself
- Offer Task Master as a hosted service
- Create competing products based on Task Master
See the [LICENSE](../LICENSE) file for the complete license text.

File diff suppressed because it is too large Load Diff

139
docs/task-structure.md Normal file
View File

@@ -0,0 +1,139 @@
# Task Structure
Tasks in Task Master follow a specific format designed to provide comprehensive information for both humans and AI assistants.
## Task Fields in tasks.json
Tasks in tasks.json have the following structure:
- `id`: Unique identifier for the task (Example: `1`)
- `title`: Brief, descriptive title of the task (Example: `"Initialize Repo"`)
- `description`: Concise description of what the task involves (Example: `"Create a new repository, set up initial structure."`)
- `status`: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
- `dependencies`: IDs of tasks that must be completed before this task (Example: `[1, 2]`)
- Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
- This helps quickly identify which prerequisite tasks are blocking work
- `priority`: Importance level of the task (Example: `"high"`, `"medium"`, `"low"`)
- `details`: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
- `testStrategy`: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
- `subtasks`: List of smaller, more specific tasks that make up the main task (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
## Task File Format
Individual task files follow this format:
```
# Task ID: <id>
# Title: <title>
# Status: <status>
# Dependencies: <comma-separated list of dependency IDs>
# Priority: <priority>
# Description: <brief description>
# Details:
<detailed implementation notes>
# Test Strategy:
<verification approach>
```
## Features in Detail
### Analyzing Task Complexity
The `analyze-complexity` command:
- Analyzes each task using AI to assess its complexity on a scale of 1-10
- Recommends optimal number of subtasks based on configured DEFAULT_SUBTASKS
- Generates tailored prompts for expanding each task
- Creates a comprehensive JSON report with ready-to-use commands
- Saves the report to scripts/task-complexity-report.json by default
The generated report contains:
- Complexity analysis for each task (scored 1-10)
- Recommended number of subtasks based on complexity
- AI-generated expansion prompts customized for each task
- Ready-to-run expansion commands directly within each task analysis
### Viewing Complexity Report
The `complexity-report` command:
- Displays a formatted, easy-to-read version of the complexity analysis report
- Shows tasks organized by complexity score (highest to lowest)
- Provides complexity distribution statistics (low, medium, high)
- Highlights tasks recommended for expansion based on threshold score
- Includes ready-to-use expansion commands for each complex task
- If no report exists, offers to generate one on the spot
### Smart Task Expansion
The `expand` command automatically checks for and uses the complexity report:
When a complexity report exists:
- Tasks are automatically expanded using the recommended subtask count and prompts
- When expanding all tasks, they're processed in order of complexity (highest first)
- Research-backed generation is preserved from the complexity analysis
- You can still override recommendations with explicit command-line options
Example workflow:
```bash
# Generate the complexity analysis report with research capabilities
task-master analyze-complexity --research
# Review the report in a readable format
task-master complexity-report
# Expand tasks using the optimized recommendations
task-master expand --id=8
# or expand all tasks
task-master expand --all
```
### Finding the Next Task
The `next` command:
- Identifies tasks that are pending/in-progress and have all dependencies satisfied
- Prioritizes tasks by priority level, dependency count, and task ID
- Displays comprehensive information about the selected task:
- Basic task details (ID, title, priority, dependencies)
- Implementation details
- Subtasks (if they exist)
- Provides contextual suggested actions:
- Command to mark the task as in-progress
- Command to mark the task as done
- Commands for working with subtasks
### Viewing Specific Task Details
The `show` command:
- Displays comprehensive details about a specific task or subtask
- Shows task status, priority, dependencies, and detailed implementation notes
- For parent tasks, displays all subtasks and their status
- For subtasks, shows parent task relationship
- Provides contextual action suggestions based on the task's state
- Works with both regular tasks and subtasks (using the format taskId.subtaskId)
## Best Practices for AI-Driven Development
1. **Start with a detailed PRD**: The more detailed your PRD, the better the generated tasks will be.
2. **Review generated tasks**: After parsing the PRD, review the tasks to ensure they make sense and have appropriate dependencies.
3. **Analyze task complexity**: Use the complexity analysis feature to identify which tasks should be broken down further.
4. **Follow the dependency chain**: Always respect task dependencies - the Cursor agent will help with this.
5. **Update as you go**: If your implementation diverges from the plan, use the update command to keep future tasks aligned with your current approach.
6. **Break down complex tasks**: Use the expand command to break down complex tasks into manageable subtasks.
7. **Regenerate task files**: After any updates to tasks.json, regenerate the task files to keep them in sync.
8. **Communicate context to the agent**: When asking the Cursor agent to help with a task, provide context about what you're trying to achieve.
9. **Validate dependencies**: Periodically run the validate-dependencies command to check for invalid or circular dependencies.

361
docs/tutorial.md Normal file
View File

@@ -0,0 +1,361 @@
# Task Master Tutorial
This tutorial will guide you through setting up and using Task Master for AI-driven development.
## Initial Setup
There are two ways to set up Task Master: using MCP (recommended) or via npm installation.
### Option 1: Using MCP (Recommended)
MCP (Model Control Protocol) provides the easiest way to get started with Task Master directly in your editor.
1. **Install the package**
```bash
npm i -g task-master-ai
```
2. **Add the MCP config to your editor** (Cursor recommended, but it works with other text editors):
```json
{
"mcpServers": {
"taskmaster-ai": {
"command": "npx",
"args": ["-y", "task-master-mcp"],
"env": {
"ANTHROPIC_API_KEY": "YOUR_ANTHROPIC_API_KEY_HERE",
"PERPLEXITY_API_KEY": "YOUR_PERPLEXITY_API_KEY_HERE",
"MODEL": "claude-3-7-sonnet-20250219",
"PERPLEXITY_MODEL": "sonar-pro",
"MAX_TOKENS": 64000,
"TEMPERATURE": 0.2,
"DEFAULT_SUBTASKS": 5,
"DEFAULT_PRIORITY": "medium"
}
}
}
}
```
2. **Enable the MCP** in your editor settings
3. **Prompt the AI** to initialize Task Master:
```
Can you please initialize taskmaster-ai into my project?
```
The AI will:
- Create necessary project structure
- Set up initial configuration files
- Guide you through the rest of the process
4. Place your PRD document in the `scripts/` directory (e.g., `scripts/prd.txt`)
5. **Use natural language commands** to interact with Task Master:
```
Can you parse my PRD at scripts/prd.txt?
What's the next task I should work on?
Can you help me implement task 3?
```
### Option 2: Manual Installation
If you prefer to use the command line interface directly:
```bash
# Install globally
npm install -g task-master-ai
# OR install locally within your project
npm install task-master-ai
```
Initialize a new project:
```bash
# If installed globally
task-master init
# If installed locally
npx task-master-init
```
This will prompt you for project details and set up a new project with the necessary files and structure.
## Common Commands
After setting up Task Master, you can use these commands (either via AI prompts or CLI):
```bash
# Parse a PRD and generate tasks
task-master parse-prd your-prd.txt
# List all tasks
task-master list
# Show the next task to work on
task-master next
# Generate task files
task-master generate
```
## Setting up Cursor AI Integration
Task Master is designed to work seamlessly with [Cursor AI](https://www.cursor.so/), providing a structured workflow for AI-driven development.
### Using Cursor with MCP (Recommended)
If you've already set up Task Master with MCP in Cursor, the integration is automatic. You can simply use natural language to interact with Task Master:
```
What tasks are available to work on next?
Can you analyze the complexity of our tasks?
I'd like to implement task 4. What does it involve?
```
### Manual Cursor Setup
If you're not using MCP, you can still set up Cursor integration:
1. After initializing your project, open it in Cursor
2. The `.cursor/rules/dev_workflow.mdc` file is automatically loaded by Cursor, providing the AI with knowledge about the task management system
3. Place your PRD document in the `scripts/` directory (e.g., `scripts/prd.txt`)
4. Open Cursor's AI chat and switch to Agent mode
### Alternative MCP Setup in Cursor
You can also set up the MCP server in Cursor settings:
1. Go to Cursor settings
2. Navigate to the MCP section
3. Click on "Add New MCP Server"
4. Configure with the following details:
- Name: "Task Master"
- Type: "Command"
- Command: "npx -y task-master-mcp"
5. Save the settings
Once configured, you can interact with Task Master's task management commands directly through Cursor's interface, providing a more integrated experience.
## Initial Task Generation
In Cursor's AI chat, instruct the agent to generate tasks from your PRD:
```
Please use the task-master parse-prd command to generate tasks from my PRD. The PRD is located at scripts/prd.txt.
```
The agent will execute:
```bash
task-master parse-prd scripts/prd.txt
```
This will:
- Parse your PRD document
- Generate a structured `tasks.json` file with tasks, dependencies, priorities, and test strategies
- The agent will understand this process due to the Cursor rules
### Generate Individual Task Files
Next, ask the agent to generate individual task files:
```
Please generate individual task files from tasks.json
```
The agent will execute:
```bash
task-master generate
```
This creates individual task files in the `tasks/` directory (e.g., `task_001.txt`, `task_002.txt`), making it easier to reference specific tasks.
## AI-Driven Development Workflow
The Cursor agent is pre-configured (via the rules file) to follow this workflow:
### 1. Task Discovery and Selection
Ask the agent to list available tasks:
```
What tasks are available to work on next?
```
The agent will:
- Run `task-master list` to see all tasks
- Run `task-master next` to determine the next task to work on
- Analyze dependencies to determine which tasks are ready to be worked on
- Prioritize tasks based on priority level and ID order
- Suggest the next task(s) to implement
### 2. Task Implementation
When implementing a task, the agent will:
- Reference the task's details section for implementation specifics
- Consider dependencies on previous tasks
- Follow the project's coding standards
- Create appropriate tests based on the task's testStrategy
You can ask:
```
Let's implement task 3. What does it involve?
```
### 3. Task Verification
Before marking a task as complete, verify it according to:
- The task's specified testStrategy
- Any automated tests in the codebase
- Manual verification if required
### 4. Task Completion
When a task is completed, tell the agent:
```
Task 3 is now complete. Please update its status.
```
The agent will execute:
```bash
task-master set-status --id=3 --status=done
```
### 5. Handling Implementation Drift
If during implementation, you discover that:
- The current approach differs significantly from what was planned
- Future tasks need to be modified due to current implementation choices
- New dependencies or requirements have emerged
Tell the agent:
```
We've changed our approach. We're now using Express instead of Fastify. Please update all future tasks to reflect this change.
```
The agent will execute:
```bash
task-master update --from=4 --prompt="Now we are using Express instead of Fastify."
```
This will rewrite or re-scope subsequent tasks in tasks.json while preserving completed work.
### 6. Breaking Down Complex Tasks
For complex tasks that need more granularity:
```
Task 5 seems complex. Can you break it down into subtasks?
```
The agent will execute:
```bash
task-master expand --id=5 --num=3
```
You can provide additional context:
```
Please break down task 5 with a focus on security considerations.
```
The agent will execute:
```bash
task-master expand --id=5 --prompt="Focus on security aspects"
```
You can also expand all pending tasks:
```
Please break down all pending tasks into subtasks.
```
The agent will execute:
```bash
task-master expand --all
```
For research-backed subtask generation using Perplexity AI:
```
Please break down task 5 using research-backed generation.
```
The agent will execute:
```bash
task-master expand --id=5 --research
```
## Example Cursor AI Interactions
### Starting a new project
```
I've just initialized a new project with Claude Task Master. I have a PRD at scripts/prd.txt.
Can you help me parse it and set up the initial tasks?
```
### Working on tasks
```
What's the next task I should work on? Please consider dependencies and priorities.
```
### Implementing a specific task
```
I'd like to implement task 4. Can you help me understand what needs to be done and how to approach it?
```
### Managing subtasks
```
I need to regenerate the subtasks for task 3 with a different approach. Can you help me clear and regenerate them?
```
### Handling changes
```
We've decided to use MongoDB instead of PostgreSQL. Can you update all future tasks to reflect this change?
```
### Completing work
```
I've finished implementing the authentication system described in task 2. All tests are passing.
Please mark it as complete and tell me what I should work on next.
```
### Analyzing complexity
```
Can you analyze the complexity of our tasks to help me understand which ones need to be broken down further?
```
### Viewing complexity report
```
Can you show me the complexity report in a more readable format?
```

View File

@@ -80,7 +80,7 @@ if (import.meta.url === `file://${process.argv[1]}`) {
.command('init')
.description('Initialize a new project')
.action(() => {
runInitCLI().catch(err => {
runInitCLI().catch((err) => {
console.error('Init failed:', err.message);
process.exit(1);
});

View File

@@ -1,8 +1,8 @@
#!/usr/bin/env node
import TaskMasterMCPServer from "./src/index.js";
import dotenv from "dotenv";
import logger from "./src/logger.js";
import TaskMasterMCPServer from './src/index.js';
import dotenv from 'dotenv';
import logger from './src/logger.js';
// Load environment variables
dotenv.config();
@@ -14,12 +14,12 @@ async function startServer() {
const server = new TaskMasterMCPServer();
// Handle graceful shutdown
process.on("SIGINT", async () => {
process.on('SIGINT', async () => {
await server.stop();
process.exit(0);
});
process.on("SIGTERM", async () => {
process.on('SIGTERM', async () => {
await server.stop();
process.exit(0);
});

View File

@@ -14,7 +14,9 @@ describe('ContextManager', () => {
describe('getContext', () => {
it('should create a new context when not in cache', async () => {
const context = await contextManager.getContext('test-id', { test: true });
const context = await contextManager.getContext('test-id', {
test: true
});
expect(context.id).toBe('test-id');
expect(context.metadata.test).toBe(true);
expect(contextManager.stats.misses).toBe(1);
@@ -26,7 +28,9 @@ describe('ContextManager', () => {
await contextManager.getContext('test-id', { test: true });
// Second call should hit cache
const context = await contextManager.getContext('test-id', { test: true });
const context = await contextManager.getContext('test-id', {
test: true
});
expect(context.id).toBe('test-id');
expect(context.metadata.test).toBe(true);
expect(contextManager.stats.hits).toBe(1);
@@ -38,7 +42,7 @@ describe('ContextManager', () => {
await contextManager.getContext('test-id', { test: true });
// Wait for TTL to expire
await new Promise(resolve => setTimeout(resolve, 1100));
await new Promise((resolve) => setTimeout(resolve, 1100));
// Should create new context
await contextManager.getContext('test-id', { test: true });
@@ -50,7 +54,9 @@ describe('ContextManager', () => {
describe('updateContext', () => {
it('should update existing context metadata', async () => {
await contextManager.getContext('test-id', { initial: true });
const updated = await contextManager.updateContext('test-id', { updated: true });
const updated = await contextManager.updateContext('test-id', {
updated: true
});
expect(updated.metadata.initial).toBe(true);
expect(updated.metadata.updated).toBe(true);

View File

@@ -112,7 +112,8 @@ export class ContextManager {
*/
getCachedData(key) {
const cached = this.cache.get(key);
if (cached !== undefined) { // Check for undefined specifically, as null/false might be valid cached values
if (cached !== undefined) {
// Check for undefined specifically, as null/false might be valid cached values
this.stats.hits++;
return cached;
}

View File

@@ -0,0 +1,106 @@
/**
* add-dependency.js
* Direct function implementation for adding a dependency to a task
*/
import { addDependency } from '../../../../scripts/modules/dependency-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for addDependency with error handling.
*
* @param {Object} args - Command arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string|number} args.id - Task ID to add dependency to
* @param {string|number} args.dependsOn - Task ID that will become a dependency
* @param {Object} log - Logger object
* @returns {Promise<Object>} - Result object with success status and data/error information
*/
export async function addDependencyDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id, dependsOn } = args;
try {
log.info(`Adding dependency with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('addDependencyDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Validate required parameters
if (!id) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Task ID (id) is required'
}
};
}
if (!dependsOn) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Dependency ID (dependsOn) is required'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Format IDs for the core function
const taskId =
id && id.includes && id.includes('.') ? id : parseInt(id, 10);
const dependencyId =
dependsOn && dependsOn.includes && dependsOn.includes('.')
? dependsOn
: parseInt(dependsOn, 10);
log.info(
`Adding dependency: task ${taskId} will depend on ${dependencyId}`
);
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the core function using the provided path
await addDependency(tasksPath, taskId, dependencyId);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: `Successfully added dependency: Task ${taskId} now depends on ${dependencyId}`,
taskId: taskId,
dependencyId: dependencyId
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in addDependencyDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,165 @@
/**
* Direct function wrapper for addSubtask
*/
import { addSubtask } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Add a subtask to an existing task
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.id - Parent task ID
* @param {string} [args.taskId] - Existing task ID to convert to subtask (optional)
* @param {string} [args.title] - Title for new subtask (when creating a new subtask)
* @param {string} [args.description] - Description for new subtask
* @param {string} [args.details] - Implementation details for new subtask
* @param {string} [args.status] - Status for new subtask (default: 'pending')
* @param {string} [args.dependencies] - Comma-separated list of dependency IDs
* @param {boolean} [args.skipGenerate] - Skip regenerating task files
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: string}>}
*/
export async function addSubtaskDirect(args, log) {
// Destructure expected args
const {
tasksJsonPath,
id,
taskId,
title,
description,
details,
status,
dependencies: dependenciesStr,
skipGenerate
} = args;
try {
log.info(`Adding subtask with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('addSubtaskDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
if (!id) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Parent task ID is required'
}
};
}
// Either taskId or title must be provided
if (!taskId && !title) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Either taskId or title must be provided'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Parse dependencies if provided
let dependencies = [];
if (dependenciesStr) {
dependencies = dependenciesStr.split(',').map((depId) => {
// Handle both regular IDs and dot notation
return depId.includes('.') ? depId.trim() : parseInt(depId.trim(), 10);
});
}
// Convert existingTaskId to a number if provided
const existingTaskId = taskId ? parseInt(taskId, 10) : null;
// Convert parent ID to a number
const parentId = parseInt(id, 10);
// Determine if we should generate files
const generateFiles = !skipGenerate;
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Case 1: Convert existing task to subtask
if (existingTaskId) {
log.info(`Converting task ${existingTaskId} to a subtask of ${parentId}`);
const result = await addSubtask(
tasksPath,
parentId,
existingTaskId,
null,
generateFiles
);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: `Task ${existingTaskId} successfully converted to a subtask of task ${parentId}`,
subtask: result
}
};
}
// Case 2: Create new subtask
else {
log.info(`Creating new subtask for parent task ${parentId}`);
const newSubtaskData = {
title: title,
description: description || '',
details: details || '',
status: status || 'pending',
dependencies: dependencies
};
const result = await addSubtask(
tasksPath,
parentId,
null,
newSubtaskData,
generateFiles
);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: `New subtask ${parentId}.${result.id} successfully created`,
subtask: result
}
};
}
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in addSubtaskDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,259 @@
/**
* add-task.js
* Direct function implementation for adding a new task
*/
import { addTask } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getModelConfig
} from '../utils/ai-client-utils.js';
import {
_buildAddTaskPrompt,
parseTaskJsonResponse,
_handleAnthropicStream
} from '../../../../scripts/modules/ai-services.js';
/**
* Direct function wrapper for adding a new task with error handling.
*
* @param {Object} args - Command arguments
* @param {string} [args.prompt] - Description of the task to add (required if not using manual fields)
* @param {string} [args.title] - Task title (for manual task creation)
* @param {string} [args.description] - Task description (for manual task creation)
* @param {string} [args.details] - Implementation details (for manual task creation)
* @param {string} [args.testStrategy] - Test strategy (for manual task creation)
* @param {string} [args.dependencies] - Comma-separated list of task IDs this task depends on
* @param {string} [args.priority='medium'] - Task priority (high, medium, low)
* @param {string} [args.file='tasks/tasks.json'] - Path to the tasks file
* @param {string} [args.projectRoot] - Project root directory
* @param {boolean} [args.research=false] - Whether to use research capabilities for task creation
* @param {Object} log - Logger object
* @param {Object} context - Additional context (reportProgress, session)
* @returns {Promise<Object>} - Result object { success: boolean, data?: any, error?: { code: string, message: string } }
*/
export async function addTaskDirect(args, log, context = {}) {
// Destructure expected args
const { tasksJsonPath, prompt, dependencies, priority, research } = args;
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('addTaskDirect called without tasksJsonPath');
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Check if this is manual task creation or AI-driven task creation
const isManualCreation = args.title && args.description;
// Check required parameters
if (!args.prompt && !isManualCreation) {
log.error(
'Missing required parameters: either prompt or title+description must be provided'
);
disableSilentMode();
return {
success: false,
error: {
code: 'MISSING_PARAMETER',
message:
'Either the prompt parameter or both title and description parameters are required for adding a task'
}
};
}
// Extract and prepare parameters
const taskPrompt = prompt;
const taskDependencies = Array.isArray(dependencies)
? dependencies
: dependencies
? String(dependencies)
.split(',')
.map((id) => parseInt(id.trim(), 10))
: [];
const taskPriority = priority || 'medium';
// Extract context parameters for advanced functionality
const { session } = context;
let manualTaskData = null;
if (isManualCreation) {
// Create manual task data object
manualTaskData = {
title: args.title,
description: args.description,
details: args.details || '',
testStrategy: args.testStrategy || ''
};
log.info(
`Adding new task manually with title: "${args.title}", dependencies: [${taskDependencies.join(', ')}], priority: ${priority}`
);
// Call the addTask function with manual task data
const newTaskId = await addTask(
tasksPath,
null, // No prompt needed for manual creation
taskDependencies,
priority,
{
mcpLog: log,
session
},
'json', // Use JSON output format to prevent console output
null, // No custom environment
manualTaskData // Pass the manual task data
);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
taskId: newTaskId,
message: `Successfully added new task #${newTaskId}`
}
};
} else {
// AI-driven task creation
log.info(
`Adding new task with prompt: "${prompt}", dependencies: [${taskDependencies.join(', ')}], priority: ${priority}`
);
// Initialize AI client with session environment
let localAnthropic;
try {
localAnthropic = getAnthropicClientForMCP(session, log);
} catch (error) {
log.error(`Failed to initialize Anthropic client: ${error.message}`);
disableSilentMode();
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
}
};
}
// Get model configuration from session
const modelConfig = getModelConfig(session);
// Read existing tasks to provide context
let tasksData;
try {
const fs = await import('fs');
tasksData = JSON.parse(fs.readFileSync(tasksPath, 'utf8'));
} catch (error) {
log.warn(`Could not read existing tasks for context: ${error.message}`);
tasksData = { tasks: [] };
}
// Build prompts for AI
const { systemPrompt, userPrompt } = _buildAddTaskPrompt(
prompt,
tasksData.tasks
);
// Make the AI call using the streaming helper
let responseText;
try {
responseText = await _handleAnthropicStream(
localAnthropic,
{
model: modelConfig.model,
max_tokens: modelConfig.maxTokens,
temperature: modelConfig.temperature,
messages: [{ role: 'user', content: userPrompt }],
system: systemPrompt
},
{
mcpLog: log
}
);
} catch (error) {
log.error(`AI processing failed: ${error.message}`);
disableSilentMode();
return {
success: false,
error: {
code: 'AI_PROCESSING_ERROR',
message: `Failed to generate task with AI: ${error.message}`
}
};
}
// Parse the AI response
let taskDataFromAI;
try {
taskDataFromAI = parseTaskJsonResponse(responseText);
} catch (error) {
log.error(`Failed to parse AI response: ${error.message}`);
disableSilentMode();
return {
success: false,
error: {
code: 'RESPONSE_PARSING_ERROR',
message: `Failed to parse AI response: ${error.message}`
}
};
}
// Call the addTask function with 'json' outputFormat to prevent console output when called via MCP
const newTaskId = await addTask(
tasksPath,
prompt,
taskDependencies,
priority,
{
mcpLog: log,
session
},
'json',
null,
taskDataFromAI // Pass the parsed AI result as the manual task data
);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
taskId: newTaskId,
message: `Successfully added new task #${newTaskId}`
}
};
}
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in addTaskDirect: ${error.message}`);
return {
success: false,
error: {
code: 'ADD_TASK_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,182 @@
/**
* Direct function wrapper for analyzeTaskComplexity
*/
import { analyzeTaskComplexity } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode,
isSilentMode,
readJSON
} from '../../../../scripts/modules/utils.js';
import fs from 'fs';
import path from 'path';
/**
* Analyze task complexity and generate recommendations
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.outputPath - Explicit absolute path to save the report.
* @param {string} [args.model] - LLM model to use for analysis
* @param {string|number} [args.threshold] - Minimum complexity score to recommend expansion (1-10)
* @param {boolean} [args.research] - Use Perplexity AI for research-backed complexity analysis
* @param {Object} log - Logger object
* @param {Object} [context={}] - Context object containing session data
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function analyzeTaskComplexityDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
// Destructure expected args
const { tasksJsonPath, outputPath, model, threshold, research } = args;
try {
log.info(`Analyzing task complexity with args: ${JSON.stringify(args)}`);
// Check if required paths were provided
if (!tasksJsonPath) {
log.error('analyzeTaskComplexityDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
if (!outputPath) {
log.error('analyzeTaskComplexityDirect called without outputPath');
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: 'outputPath is required' }
};
}
// Use the provided paths
const tasksPath = tasksJsonPath;
const resolvedOutputPath = outputPath;
log.info(`Analyzing task complexity from: ${tasksPath}`);
log.info(`Output report will be saved to: ${resolvedOutputPath}`);
if (research) {
log.info('Using Perplexity AI for research-backed complexity analysis');
}
// Create options object for analyzeTaskComplexity using provided paths
const options = {
file: tasksPath,
output: resolvedOutputPath,
model: model,
threshold: threshold,
research: research === true
};
// Enable silent mode to prevent console logs from interfering with JSON response
const wasSilent = isSilentMode();
if (!wasSilent) {
enableSilentMode();
}
// Create a logWrapper that matches the expected mcpLog interface as specified in utilities.mdc
const logWrapper = {
info: (message, ...args) => log.info(message, ...args),
warn: (message, ...args) => log.warn(message, ...args),
error: (message, ...args) => log.error(message, ...args),
debug: (message, ...args) => log.debug && log.debug(message, ...args),
success: (message, ...args) => log.info(message, ...args) // Map success to info
};
try {
// Call the core function with session and logWrapper as mcpLog
await analyzeTaskComplexity(options, {
session,
mcpLog: logWrapper // Use the wrapper instead of passing log directly
});
} catch (error) {
log.error(`Error in analyzeTaskComplexity: ${error.message}`);
return {
success: false,
error: {
code: 'ANALYZE_ERROR',
message: `Error running complexity analysis: ${error.message}`
}
};
} finally {
// Always restore normal logging in finally block, but only if we enabled it
if (!wasSilent) {
disableSilentMode();
}
}
// Verify the report file was created
if (!fs.existsSync(resolvedOutputPath)) {
return {
success: false,
error: {
code: 'ANALYZE_ERROR',
message: 'Analysis completed but no report file was created'
}
};
}
// Read the report file
let report;
try {
report = JSON.parse(fs.readFileSync(resolvedOutputPath, 'utf8'));
// Important: Handle different report formats
// The core function might return an array or an object with a complexityAnalysis property
const analysisArray = Array.isArray(report)
? report
: report.complexityAnalysis || [];
// Count tasks by complexity
const highComplexityTasks = analysisArray.filter(
(t) => t.complexityScore >= 8
).length;
const mediumComplexityTasks = analysisArray.filter(
(t) => t.complexityScore >= 5 && t.complexityScore < 8
).length;
const lowComplexityTasks = analysisArray.filter(
(t) => t.complexityScore < 5
).length;
return {
success: true,
data: {
message: `Task complexity analysis complete. Report saved to ${resolvedOutputPath}`,
reportPath: resolvedOutputPath,
reportSummary: {
taskCount: analysisArray.length,
highComplexityTasks,
mediumComplexityTasks,
lowComplexityTasks
}
}
};
} catch (parseError) {
log.error(`Error parsing report file: ${parseError.message}`);
return {
success: false,
error: {
code: 'REPORT_PARSE_ERROR',
message: `Error parsing complexity report: ${parseError.message}`
}
};
}
} catch (error) {
// Make sure to restore normal logging even if there's an error
if (isSilentMode()) {
disableSilentMode();
}
log.error(`Error in analyzeTaskComplexityDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,32 @@
/**
* cache-stats.js
* Direct function implementation for retrieving cache statistics
*/
import { contextManager } from '../context-manager.js';
/**
* Get cache statistics for monitoring
* @param {Object} args - Command arguments
* @param {Object} log - Logger object
* @returns {Object} - Cache statistics
*/
export async function getCacheStatsDirect(args, log) {
try {
log.info('Retrieving cache statistics');
const stats = contextManager.getStats();
return {
success: true,
data: stats
};
} catch (error) {
log.error(`Error getting cache stats: ${error.message}`);
return {
success: false,
error: {
code: 'CACHE_STATS_ERROR',
message: error.message || 'Unknown error occurred'
}
};
}
}

View File

@@ -0,0 +1,128 @@
/**
* Direct function wrapper for clearSubtasks
*/
import { clearSubtasks } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import fs from 'fs';
/**
* Clear subtasks from specified tasks
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} [args.id] - Task IDs (comma-separated) to clear subtasks from
* @param {boolean} [args.all] - Clear subtasks from all tasks
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function clearSubtasksDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id, all } = args;
try {
log.info(`Clearing subtasks with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('clearSubtasksDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Either id or all must be provided
if (!id && !all) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message:
'Either task IDs with id parameter or all parameter must be provided'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Check if tasks.json exists
if (!fs.existsSync(tasksPath)) {
return {
success: false,
error: {
code: 'FILE_NOT_FOUND_ERROR',
message: `Tasks file not found at ${tasksPath}`
}
};
}
let taskIds;
// If all is specified, get all task IDs
if (all) {
log.info('Clearing subtasks from all tasks');
const data = JSON.parse(fs.readFileSync(tasksPath, 'utf8'));
if (!data || !data.tasks || data.tasks.length === 0) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'No valid tasks found in the tasks file'
}
};
}
taskIds = data.tasks.map((t) => t.id).join(',');
} else {
// Use the provided task IDs
taskIds = id;
}
log.info(`Clearing subtasks from tasks: ${taskIds}`);
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the core function
clearSubtasks(tasksPath, taskIds);
// Restore normal logging
disableSilentMode();
// Read the updated data to provide a summary
const updatedData = JSON.parse(fs.readFileSync(tasksPath, 'utf8'));
const taskIdArray = taskIds.split(',').map((id) => parseInt(id.trim(), 10));
// Build a summary of what was done
const clearedTasksCount = taskIdArray.length;
const taskSummary = taskIdArray.map((id) => {
const task = updatedData.tasks.find((t) => t.id === id);
return task ? { id, title: task.title } : { id, title: 'Task not found' };
});
return {
success: true,
data: {
message: `Successfully cleared subtasks from ${clearedTasksCount} task(s)`,
tasksCleared: taskSummary
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in clearSubtasksDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,130 @@
/**
* complexity-report.js
* Direct function implementation for displaying complexity analysis report
*/
import {
readComplexityReport,
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import { getCachedOrExecute } from '../../tools/utils.js';
import path from 'path';
/**
* Direct function wrapper for displaying the complexity report with error handling and caching.
*
* @param {Object} args - Command arguments containing reportPath.
* @param {string} args.reportPath - Explicit path to the complexity report file.
* @param {Object} log - Logger object
* @returns {Promise<Object>} - Result object with success status and data/error information
*/
export async function complexityReportDirect(args, log) {
// Destructure expected args
const { reportPath } = args;
try {
log.info(`Getting complexity report with args: ${JSON.stringify(args)}`);
// Check if reportPath was provided
if (!reportPath) {
log.error('complexityReportDirect called without reportPath');
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: 'reportPath is required' },
fromCache: false
};
}
// Use the provided report path
log.info(`Looking for complexity report at: ${reportPath}`);
// Generate cache key based on report path
const cacheKey = `complexityReport:${reportPath}`;
// Define the core action function to read the report
const coreActionFn = async () => {
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
const report = readComplexityReport(reportPath);
// Restore normal logging
disableSilentMode();
if (!report) {
log.warn(`No complexity report found at ${reportPath}`);
return {
success: false,
error: {
code: 'FILE_NOT_FOUND_ERROR',
message: `No complexity report found at ${reportPath}. Run 'analyze-complexity' first.`
}
};
}
return {
success: true,
data: {
report,
reportPath
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error reading complexity report: ${error.message}`);
return {
success: false,
error: {
code: 'READ_ERROR',
message: error.message
}
};
}
};
// Use the caching utility
try {
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreActionFn,
log
});
log.info(
`complexityReportDirect completed. From cache: ${result.fromCache}`
);
return result; // Returns { success, data/error, fromCache }
} catch (error) {
// Catch unexpected errors from getCachedOrExecute itself
// Ensure silent mode is disabled
disableSilentMode();
log.error(
`Unexpected error during getCachedOrExecute for complexityReport: ${error.message}`
);
return {
success: false,
error: {
code: 'UNEXPECTED_ERROR',
message: error.message
},
fromCache: false
};
}
} catch (error) {
// Ensure silent mode is disabled if an outer error occurs
disableSilentMode();
log.error(`Error in complexityReportDirect: ${error.message}`);
return {
success: false,
error: {
code: 'UNEXPECTED_ERROR',
message: error.message
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,142 @@
/**
* Direct function wrapper for expandAllTasks
*/
import { expandAllTasks } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode,
isSilentMode
} from '../../../../scripts/modules/utils.js';
import { getAnthropicClientForMCP } from '../utils/ai-client-utils.js';
import path from 'path';
import fs from 'fs';
/**
* Expand all pending tasks with subtasks
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {number|string} [args.num] - Number of subtasks to generate
* @param {boolean} [args.research] - Enable Perplexity AI for research-backed subtask generation
* @param {string} [args.prompt] - Additional context to guide subtask generation
* @param {boolean} [args.force] - Force regeneration of subtasks for tasks that already have them
* @param {Object} log - Logger object
* @param {Object} context - Context object containing session
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function expandAllTasksDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
// Destructure expected args
const { tasksJsonPath, num, research, prompt, force } = args;
try {
log.info(`Expanding all tasks with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('expandAllTasksDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Enable silent mode early to prevent any console output
enableSilentMode();
try {
// Remove internal path finding
/*
const tasksPath = findTasksJsonPath(args, log);
*/
// Use provided path
const tasksPath = tasksJsonPath;
// Parse parameters
const numSubtasks = num ? parseInt(num, 10) : undefined;
const useResearch = research === true;
const additionalContext = prompt || '';
const forceFlag = force === true;
log.info(
`Expanding all tasks with ${numSubtasks || 'default'} subtasks each...`
);
if (useResearch) {
log.info('Using Perplexity AI for research-backed subtask generation');
// Initialize AI client for research-backed expansion
try {
await getAnthropicClientForMCP(session, log);
} catch (error) {
// Ensure silent mode is disabled before returning error
disableSilentMode();
log.error(`Failed to initialize AI client: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
}
};
}
}
if (additionalContext) {
log.info(`Additional context: "${additionalContext}"`);
}
if (forceFlag) {
log.info('Force regeneration of subtasks is enabled');
}
// Call the core function with session context for AI operations
// and outputFormat as 'json' to prevent UI elements
const result = await expandAllTasks(
tasksPath,
numSubtasks,
useResearch,
additionalContext,
forceFlag,
{ mcpLog: log, session },
'json' // Use JSON output format to prevent UI elements
);
// The expandAllTasks function now returns a result object
return {
success: true,
data: {
message: 'Successfully expanded all pending tasks with subtasks',
details: {
numSubtasks: numSubtasks,
research: useResearch,
prompt: additionalContext,
force: forceFlag,
tasksExpanded: result.expandedCount,
totalEligibleTasks: result.tasksToExpand
}
}
};
} finally {
// Restore normal logging in finally block to ensure it runs even if there's an error
disableSilentMode();
}
} catch (error) {
// Ensure silent mode is disabled if an error occurs
if (isSilentMode()) {
disableSilentMode();
}
log.error(`Error in expandAllTasksDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,270 @@
/**
* expand-task.js
* Direct function implementation for expanding a task into subtasks
*/
import { expandTask } from '../../../../scripts/modules/task-manager.js';
import {
readJSON,
writeJSON,
enableSilentMode,
disableSilentMode,
isSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getModelConfig
} from '../utils/ai-client-utils.js';
import path from 'path';
import fs from 'fs';
/**
* Direct function wrapper for expanding a task into subtasks with error handling.
*
* @param {Object} args - Command arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.id - The ID of the task to expand.
* @param {number|string} [args.num] - Number of subtasks to generate.
* @param {boolean} [args.research] - Enable Perplexity AI for research-backed subtask generation.
* @param {string} [args.prompt] - Additional context to guide subtask generation.
* @param {boolean} [args.force] - Force expansion even if subtasks exist.
* @param {Object} log - Logger object
* @param {Object} context - Context object containing session and reportProgress
* @returns {Promise<Object>} - Task expansion result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: boolean }
*/
export async function expandTaskDirect(args, log, context = {}) {
const { session } = context;
// Destructure expected args
const { tasksJsonPath, id, num, research, prompt, force } = args;
// Log session root data for debugging
log.info(
`Session data in expandTaskDirect: ${JSON.stringify({
hasSession: !!session,
sessionKeys: session ? Object.keys(session) : [],
roots: session?.roots,
rootsStr: JSON.stringify(session?.roots)
})}`
);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('expandTaskDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
},
fromCache: false
};
}
// Use provided path
const tasksPath = tasksJsonPath;
log.info(`[expandTaskDirect] Using tasksPath: ${tasksPath}`);
// Validate task ID
const taskId = id ? parseInt(id, 10) : null;
if (!taskId) {
log.error('Task ID is required');
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Task ID is required'
},
fromCache: false
};
}
// Process other parameters
const numSubtasks = num ? parseInt(num, 10) : undefined;
const useResearch = research === true;
const additionalContext = prompt || '';
const forceFlag = force === true;
// Initialize AI client if needed (for expandTask function)
try {
// This ensures the AI client is available by checking it
if (useResearch) {
log.info('Verifying AI client for research-backed expansion');
await getAnthropicClientForMCP(session, log);
}
} catch (error) {
log.error(`Failed to initialize AI client: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
},
fromCache: false
};
}
try {
log.info(
`[expandTaskDirect] Expanding task ${taskId} into ${numSubtasks || 'default'} subtasks. Research: ${useResearch}`
);
// Read tasks data
log.info(`[expandTaskDirect] Attempting to read JSON from: ${tasksPath}`);
const data = readJSON(tasksPath);
log.info(
`[expandTaskDirect] Result of readJSON: ${data ? 'Data read successfully' : 'readJSON returned null or undefined'}`
);
if (!data || !data.tasks) {
log.error(
`[expandTaskDirect] readJSON failed or returned invalid data for path: ${tasksPath}`
);
return {
success: false,
error: {
code: 'INVALID_TASKS_FILE',
message: `No valid tasks found in ${tasksPath}. readJSON returned: ${JSON.stringify(data)}`
},
fromCache: false
};
}
// Find the specific task
log.info(`[expandTaskDirect] Searching for task ID ${taskId} in data`);
const task = data.tasks.find((t) => t.id === taskId);
log.info(`[expandTaskDirect] Task found: ${task ? 'Yes' : 'No'}`);
if (!task) {
return {
success: false,
error: {
code: 'TASK_NOT_FOUND',
message: `Task with ID ${taskId} not found`
},
fromCache: false
};
}
// Check if task is completed
if (task.status === 'done' || task.status === 'completed') {
return {
success: false,
error: {
code: 'TASK_COMPLETED',
message: `Task ${taskId} is already marked as ${task.status} and cannot be expanded`
},
fromCache: false
};
}
// Check for existing subtasks and force flag
const hasExistingSubtasks = task.subtasks && task.subtasks.length > 0;
if (hasExistingSubtasks && !forceFlag) {
log.info(
`Task ${taskId} already has ${task.subtasks.length} subtasks. Use --force to overwrite.`
);
return {
success: true,
data: {
message: `Task ${taskId} already has subtasks. Expansion skipped.`,
task,
subtasksAdded: 0,
hasExistingSubtasks
},
fromCache: false
};
}
// If force flag is set, clear existing subtasks
if (hasExistingSubtasks && forceFlag) {
log.info(
`Force flag set. Clearing existing subtasks for task ${taskId}.`
);
task.subtasks = [];
}
// Keep a copy of the task before modification
const originalTask = JSON.parse(JSON.stringify(task));
// Tracking subtasks count before expansion
const subtasksCountBefore = task.subtasks ? task.subtasks.length : 0;
// Create a backup of the tasks.json file
const backupPath = path.join(path.dirname(tasksPath), 'tasks.json.bak');
fs.copyFileSync(tasksPath, backupPath);
// Directly modify the data instead of calling the CLI function
if (!task.subtasks) {
task.subtasks = [];
}
// Save tasks.json with potentially empty subtasks array
writeJSON(tasksPath, data);
// Process the request
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call expandTask with session context to ensure AI client is properly initialized
const result = await expandTask(
tasksPath,
taskId,
numSubtasks,
useResearch,
additionalContext,
{ mcpLog: log, session } // Only pass mcpLog and session, NOT reportProgress
);
// Restore normal logging
disableSilentMode();
// Read the updated data
const updatedData = readJSON(tasksPath);
const updatedTask = updatedData.tasks.find((t) => t.id === taskId);
// Calculate how many subtasks were added
const subtasksAdded = updatedTask.subtasks
? updatedTask.subtasks.length - subtasksCountBefore
: 0;
// Return the result
log.info(
`Successfully expanded task ${taskId} with ${subtasksAdded} new subtasks`
);
return {
success: true,
data: {
task: updatedTask,
subtasksAdded,
hasExistingSubtasks
},
fromCache: false
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error expanding task: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message || 'Failed to expand task'
},
fromCache: false
};
}
} catch (error) {
log.error(`Error expanding task: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message || 'Failed to expand task'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,80 @@
/**
* Direct function wrapper for fixDependenciesCommand
*/
import { fixDependenciesCommand } from '../../../../scripts/modules/dependency-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import fs from 'fs';
/**
* Fix invalid dependencies in tasks.json automatically
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function fixDependenciesDirect(args, log) {
// Destructure expected args
const { tasksJsonPath } = args;
try {
log.info(`Fixing invalid dependencies in tasks: ${tasksJsonPath}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('fixDependenciesDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Verify the file exists
if (!fs.existsSync(tasksPath)) {
return {
success: false,
error: {
code: 'FILE_NOT_FOUND',
message: `Tasks file not found at ${tasksPath}`
}
};
}
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the original command function using the provided path
await fixDependenciesCommand(tasksPath);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: 'Dependencies fixed successfully',
tasksPath
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error fixing dependencies: ${error.message}`);
return {
success: false,
error: {
code: 'FIX_DEPENDENCIES_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,100 @@
/**
* generate-task-files.js
* Direct function implementation for generating task files from tasks.json
*/
import { generateTaskFiles } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import path from 'path';
/**
* Direct function wrapper for generateTaskFiles with error handling.
*
* @param {Object} args - Command arguments containing tasksJsonPath and outputDir.
* @param {Object} log - Logger object.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function generateTaskFilesDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, outputDir } = args;
try {
log.info(`Generating task files with args: ${JSON.stringify(args)}`);
// Check if paths were provided
if (!tasksJsonPath) {
const errorMessage = 'tasksJsonPath is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
if (!outputDir) {
const errorMessage = 'outputDir is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
// Use the provided paths
const tasksPath = tasksJsonPath;
const resolvedOutputDir = outputDir;
log.info(`Generating task files from ${tasksPath} to ${resolvedOutputDir}`);
// Execute core generateTaskFiles function in a separate try/catch
try {
// Enable silent mode to prevent logs from being written to stdout
enableSilentMode();
// The function is synchronous despite being awaited elsewhere
generateTaskFiles(tasksPath, resolvedOutputDir);
// Restore normal logging after task generation
disableSilentMode();
} catch (genError) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in generateTaskFiles: ${genError.message}`);
return {
success: false,
error: { code: 'GENERATE_FILES_ERROR', message: genError.message },
fromCache: false
};
}
// Return success with file paths
return {
success: true,
data: {
message: `Successfully generated task files`,
tasksPath: tasksPath,
outputDir: resolvedOutputDir,
taskFiles:
'Individual task files have been generated in the output directory'
},
fromCache: false // This operation always modifies state and should never be cached
};
} catch (error) {
// Make sure to restore normal logging if an outer error occurs
disableSilentMode();
log.error(`Error generating task files: ${error.message}`);
return {
success: false,
error: {
code: 'GENERATE_TASKS_ERROR',
message: error.message || 'Unknown error generating task files'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,138 @@
import { initializeProject } from '../../../../scripts/init.js'; // Import core function and its logger if needed separately
import {
enableSilentMode,
disableSilentMode
// isSilentMode // Not used directly here
} from '../../../../scripts/modules/utils.js';
import { getProjectRootFromSession } from '../../tools/utils.js'; // Adjust path if necessary
import os from 'os'; // Import os module for home directory check
/**
* Direct function wrapper for initializing a project.
* Derives target directory from session, sets CWD, and calls core init logic.
* @param {object} args - Arguments containing project details and options (projectName, projectDescription, yes, etc.)
* @param {object} log - The FastMCP logger instance.
* @param {object} context - The context object, must contain { session }.
* @returns {Promise<{success: boolean, data?: any, error?: {code: string, message: string}}>} - Standard result object.
*/
export async function initializeProjectDirect(args, log, context = {}) {
const { session } = context;
const homeDir = os.homedir();
let targetDirectory = null;
log.info(
`CONTEXT received in direct function: ${context ? JSON.stringify(Object.keys(context)) : 'MISSING or Falsy'}`
);
log.info(
`SESSION extracted in direct function: ${session ? 'Exists' : 'MISSING or Falsy'}`
);
log.info(`Args received in direct function: ${JSON.stringify(args)}`);
// --- Determine Target Directory ---
// 1. Prioritize projectRoot passed directly in args
// Ensure it's not null, '/', or the home directory
if (
args.projectRoot &&
args.projectRoot !== '/' &&
args.projectRoot !== homeDir
) {
log.info(`Using projectRoot directly from args: ${args.projectRoot}`);
targetDirectory = args.projectRoot;
} else {
// 2. If args.projectRoot is missing or invalid, THEN try session (as a fallback)
log.warn(
`args.projectRoot ('${args.projectRoot}') is missing or invalid. Attempting to derive from session.`
);
const sessionDerivedPath = getProjectRootFromSession(session, log);
// Validate the session-derived path as well
if (
sessionDerivedPath &&
sessionDerivedPath !== '/' &&
sessionDerivedPath !== homeDir
) {
log.info(
`Using project root derived from session: ${sessionDerivedPath}`
);
targetDirectory = sessionDerivedPath;
} else {
log.error(
`Could not determine a valid project root. args.projectRoot='${args.projectRoot}', sessionDerivedPath='${sessionDerivedPath}'`
);
}
}
// 3. Validate the final targetDirectory
if (!targetDirectory) {
// This error now covers cases where neither args.projectRoot nor session provided a valid path
return {
success: false,
error: {
code: 'INVALID_TARGET_DIRECTORY',
message: `Cannot initialize project: Could not determine a valid target directory. Please ensure a workspace/folder is open or specify projectRoot.`,
details: `Attempted args.projectRoot: ${args.projectRoot}`
},
fromCache: false
};
}
// --- Proceed with validated targetDirectory ---
log.info(`Validated target directory for initialization: ${targetDirectory}`);
const originalCwd = process.cwd();
let resultData;
let success = false;
let errorResult = null;
log.info(
`Temporarily changing CWD to ${targetDirectory} for initialization.`
);
process.chdir(targetDirectory); // Change CWD to the *validated* targetDirectory
enableSilentMode(); // Enable silent mode BEFORE calling the core function
try {
// Always force yes: true when called via MCP to avoid interactive prompts
const options = {
name: args.projectName,
description: args.projectDescription,
version: args.projectVersion,
author: args.authorName,
skipInstall: args.skipInstall,
aliases: args.addAliases,
yes: true // Force yes mode
};
log.info(`Initializing project with options: ${JSON.stringify(options)}`);
const result = await initializeProject(options); // Call core logic
// Format success result for handleApiResult
resultData = {
message: 'Project initialized successfully.',
next_step:
'Now that the project is initialized, the next step is to create the tasks by parsing a PRD. This will create the tasks folder and the initial task files (tasks folder will be created when parse-prd is run). The parse-prd tool will require a prd.txt file as input (typically found in the project root directory, scripts/ directory). You can create a prd.txt file by asking the user about their idea, and then using the scripts/example_prd.txt file as a template to genrate a prd.txt file in scripts/. You may skip all of this if the user already has a prd.txt file. You can THEN use the parse-prd tool to create the tasks. So: step 1 after initialization is to create a prd.txt file in scripts/prd.txt or confirm the user already has one. Step 2 is to use the parse-prd tool to create the tasks. Do not bother looking for tasks after initialization, just use the parse-prd tool to create the tasks after creating a prd.txt from which to parse the tasks. You do NOT need to reinitialize the project to parse-prd.',
...result // Include details returned by initializeProject
};
success = true;
log.info(
`Project initialization completed successfully in ${targetDirectory}.`
);
} catch (error) {
log.error(`Core initializeProject failed: ${error.message}`);
errorResult = {
code: 'INITIALIZATION_FAILED',
message: `Core project initialization failed: ${error.message}`,
details: error.stack
};
success = false;
} finally {
disableSilentMode(); // ALWAYS disable silent mode in finally
log.info(`Restoring original CWD: ${originalCwd}`);
process.chdir(originalCwd); // Change back to original CWD
}
// Return in format expected by handleApiResult
if (success) {
return { success: true, data: resultData, fromCache: false };
} else {
return { success: false, error: errorResult, fromCache: false };
}
}

View File

@@ -0,0 +1,112 @@
/**
* list-tasks.js
* Direct function implementation for listing tasks
*/
import { listTasks } from '../../../../scripts/modules/task-manager.js';
import { getCachedOrExecute } from '../../tools/utils.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for listTasks with error handling and caching.
*
* @param {Object} args - Command arguments (now expecting tasksJsonPath explicitly).
* @param {Object} log - Logger object.
* @returns {Promise<Object>} - Task list result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: boolean }.
*/
export async function listTasksDirect(args, log) {
// Destructure the explicit tasksJsonPath from args
const { tasksJsonPath, status, withSubtasks } = args;
if (!tasksJsonPath) {
log.error('listTasksDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
},
fromCache: false
};
}
// Use the explicit tasksJsonPath for cache key
const statusFilter = status || 'all';
const withSubtasksFilter = withSubtasks || false;
const cacheKey = `listTasks:${tasksJsonPath}:${statusFilter}:${withSubtasksFilter}`;
// Define the action function to be executed on cache miss
const coreListTasksAction = async () => {
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
log.info(
`Executing core listTasks function for path: ${tasksJsonPath}, filter: ${statusFilter}, subtasks: ${withSubtasksFilter}`
);
// Pass the explicit tasksJsonPath to the core function
const resultData = listTasks(
tasksJsonPath,
statusFilter,
withSubtasksFilter,
'json'
);
if (!resultData || !resultData.tasks) {
log.error('Invalid or empty response from listTasks core function');
return {
success: false,
error: {
code: 'INVALID_CORE_RESPONSE',
message: 'Invalid or empty response from listTasks core function'
}
};
}
log.info(
`Core listTasks function retrieved ${resultData.tasks.length} tasks`
);
// Restore normal logging
disableSilentMode();
return { success: true, data: resultData };
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Core listTasks function failed: ${error.message}`);
return {
success: false,
error: {
code: 'LIST_TASKS_CORE_ERROR',
message: error.message || 'Failed to list tasks'
}
};
}
};
// Use the caching utility
try {
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreListTasksAction,
log
});
log.info(`listTasksDirect completed. From cache: ${result.fromCache}`);
return result; // Returns { success, data/error, fromCache }
} catch (error) {
// Catch unexpected errors from getCachedOrExecute itself (though unlikely)
log.error(
`Unexpected error during getCachedOrExecute for listTasks: ${error.message}`
);
console.error(error.stack);
return {
success: false,
error: { code: 'CACHE_UTIL_ERROR', message: error.message },
fromCache: false
};
}
}

View File

@@ -0,0 +1,132 @@
/**
* next-task.js
* Direct function implementation for finding the next task to work on
*/
import { findNextTask } from '../../../../scripts/modules/task-manager.js';
import { readJSON } from '../../../../scripts/modules/utils.js';
import { getCachedOrExecute } from '../../tools/utils.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for finding the next task to work on with error handling and caching.
*
* @param {Object} args - Command arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {Object} log - Logger object
* @returns {Promise<Object>} - Next task result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: boolean }
*/
export async function nextTaskDirect(args, log) {
// Destructure expected args
const { tasksJsonPath } = args;
if (!tasksJsonPath) {
log.error('nextTaskDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
},
fromCache: false
};
}
// Generate cache key using the provided task path
const cacheKey = `nextTask:${tasksJsonPath}`;
// Define the action function to be executed on cache miss
const coreNextTaskAction = async () => {
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
log.info(`Finding next task from ${tasksJsonPath}`);
// Read tasks data using the provided path
const data = readJSON(tasksJsonPath);
if (!data || !data.tasks) {
disableSilentMode(); // Disable before return
return {
success: false,
error: {
code: 'INVALID_TASKS_FILE',
message: `No valid tasks found in ${tasksJsonPath}`
}
};
}
// Find the next task
const nextTask = findNextTask(data.tasks);
if (!nextTask) {
log.info(
'No eligible next task found. All tasks are either completed or have unsatisfied dependencies'
);
return {
success: true,
data: {
message:
'No eligible next task found. All tasks are either completed or have unsatisfied dependencies',
nextTask: null,
allTasks: data.tasks
}
};
}
// Restore normal logging
disableSilentMode();
// Return the next task data with the full tasks array for reference
log.info(
`Successfully found next task ${nextTask.id}: ${nextTask.title}`
);
return {
success: true,
data: {
nextTask,
allTasks: data.tasks
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error finding next task: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message || 'Failed to find next task'
}
};
}
};
// Use the caching utility
try {
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreNextTaskAction,
log
});
log.info(`nextTaskDirect completed. From cache: ${result.fromCache}`);
return result; // Returns { success, data/error, fromCache }
} catch (error) {
// Catch unexpected errors from getCachedOrExecute itself
log.error(
`Unexpected error during getCachedOrExecute for nextTask: ${error.message}`
);
return {
success: false,
error: {
code: 'UNEXPECTED_ERROR',
message: error.message
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,210 @@
/**
* parse-prd.js
* Direct function implementation for parsing PRD documents
*/
import path from 'path';
import fs from 'fs';
import os from 'os'; // Import os module for home directory check
import { parsePRD } from '../../../../scripts/modules/task-manager.js';
import { findTasksJsonPath } from '../utils/path-utils.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getModelConfig
} from '../utils/ai-client-utils.js';
/**
* Direct function wrapper for parsing PRD documents and generating tasks.
*
* @param {Object} args - Command arguments containing input, numTasks or tasks, and output options.
* @param {Object} log - Logger object.
* @param {Object} context - Context object containing session data.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function parsePRDDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
try {
log.info(`Parsing PRD document with args: ${JSON.stringify(args)}`);
// Initialize AI client for PRD parsing
let aiClient;
try {
aiClient = getAnthropicClientForMCP(session, log);
} catch (error) {
log.error(`Failed to initialize AI client: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
},
fromCache: false
};
}
// Validate required parameters
if (!args.projectRoot) {
const errorMessage = 'Project root is required for parsePRDDirect';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_PROJECT_ROOT', message: errorMessage },
fromCache: false
};
}
if (!args.input) {
const errorMessage = 'Input file path is required for parsePRDDirect';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_INPUT_PATH', message: errorMessage },
fromCache: false
};
}
if (!args.output) {
const errorMessage = 'Output file path is required for parsePRDDirect';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_OUTPUT_PATH', message: errorMessage },
fromCache: false
};
}
// Resolve input path (expecting absolute path or path relative to project root)
const projectRoot = args.projectRoot;
const inputPath = path.isAbsolute(args.input)
? args.input
: path.resolve(projectRoot, args.input);
// Verify input file exists
if (!fs.existsSync(inputPath)) {
const errorMessage = `Input file not found: ${inputPath}`;
log.error(errorMessage);
return {
success: false,
error: {
code: 'INPUT_FILE_NOT_FOUND',
message: errorMessage,
details: `Checked path: ${inputPath}\nProject root: ${projectRoot}\nInput argument: ${args.input}`
},
fromCache: false
};
}
// Resolve output path (expecting absolute path or path relative to project root)
const outputPath = path.isAbsolute(args.output)
? args.output
: path.resolve(projectRoot, args.output);
// Ensure output directory exists
const outputDir = path.dirname(outputPath);
if (!fs.existsSync(outputDir)) {
log.info(`Creating output directory: ${outputDir}`);
fs.mkdirSync(outputDir, { recursive: true });
}
// Parse number of tasks - handle both string and number values
let numTasks = 10; // Default
if (args.numTasks) {
numTasks =
typeof args.numTasks === 'string'
? parseInt(args.numTasks, 10)
: args.numTasks;
if (isNaN(numTasks)) {
numTasks = 10; // Fallback to default if parsing fails
log.warn(`Invalid numTasks value: ${args.numTasks}. Using default: 10`);
}
}
log.info(
`Preparing to parse PRD from ${inputPath} and output to ${outputPath} with ${numTasks} tasks`
);
// Create the logger wrapper for proper logging in the core function
const logWrapper = {
info: (message, ...args) => log.info(message, ...args),
warn: (message, ...args) => log.warn(message, ...args),
error: (message, ...args) => log.error(message, ...args),
debug: (message, ...args) => log.debug && log.debug(message, ...args),
success: (message, ...args) => log.info(message, ...args) // Map success to info
};
// Get model config from session
const modelConfig = getModelConfig(session);
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
try {
// Make sure the output directory exists
const outputDir = path.dirname(outputPath);
if (!fs.existsSync(outputDir)) {
log.info(`Creating output directory: ${outputDir}`);
fs.mkdirSync(outputDir, { recursive: true });
}
// Execute core parsePRD function with AI client
await parsePRD(
inputPath,
outputPath,
numTasks,
{
mcpLog: logWrapper,
session
},
aiClient,
modelConfig
);
// Since parsePRD doesn't return a value but writes to a file, we'll read the result
// to return it to the caller
if (fs.existsSync(outputPath)) {
const tasksData = JSON.parse(fs.readFileSync(outputPath, 'utf8'));
log.info(
`Successfully parsed PRD and generated ${tasksData.tasks?.length || 0} tasks`
);
return {
success: true,
data: {
message: `Successfully generated ${tasksData.tasks?.length || 0} tasks from PRD`,
taskCount: tasksData.tasks?.length || 0,
outputPath
},
fromCache: false // This operation always modifies state and should never be cached
};
} else {
const errorMessage = `Tasks file was not created at ${outputPath}`;
log.error(errorMessage);
return {
success: false,
error: { code: 'OUTPUT_FILE_NOT_CREATED', message: errorMessage },
fromCache: false
};
}
} finally {
// Always restore normal logging
disableSilentMode();
}
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error parsing PRD: ${error.message}`);
return {
success: false,
error: {
code: 'PARSE_PRD_ERROR',
message: error.message || 'Unknown error parsing PRD'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,104 @@
/**
* Direct function wrapper for removeDependency
*/
import { removeDependency } from '../../../../scripts/modules/dependency-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Remove a dependency from a task
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string|number} args.id - Task ID to remove dependency from
* @param {string|number} args.dependsOn - Task ID to remove as a dependency
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function removeDependencyDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id, dependsOn } = args;
try {
log.info(`Removing dependency with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('removeDependencyDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
// Validate required parameters
if (!id) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Task ID (id) is required'
}
};
}
if (!dependsOn) {
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Dependency ID (dependsOn) is required'
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Format IDs for the core function
const taskId =
id && id.includes && id.includes('.') ? id : parseInt(id, 10);
const dependencyId =
dependsOn && dependsOn.includes && dependsOn.includes('.')
? dependsOn
: parseInt(dependsOn, 10);
log.info(
`Removing dependency: task ${taskId} no longer depends on ${dependencyId}`
);
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the core function using the provided tasksPath
await removeDependency(tasksPath, taskId, dependencyId);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: `Successfully removed dependency: Task ${taskId} no longer depends on ${dependencyId}`,
taskId: taskId,
dependencyId: dependencyId
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error in removeDependencyDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,122 @@
/**
* Direct function wrapper for removeSubtask
*/
import { removeSubtask } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Remove a subtask from its parent task
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.id - Subtask ID in format "parentId.subtaskId" (required)
* @param {boolean} [args.convert] - Whether to convert the subtask to a standalone task
* @param {boolean} [args.skipGenerate] - Skip regenerating task files
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function removeSubtaskDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id, convert, skipGenerate } = args;
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
log.info(`Removing subtask with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('removeSubtaskDirect called without tasksJsonPath');
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
if (!id) {
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message:
'Subtask ID is required and must be in format "parentId.subtaskId"'
}
};
}
// Validate subtask ID format
if (!id.includes('.')) {
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: `Invalid subtask ID format: ${id}. Expected format: "parentId.subtaskId"`
}
};
}
// Use provided path
const tasksPath = tasksJsonPath;
// Convert convertToTask to a boolean
const convertToTask = convert === true;
// Determine if we should generate files
const generateFiles = !skipGenerate;
log.info(
`Removing subtask ${id} (convertToTask: ${convertToTask}, generateFiles: ${generateFiles})`
);
// Use the provided tasksPath
const result = await removeSubtask(
tasksPath,
id,
convertToTask,
generateFiles
);
// Restore normal logging
disableSilentMode();
if (convertToTask && result) {
// Return info about the converted task
return {
success: true,
data: {
message: `Subtask ${id} successfully converted to task #${result.id}`,
task: result
}
};
} else {
// Return simple success message for deletion
return {
success: true,
data: {
message: `Subtask ${id} successfully removed`
}
};
}
} catch (error) {
// Ensure silent mode is disabled even if an outer error occurs
disableSilentMode();
log.error(`Error in removeSubtaskDirect: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message
}
};
}
}

View File

@@ -0,0 +1,107 @@
/**
* remove-task.js
* Direct function implementation for removing a task
*/
import { removeTask } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for removeTask with error handling.
*
* @param {Object} args - Command arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.id - The ID of the task or subtask to remove.
* @param {Object} log - Logger object
* @returns {Promise<Object>} - Remove task result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: false }
*/
export async function removeTaskDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id } = args;
try {
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
log.error('removeTaskDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
},
fromCache: false
};
}
// Validate task ID parameter
const taskId = id;
if (!taskId) {
log.error('Task ID is required');
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Task ID is required'
},
fromCache: false
};
}
// Skip confirmation in the direct function since it's handled by the client
log.info(`Removing task with ID: ${taskId} from ${tasksJsonPath}`);
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the core removeTask function using the provided path
const result = await removeTask(tasksJsonPath, taskId);
// Restore normal logging
disableSilentMode();
log.info(`Successfully removed task: ${taskId}`);
// Return the result
return {
success: true,
data: {
message: result.message,
taskId: taskId,
tasksPath: tasksJsonPath,
removedTask: result.removedTask
},
fromCache: false
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error removing task: ${error.message}`);
return {
success: false,
error: {
code: error.code || 'REMOVE_TASK_ERROR',
message: error.message || 'Failed to remove task'
},
fromCache: false
};
}
} catch (error) {
// Ensure silent mode is disabled even if an outer error occurs
disableSilentMode();
// Catch any unexpected errors
log.error(`Unexpected error in removeTaskDirect: ${error.message}`);
return {
success: false,
error: {
code: 'UNEXPECTED_ERROR',
message: error.message
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,119 @@
/**
* set-task-status.js
* Direct function implementation for setting task status
*/
import { setTaskStatus } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode,
isSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for setTaskStatus with error handling.
*
* @param {Object} args - Command arguments containing id, status and tasksJsonPath.
* @param {Object} log - Logger object.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function setTaskStatusDirect(args, log) {
// Destructure expected args, including the resolved tasksJsonPath
const { tasksJsonPath, id, status } = args;
try {
log.info(`Setting task status with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
const errorMessage = 'tasksJsonPath is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
// Check required parameters (id and status)
if (!id) {
const errorMessage =
'No task ID specified. Please provide a task ID to update.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_TASK_ID', message: errorMessage },
fromCache: false
};
}
if (!status) {
const errorMessage =
'No status specified. Please provide a new status value.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_STATUS', message: errorMessage },
fromCache: false
};
}
// Use the provided path
const tasksPath = tasksJsonPath;
// Execute core setTaskStatus function
const taskId = id;
const newStatus = status;
log.info(`Setting task ${taskId} status to "${newStatus}"`);
// Call the core function with proper silent mode handling
enableSilentMode(); // Enable silent mode before calling core function
try {
// Call the core function
await setTaskStatus(tasksPath, taskId, newStatus, { mcpLog: log });
log.info(`Successfully set task ${taskId} status to ${newStatus}`);
// Return success data
const result = {
success: true,
data: {
message: `Successfully updated task ${taskId} status to "${newStatus}"`,
taskId,
status: newStatus,
tasksPath: tasksPath // Return the path used
},
fromCache: false // This operation always modifies state and should never be cached
};
return result;
} catch (error) {
log.error(`Error setting task status: ${error.message}`);
return {
success: false,
error: {
code: 'SET_STATUS_ERROR',
message: error.message || 'Unknown error setting task status'
},
fromCache: false
};
} finally {
// ALWAYS restore normal logging in finally block
disableSilentMode();
}
} catch (error) {
// Ensure silent mode is disabled if there was an uncaught error in the outer try block
if (isSilentMode()) {
disableSilentMode();
}
log.error(`Error setting task status: ${error.message}`);
return {
success: false,
error: {
code: 'SET_STATUS_ERROR',
message: error.message || 'Unknown error setting task status'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,145 @@
/**
* show-task.js
* Direct function implementation for showing task details
*/
import { findTaskById } from '../../../../scripts/modules/utils.js';
import { readJSON } from '../../../../scripts/modules/utils.js';
import { getCachedOrExecute } from '../../tools/utils.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
/**
* Direct function wrapper for showing task details with error handling and caching.
*
* @param {Object} args - Command arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {string} args.id - The ID of the task or subtask to show.
* @param {Object} log - Logger object
* @returns {Promise<Object>} - Task details result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: boolean }
*/
export async function showTaskDirect(args, log) {
// Destructure expected args
const { tasksJsonPath, id } = args;
if (!tasksJsonPath) {
log.error('showTaskDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
},
fromCache: false
};
}
// Validate task ID
const taskId = id;
if (!taskId) {
log.error('Task ID is required');
return {
success: false,
error: {
code: 'INPUT_VALIDATION_ERROR',
message: 'Task ID is required'
},
fromCache: false
};
}
// Generate cache key using the provided task path and ID
const cacheKey = `showTask:${tasksJsonPath}:${taskId}`;
// Define the action function to be executed on cache miss
const coreShowTaskAction = async () => {
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
log.info(
`Retrieving task details for ID: ${taskId} from ${tasksJsonPath}`
);
// Read tasks data using the provided path
const data = readJSON(tasksJsonPath);
if (!data || !data.tasks) {
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'INVALID_TASKS_FILE',
message: `No valid tasks found in ${tasksJsonPath}`
}
};
}
// Find the specific task
const task = findTaskById(data.tasks, taskId);
if (!task) {
disableSilentMode(); // Disable before returning
return {
success: false,
error: {
code: 'TASK_NOT_FOUND',
message: `Task with ID ${taskId} not found`
}
};
}
// Restore normal logging
disableSilentMode();
// Return the task data with the full tasks array for reference
// (needed for formatDependenciesWithStatus function in UI)
log.info(`Successfully found task ${taskId}`);
return {
success: true,
data: {
task,
allTasks: data.tasks
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error showing task: ${error.message}`);
return {
success: false,
error: {
code: 'CORE_FUNCTION_ERROR',
message: error.message || 'Failed to show task details'
}
};
}
};
// Use the caching utility
try {
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreShowTaskAction,
log
});
log.info(`showTaskDirect completed. From cache: ${result.fromCache}`);
return result; // Returns { success, data/error, fromCache }
} catch (error) {
// Catch unexpected errors from getCachedOrExecute itself
disableSilentMode();
log.error(
`Unexpected error during getCachedOrExecute for showTask: ${error.message}`
);
return {
success: false,
error: {
code: 'UNEXPECTED_ERROR',
message: error.message
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,194 @@
/**
* update-subtask-by-id.js
* Direct function implementation for appending information to a specific subtask
*/
import { updateSubtaskById } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getPerplexityClientForMCP
} from '../utils/ai-client-utils.js';
/**
* Direct function wrapper for updateSubtaskById with error handling.
*
* @param {Object} args - Command arguments containing id, prompt, useResearch and tasksJsonPath.
* @param {Object} log - Logger object.
* @param {Object} context - Context object containing session data.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function updateSubtaskByIdDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
const { tasksJsonPath, id, prompt, research } = args;
try {
log.info(`Updating subtask with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
const errorMessage = 'tasksJsonPath is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
// Check required parameters (id and prompt)
if (!id) {
const errorMessage =
'No subtask ID specified. Please provide a subtask ID to update.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_SUBTASK_ID', message: errorMessage },
fromCache: false
};
}
if (!prompt) {
const errorMessage =
'No prompt specified. Please provide a prompt with information to add to the subtask.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_PROMPT', message: errorMessage },
fromCache: false
};
}
// Validate subtask ID format
const subtaskId = id;
if (typeof subtaskId !== 'string' && typeof subtaskId !== 'number') {
const errorMessage = `Invalid subtask ID type: ${typeof subtaskId}. Subtask ID must be a string or number.`;
log.error(errorMessage);
return {
success: false,
error: { code: 'INVALID_SUBTASK_ID_TYPE', message: errorMessage },
fromCache: false
};
}
const subtaskIdStr = String(subtaskId);
if (!subtaskIdStr.includes('.')) {
const errorMessage = `Invalid subtask ID format: ${subtaskIdStr}. Subtask ID must be in format "parentId.subtaskId" (e.g., "5.2").`;
log.error(errorMessage);
return {
success: false,
error: { code: 'INVALID_SUBTASK_ID_FORMAT', message: errorMessage },
fromCache: false
};
}
// Use the provided path
const tasksPath = tasksJsonPath;
// Get research flag
const useResearch = research === true;
log.info(
`Updating subtask with ID ${subtaskIdStr} with prompt "${prompt}" and research: ${useResearch}`
);
// Initialize the appropriate AI client based on research flag
try {
if (useResearch) {
// Initialize Perplexity client
await getPerplexityClientForMCP(session);
} else {
// Initialize Anthropic client
await getAnthropicClientForMCP(session);
}
} catch (error) {
log.error(`AI client initialization error: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: error.message || 'Failed to initialize AI client'
},
fromCache: false
};
}
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Create a logger wrapper object to handle logging without breaking the mcpLog[level] calls
// This ensures outputFormat is set to 'json' while still supporting proper logging
const logWrapper = {
info: (message) => log.info(message),
warn: (message) => log.warn(message),
error: (message) => log.error(message),
debug: (message) => log.debug && log.debug(message),
success: (message) => log.info(message) // Map success to info if needed
};
// Execute core updateSubtaskById function
// Pass both session and logWrapper as mcpLog to ensure outputFormat is 'json'
const updatedSubtask = await updateSubtaskById(
tasksPath,
subtaskIdStr,
prompt,
useResearch,
{
session,
mcpLog: logWrapper
}
);
// Restore normal logging
disableSilentMode();
// Handle the case where the subtask couldn't be updated (e.g., already marked as done)
if (!updatedSubtask) {
return {
success: false,
error: {
code: 'SUBTASK_UPDATE_FAILED',
message:
'Failed to update subtask. It may be marked as completed, or another error occurred.'
},
fromCache: false
};
}
// Return the updated subtask information
return {
success: true,
data: {
message: `Successfully updated subtask with ID ${subtaskIdStr}`,
subtaskId: subtaskIdStr,
parentId: subtaskIdStr.split('.')[0],
subtask: updatedSubtask,
tasksPath,
useResearch
},
fromCache: false // This operation always modifies state and should never be cached
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
throw error; // Rethrow to be caught by outer catch block
}
} catch (error) {
// Ensure silent mode is disabled
disableSilentMode();
log.error(`Error updating subtask by ID: ${error.message}`);
return {
success: false,
error: {
code: 'UPDATE_SUBTASK_ERROR',
message: error.message || 'Unknown error updating subtask'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,187 @@
/**
* update-task-by-id.js
* Direct function implementation for updating a single task by ID with new information
*/
import { updateTaskById } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getPerplexityClientForMCP
} from '../utils/ai-client-utils.js';
/**
* Direct function wrapper for updateTaskById with error handling.
*
* @param {Object} args - Command arguments containing id, prompt, useResearch and tasksJsonPath.
* @param {Object} log - Logger object.
* @param {Object} context - Context object containing session data.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function updateTaskByIdDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
// Destructure expected args, including the resolved tasksJsonPath
const { tasksJsonPath, id, prompt, research } = args;
try {
log.info(`Updating task with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
const errorMessage = 'tasksJsonPath is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
// Check required parameters (id and prompt)
if (!id) {
const errorMessage =
'No task ID specified. Please provide a task ID to update.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_TASK_ID', message: errorMessage },
fromCache: false
};
}
if (!prompt) {
const errorMessage =
'No prompt specified. Please provide a prompt with new information for the task update.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_PROMPT', message: errorMessage },
fromCache: false
};
}
// Parse taskId - handle both string and number values
let taskId;
if (typeof id === 'string') {
// Handle subtask IDs (e.g., "5.2")
if (id.includes('.')) {
taskId = id; // Keep as string for subtask IDs
} else {
// Parse as integer for main task IDs
taskId = parseInt(id, 10);
if (isNaN(taskId)) {
const errorMessage = `Invalid task ID: ${id}. Task ID must be a positive integer or subtask ID (e.g., "5.2").`;
log.error(errorMessage);
return {
success: false,
error: { code: 'INVALID_TASK_ID', message: errorMessage },
fromCache: false
};
}
}
} else {
taskId = id;
}
// Use the provided path
const tasksPath = tasksJsonPath;
// Get research flag
const useResearch = research === true;
// Initialize appropriate AI client based on research flag
let aiClient;
try {
if (useResearch) {
log.info('Using Perplexity AI for research-backed task update');
aiClient = await getPerplexityClientForMCP(session, log);
} else {
log.info('Using Claude AI for task update');
aiClient = getAnthropicClientForMCP(session, log);
}
} catch (error) {
log.error(`Failed to initialize AI client: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
},
fromCache: false
};
}
log.info(
`Updating task with ID ${taskId} with prompt "${prompt}" and research: ${useResearch}`
);
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Create a logger wrapper that matches what updateTaskById expects
const logWrapper = {
info: (message) => log.info(message),
warn: (message) => log.warn(message),
error: (message) => log.error(message),
debug: (message) => log.debug && log.debug(message),
success: (message) => log.info(message) // Map success to info since many loggers don't have success
};
// Execute core updateTaskById function with proper parameters
await updateTaskById(
tasksPath,
taskId,
prompt,
useResearch,
{
mcpLog: logWrapper, // Use our wrapper object that has the expected method structure
session
},
'json'
);
// Since updateTaskById doesn't return a value but modifies the tasks file,
// we'll return a success message
return {
success: true,
data: {
message: `Successfully updated task with ID ${taskId} based on the prompt`,
taskId,
tasksPath: tasksPath, // Return the used path
useResearch
},
fromCache: false // This operation always modifies state and should never be cached
};
} catch (error) {
log.error(`Error updating task by ID: ${error.message}`);
return {
success: false,
error: {
code: 'UPDATE_TASK_ERROR',
message: error.message || 'Unknown error updating task'
},
fromCache: false
};
} finally {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
}
} catch (error) {
// Ensure silent mode is disabled
disableSilentMode();
log.error(`Error updating task by ID: ${error.message}`);
return {
success: false,
error: {
code: 'UPDATE_TASK_ERROR',
message: error.message || 'Unknown error updating task'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,187 @@
/**
* update-tasks.js
* Direct function implementation for updating tasks based on new context/prompt
*/
import { updateTasks } from '../../../../scripts/modules/task-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import {
getAnthropicClientForMCP,
getPerplexityClientForMCP
} from '../utils/ai-client-utils.js';
/**
* Direct function wrapper for updating tasks based on new context/prompt.
*
* @param {Object} args - Command arguments containing fromId, prompt, useResearch and tasksJsonPath.
* @param {Object} log - Logger object.
* @param {Object} context - Context object containing session data.
* @returns {Promise<Object>} - Result object with success status and data/error information.
*/
export async function updateTasksDirect(args, log, context = {}) {
const { session } = context; // Only extract session, not reportProgress
const { tasksJsonPath, from, prompt, research } = args;
try {
log.info(`Updating tasks with args: ${JSON.stringify(args)}`);
// Check if tasksJsonPath was provided
if (!tasksJsonPath) {
const errorMessage = 'tasksJsonPath is required but was not provided.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_ARGUMENT', message: errorMessage },
fromCache: false
};
}
// Check for the common mistake of using 'id' instead of 'from'
if (args.id !== undefined && from === undefined) {
const errorMessage =
"You specified 'id' parameter but 'update' requires 'from' parameter. Use 'from' for this tool or use 'update_task' tool if you want to update a single task.";
log.error(errorMessage);
return {
success: false,
error: {
code: 'PARAMETER_MISMATCH',
message: errorMessage,
suggestion:
"Use 'from' parameter instead of 'id', or use the 'update_task' tool for single task updates"
},
fromCache: false
};
}
// Check required parameters
if (!from) {
const errorMessage =
'No from ID specified. Please provide a task ID to start updating from.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_FROM_ID', message: errorMessage },
fromCache: false
};
}
if (!prompt) {
const errorMessage =
'No prompt specified. Please provide a prompt with new context for task updates.';
log.error(errorMessage);
return {
success: false,
error: { code: 'MISSING_PROMPT', message: errorMessage },
fromCache: false
};
}
// Parse fromId - handle both string and number values
let fromId;
if (typeof from === 'string') {
fromId = parseInt(from, 10);
if (isNaN(fromId)) {
const errorMessage = `Invalid from ID: ${from}. Task ID must be a positive integer.`;
log.error(errorMessage);
return {
success: false,
error: { code: 'INVALID_FROM_ID', message: errorMessage },
fromCache: false
};
}
} else {
fromId = from;
}
// Get research flag
const useResearch = research === true;
// Initialize appropriate AI client based on research flag
let aiClient;
try {
if (useResearch) {
log.info('Using Perplexity AI for research-backed task updates');
aiClient = await getPerplexityClientForMCP(session, log);
} else {
log.info('Using Claude AI for task updates');
aiClient = getAnthropicClientForMCP(session, log);
}
} catch (error) {
log.error(`Failed to initialize AI client: ${error.message}`);
return {
success: false,
error: {
code: 'AI_CLIENT_ERROR',
message: `Cannot initialize AI client: ${error.message}`
},
fromCache: false
};
}
log.info(
`Updating tasks from ID ${fromId} with prompt "${prompt}" and research: ${useResearch}`
);
// Create the logger wrapper to ensure compatibility with core functions
const logWrapper = {
info: (message, ...args) => log.info(message, ...args),
warn: (message, ...args) => log.warn(message, ...args),
error: (message, ...args) => log.error(message, ...args),
debug: (message, ...args) => log.debug && log.debug(message, ...args), // Handle optional debug
success: (message, ...args) => log.info(message, ...args) // Map success to info if needed
};
try {
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Execute core updateTasks function, passing the AI client and session
await updateTasks(tasksJsonPath, fromId, prompt, useResearch, {
mcpLog: logWrapper, // Pass the wrapper instead of the raw log object
session
});
// Since updateTasks doesn't return a value but modifies the tasks file,
// we'll return a success message
return {
success: true,
data: {
message: `Successfully updated tasks from ID ${fromId} based on the prompt`,
fromId,
tasksPath: tasksJsonPath,
useResearch
},
fromCache: false // This operation always modifies state and should never be cached
};
} catch (error) {
log.error(`Error updating tasks: ${error.message}`);
return {
success: false,
error: {
code: 'UPDATE_TASKS_ERROR',
message: error.message || 'Unknown error updating tasks'
},
fromCache: false
};
} finally {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
}
} catch (error) {
// Ensure silent mode is disabled
disableSilentMode();
log.error(`Error updating tasks: ${error.message}`);
return {
success: false,
error: {
code: 'UPDATE_TASKS_ERROR',
message: error.message || 'Unknown error updating tasks'
},
fromCache: false
};
}
}

View File

@@ -0,0 +1,80 @@
/**
* Direct function wrapper for validateDependenciesCommand
*/
import { validateDependenciesCommand } from '../../../../scripts/modules/dependency-manager.js';
import {
enableSilentMode,
disableSilentMode
} from '../../../../scripts/modules/utils.js';
import fs from 'fs';
/**
* Validate dependencies in tasks.json
* @param {Object} args - Function arguments
* @param {string} args.tasksJsonPath - Explicit path to the tasks.json file.
* @param {Object} log - Logger object
* @returns {Promise<{success: boolean, data?: Object, error?: {code: string, message: string}}>}
*/
export async function validateDependenciesDirect(args, log) {
// Destructure the explicit tasksJsonPath
const { tasksJsonPath } = args;
if (!tasksJsonPath) {
log.error('validateDependenciesDirect called without tasksJsonPath');
return {
success: false,
error: {
code: 'MISSING_ARGUMENT',
message: 'tasksJsonPath is required'
}
};
}
try {
log.info(`Validating dependencies in tasks: ${tasksJsonPath}`);
// Use the provided tasksJsonPath
const tasksPath = tasksJsonPath;
// Verify the file exists
if (!fs.existsSync(tasksPath)) {
return {
success: false,
error: {
code: 'FILE_NOT_FOUND',
message: `Tasks file not found at ${tasksPath}`
}
};
}
// Enable silent mode to prevent console logs from interfering with JSON response
enableSilentMode();
// Call the original command function using the provided tasksPath
await validateDependenciesCommand(tasksPath);
// Restore normal logging
disableSilentMode();
return {
success: true,
data: {
message: 'Dependencies validated successfully',
tasksPath
}
};
} catch (error) {
// Make sure to restore normal logging even if there's an error
disableSilentMode();
log.error(`Error validating dependencies: ${error.message}`);
return {
success: false,
error: {
code: 'VALIDATION_ERROR',
message: error.message
}
};
}
}

View File

@@ -1,167 +1,98 @@
/**
* task-master-core.js
* Direct function imports from Task Master modules
*
* This module provides direct access to Task Master core functions
* for improved performance and error handling compared to CLI execution.
* Central module that imports and re-exports all direct function implementations
* for improved organization and maintainability.
*/
import path from 'path';
import { fileURLToPath } from 'url';
import { dirname } from 'path';
import fs from 'fs';
// Import direct function implementations
import { listTasksDirect } from './direct-functions/list-tasks.js';
import { getCacheStatsDirect } from './direct-functions/cache-stats.js';
import { parsePRDDirect } from './direct-functions/parse-prd.js';
import { updateTasksDirect } from './direct-functions/update-tasks.js';
import { updateTaskByIdDirect } from './direct-functions/update-task-by-id.js';
import { updateSubtaskByIdDirect } from './direct-functions/update-subtask-by-id.js';
import { generateTaskFilesDirect } from './direct-functions/generate-task-files.js';
import { setTaskStatusDirect } from './direct-functions/set-task-status.js';
import { showTaskDirect } from './direct-functions/show-task.js';
import { nextTaskDirect } from './direct-functions/next-task.js';
import { expandTaskDirect } from './direct-functions/expand-task.js';
import { addTaskDirect } from './direct-functions/add-task.js';
import { addSubtaskDirect } from './direct-functions/add-subtask.js';
import { removeSubtaskDirect } from './direct-functions/remove-subtask.js';
import { analyzeTaskComplexityDirect } from './direct-functions/analyze-task-complexity.js';
import { clearSubtasksDirect } from './direct-functions/clear-subtasks.js';
import { expandAllTasksDirect } from './direct-functions/expand-all-tasks.js';
import { removeDependencyDirect } from './direct-functions/remove-dependency.js';
import { validateDependenciesDirect } from './direct-functions/validate-dependencies.js';
import { fixDependenciesDirect } from './direct-functions/fix-dependencies.js';
import { complexityReportDirect } from './direct-functions/complexity-report.js';
import { addDependencyDirect } from './direct-functions/add-dependency.js';
import { removeTaskDirect } from './direct-functions/remove-task.js';
import { initializeProjectDirect } from './direct-functions/initialize-project-direct.js';
// Get the current module's directory
const __filename = fileURLToPath(import.meta.url);
const __dirname = dirname(__filename);
// Re-export utility functions
export { findTasksJsonPath } from './utils/path-utils.js';
// Import Task Master modules
import {
listTasks,
// We'll import more functions as we continue implementation
} from '../../../scripts/modules/task-manager.js';
// Re-export AI client utilities
export {
getAnthropicClientForMCP,
getPerplexityClientForMCP,
getModelConfig,
getBestAvailableAIModel,
handleClaudeError
} from './utils/ai-client-utils.js';
// Import context manager
import { contextManager } from './context-manager.js';
import { getCachedOrExecute } from '../tools/utils.js'; // Import the utility here
// Use Map for potential future enhancements like introspection or dynamic dispatch
export const directFunctions = new Map([
['listTasksDirect', listTasksDirect],
['getCacheStatsDirect', getCacheStatsDirect],
['parsePRDDirect', parsePRDDirect],
['updateTasksDirect', updateTasksDirect],
['updateTaskByIdDirect', updateTaskByIdDirect],
['updateSubtaskByIdDirect', updateSubtaskByIdDirect],
['generateTaskFilesDirect', generateTaskFilesDirect],
['setTaskStatusDirect', setTaskStatusDirect],
['showTaskDirect', showTaskDirect],
['nextTaskDirect', nextTaskDirect],
['expandTaskDirect', expandTaskDirect],
['addTaskDirect', addTaskDirect],
['addSubtaskDirect', addSubtaskDirect],
['removeSubtaskDirect', removeSubtaskDirect],
['analyzeTaskComplexityDirect', analyzeTaskComplexityDirect],
['clearSubtasksDirect', clearSubtasksDirect],
['expandAllTasksDirect', expandAllTasksDirect],
['removeDependencyDirect', removeDependencyDirect],
['validateDependenciesDirect', validateDependenciesDirect],
['fixDependenciesDirect', fixDependenciesDirect],
['complexityReportDirect', complexityReportDirect],
['addDependencyDirect', addDependencyDirect],
['removeTaskDirect', removeTaskDirect]
]);
/**
* Finds the absolute path to the tasks.json file based on project root and arguments.
* @param {Object} args - Command arguments, potentially including 'projectRoot' and 'file'.
* @param {Object} log - Logger object.
* @returns {string} - Absolute path to the tasks.json file.
* @throws {Error} - If tasks.json cannot be found.
*/
function findTasksJsonPath(args, log) {
// Assume projectRoot is already normalized absolute path if passed in args
// Or use getProjectRoot if we decide to centralize that logic
const projectRoot = args.projectRoot || process.cwd();
log.info(`Searching for tasks.json within project root: ${projectRoot}`);
const possiblePaths = [];
// 1. If a file is explicitly provided relative to projectRoot
if (args.file) {
possiblePaths.push(path.resolve(projectRoot, args.file));
}
// 2. Check the standard locations relative to projectRoot
possiblePaths.push(
path.join(projectRoot, 'tasks.json'),
path.join(projectRoot, 'tasks', 'tasks.json')
);
log.info(`Checking potential task file paths: ${possiblePaths.join(', ')}`);
// Find the first existing path
for (const p of possiblePaths) {
if (fs.existsSync(p)) {
log.info(`Found tasks file at: ${p}`);
return p;
}
}
// If no file was found, throw an error
const error = new Error(`Tasks file not found in any of the expected locations relative to ${projectRoot}: ${possiblePaths.join(', ')}`);
error.code = 'TASKS_FILE_NOT_FOUND';
throw error;
}
/**
* Direct function wrapper for listTasks with error handling and caching.
*
* @param {Object} args - Command arguments (projectRoot is expected to be resolved).
* @param {Object} log - Logger object.
* @returns {Promise<Object>} - Task list result { success: boolean, data?: any, error?: { code: string, message: string }, fromCache: boolean }.
*/
export async function listTasksDirect(args, log) {
let tasksPath;
try {
// Find the tasks path first - needed for cache key and execution
tasksPath = findTasksJsonPath(args, log);
} catch (error) {
if (error.code === 'TASKS_FILE_NOT_FOUND') {
log.error(`Tasks file not found: ${error.message}`);
// Return the error structure expected by the calling tool/handler
return { success: false, error: { code: error.code, message: error.message }, fromCache: false };
}
log.error(`Unexpected error finding tasks file: ${error.message}`);
// Re-throw for outer catch or return structured error
return { success: false, error: { code: 'FIND_TASKS_PATH_ERROR', message: error.message }, fromCache: false };
}
// Generate cache key *after* finding tasksPath
const statusFilter = args.status || 'all';
const withSubtasks = args.withSubtasks || false;
const cacheKey = `listTasks:${tasksPath}:${statusFilter}:${withSubtasks}`;
// Define the action function to be executed on cache miss
const coreListTasksAction = async () => {
try {
log.info(`Executing core listTasks function for path: ${tasksPath}, filter: ${statusFilter}, subtasks: ${withSubtasks}`);
const resultData = listTasks(tasksPath, statusFilter, withSubtasks, 'json');
if (!resultData || !resultData.tasks) {
log.error('Invalid or empty response from listTasks core function');
return { success: false, error: { code: 'INVALID_CORE_RESPONSE', message: 'Invalid or empty response from listTasks core function' } };
}
log.info(`Core listTasks function retrieved ${resultData.tasks.length} tasks`);
return { success: true, data: resultData };
} catch (error) {
log.error(`Core listTasks function failed: ${error.message}`);
return { success: false, error: { code: 'LIST_TASKS_CORE_ERROR', message: error.message || 'Failed to list tasks' } };
}
};
// Use the caching utility
try {
const result = await getCachedOrExecute({
cacheKey,
actionFn: coreListTasksAction,
log
});
log.info(`listTasksDirect completed. From cache: ${result.fromCache}`);
return result; // Returns { success, data/error, fromCache }
} catch(error) {
// Catch unexpected errors from getCachedOrExecute itself (though unlikely)
log.error(`Unexpected error during getCachedOrExecute for listTasks: ${error.message}`);
console.error(error.stack);
return { success: false, error: { code: 'CACHE_UTIL_ERROR', message: error.message }, fromCache: false };
}
}
/**
* Get cache statistics for monitoring
* @param {Object} args - Command arguments
* @param {Object} log - Logger object
* @returns {Object} - Cache statistics
*/
export async function getCacheStatsDirect(args, log) {
try {
log.info('Retrieving cache statistics');
const stats = contextManager.getStats();
return {
success: true,
data: stats
};
} catch (error) {
log.error(`Error getting cache stats: ${error.message}`);
return {
success: false,
error: {
code: 'CACHE_STATS_ERROR',
message: error.message || 'Unknown error occurred'
}
};
}
}
/**
* Maps Task Master functions to their direct implementation
*/
export const directFunctions = {
list: listTasksDirect,
cacheStats: getCacheStatsDirect,
// Add more functions as we implement them
// Re-export all direct function implementations
export {
listTasksDirect,
getCacheStatsDirect,
parsePRDDirect,
updateTasksDirect,
updateTaskByIdDirect,
updateSubtaskByIdDirect,
generateTaskFilesDirect,
setTaskStatusDirect,
showTaskDirect,
nextTaskDirect,
expandTaskDirect,
addTaskDirect,
addSubtaskDirect,
removeSubtaskDirect,
analyzeTaskComplexityDirect,
clearSubtasksDirect,
expandAllTasksDirect,
removeDependencyDirect,
validateDependenciesDirect,
fixDependenciesDirect,
complexityReportDirect,
addDependencyDirect,
removeTaskDirect,
initializeProjectDirect
};

View File

@@ -0,0 +1,213 @@
/**
* ai-client-utils.js
* Utility functions for initializing AI clients in MCP context
*/
import { Anthropic } from '@anthropic-ai/sdk';
import dotenv from 'dotenv';
// Load environment variables for CLI mode
dotenv.config();
// Default model configuration from CLI environment
const DEFAULT_MODEL_CONFIG = {
model: 'claude-3-7-sonnet-20250219',
maxTokens: 64000,
temperature: 0.2
};
/**
* Get an Anthropic client instance initialized with MCP session environment variables
* @param {Object} [session] - Session object from MCP containing environment variables
* @param {Object} [log] - Logger object to use (defaults to console)
* @returns {Anthropic} Anthropic client instance
* @throws {Error} If API key is missing
*/
export function getAnthropicClientForMCP(session, log = console) {
try {
// Extract API key from session.env or fall back to environment variables
const apiKey =
session?.env?.ANTHROPIC_API_KEY || process.env.ANTHROPIC_API_KEY;
if (!apiKey) {
throw new Error(
'ANTHROPIC_API_KEY not found in session environment or process.env'
);
}
// Initialize and return a new Anthropic client
return new Anthropic({
apiKey,
defaultHeaders: {
'anthropic-beta': 'output-128k-2025-02-19' // Include header for increased token limit
}
});
} catch (error) {
log.error(`Failed to initialize Anthropic client: ${error.message}`);
throw error;
}
}
/**
* Get a Perplexity client instance initialized with MCP session environment variables
* @param {Object} [session] - Session object from MCP containing environment variables
* @param {Object} [log] - Logger object to use (defaults to console)
* @returns {OpenAI} OpenAI client configured for Perplexity API
* @throws {Error} If API key is missing or OpenAI package can't be imported
*/
export async function getPerplexityClientForMCP(session, log = console) {
try {
// Extract API key from session.env or fall back to environment variables
const apiKey =
session?.env?.PERPLEXITY_API_KEY || process.env.PERPLEXITY_API_KEY;
if (!apiKey) {
throw new Error(
'PERPLEXITY_API_KEY not found in session environment or process.env'
);
}
// Dynamically import OpenAI (it may not be used in all contexts)
const { default: OpenAI } = await import('openai');
// Initialize and return a new OpenAI client configured for Perplexity
return new OpenAI({
apiKey,
baseURL: 'https://api.perplexity.ai'
});
} catch (error) {
log.error(`Failed to initialize Perplexity client: ${error.message}`);
throw error;
}
}
/**
* Get model configuration from session environment or fall back to defaults
* @param {Object} [session] - Session object from MCP containing environment variables
* @param {Object} [defaults] - Default model configuration to use if not in session
* @returns {Object} Model configuration with model, maxTokens, and temperature
*/
export function getModelConfig(session, defaults = DEFAULT_MODEL_CONFIG) {
// Get values from session or fall back to defaults
return {
model: session?.env?.MODEL || defaults.model,
maxTokens: parseInt(session?.env?.MAX_TOKENS || defaults.maxTokens),
temperature: parseFloat(session?.env?.TEMPERATURE || defaults.temperature)
};
}
/**
* Returns the best available AI model based on specified options
* @param {Object} session - Session object from MCP containing environment variables
* @param {Object} options - Options for model selection
* @param {boolean} [options.requiresResearch=false] - Whether the operation requires research capabilities
* @param {boolean} [options.claudeOverloaded=false] - Whether Claude is currently overloaded
* @param {Object} [log] - Logger object to use (defaults to console)
* @returns {Promise<Object>} Selected model info with type and client
* @throws {Error} If no AI models are available
*/
export async function getBestAvailableAIModel(
session,
options = {},
log = console
) {
const { requiresResearch = false, claudeOverloaded = false } = options;
// Test case: When research is needed but no Perplexity, use Claude
if (
requiresResearch &&
!(session?.env?.PERPLEXITY_API_KEY || process.env.PERPLEXITY_API_KEY) &&
(session?.env?.ANTHROPIC_API_KEY || process.env.ANTHROPIC_API_KEY)
) {
try {
log.warn('Perplexity not available for research, using Claude');
const client = getAnthropicClientForMCP(session, log);
return { type: 'claude', client };
} catch (error) {
log.error(`Claude not available: ${error.message}`);
throw new Error('No AI models available for research');
}
}
// Regular path: Perplexity for research when available
if (
requiresResearch &&
(session?.env?.PERPLEXITY_API_KEY || process.env.PERPLEXITY_API_KEY)
) {
try {
const client = await getPerplexityClientForMCP(session, log);
return { type: 'perplexity', client };
} catch (error) {
log.warn(`Perplexity not available: ${error.message}`);
// Fall through to Claude as backup
}
}
// Test case: Claude for overloaded scenario
if (
claudeOverloaded &&
(session?.env?.ANTHROPIC_API_KEY || process.env.ANTHROPIC_API_KEY)
) {
try {
log.warn(
'Claude is overloaded but no alternatives are available. Proceeding with Claude anyway.'
);
const client = getAnthropicClientForMCP(session, log);
return { type: 'claude', client };
} catch (error) {
log.error(
`Claude not available despite being overloaded: ${error.message}`
);
throw new Error('No AI models available');
}
}
// Default case: Use Claude when available and not overloaded
if (
!claudeOverloaded &&
(session?.env?.ANTHROPIC_API_KEY || process.env.ANTHROPIC_API_KEY)
) {
try {
const client = getAnthropicClientForMCP(session, log);
return { type: 'claude', client };
} catch (error) {
log.warn(`Claude not available: ${error.message}`);
// Fall through to error if no other options
}
}
// If we got here, no models were successfully initialized
throw new Error('No AI models available. Please check your API keys.');
}
/**
* Handle Claude API errors with user-friendly messages
* @param {Error} error - The error from Claude API
* @returns {string} User-friendly error message
*/
export function handleClaudeError(error) {
// Check if it's a structured error response
if (error.type === 'error' && error.error) {
switch (error.error.type) {
case 'overloaded_error':
return 'Claude is currently experiencing high demand and is overloaded. Please wait a few minutes and try again.';
case 'rate_limit_error':
return 'You have exceeded the rate limit. Please wait a few minutes before making more requests.';
case 'invalid_request_error':
return 'There was an issue with the request format. If this persists, please report it as a bug.';
default:
return `Claude API error: ${error.error.message}`;
}
}
// Check for network/timeout errors
if (error.message?.toLowerCase().includes('timeout')) {
return 'The request to Claude timed out. Please try again.';
}
if (error.message?.toLowerCase().includes('network')) {
return 'There was a network error connecting to Claude. Please check your internet connection and try again.';
}
// Default error message
return `Error communicating with Claude: ${error.message}`;
}

View File

@@ -0,0 +1,251 @@
import { v4 as uuidv4 } from 'uuid';
class AsyncOperationManager {
constructor() {
this.operations = new Map(); // Stores active operation state
this.completedOperations = new Map(); // Stores completed operations
this.maxCompletedOperations = 100; // Maximum number of completed operations to store
this.listeners = new Map(); // For potential future notifications
}
/**
* Adds an operation to be executed asynchronously.
* @param {Function} operationFn - The async function to execute (e.g., a Direct function).
* @param {Object} args - Arguments to pass to the operationFn.
* @param {Object} context - The MCP tool context { log, reportProgress, session }.
* @returns {string} The unique ID assigned to this operation.
*/
addOperation(operationFn, args, context) {
const operationId = `op-${uuidv4()}`;
const operation = {
id: operationId,
status: 'pending',
startTime: Date.now(),
endTime: null,
result: null,
error: null,
// Store necessary parts of context, especially log for background execution
log: context.log,
reportProgress: context.reportProgress, // Pass reportProgress through
session: context.session // Pass session through if needed by the operationFn
};
this.operations.set(operationId, operation);
this.log(operationId, 'info', `Operation added.`);
// Start execution in the background (don't await here)
this._runOperation(operationId, operationFn, args, context).catch((err) => {
// Catch unexpected errors during the async execution setup itself
this.log(
operationId,
'error',
`Critical error starting operation: ${err.message}`,
{ stack: err.stack }
);
operation.status = 'failed';
operation.error = {
code: 'MANAGER_EXECUTION_ERROR',
message: err.message
};
operation.endTime = Date.now();
// Move to completed operations
this._moveToCompleted(operationId);
});
return operationId;
}
/**
* Internal function to execute the operation.
* @param {string} operationId - The ID of the operation.
* @param {Function} operationFn - The async function to execute.
* @param {Object} args - Arguments for the function.
* @param {Object} context - The original MCP tool context.
*/
async _runOperation(operationId, operationFn, args, context) {
const operation = this.operations.get(operationId);
if (!operation) return; // Should not happen
operation.status = 'running';
this.log(operationId, 'info', `Operation running.`);
this.emit('statusChanged', { operationId, status: 'running' });
try {
// Pass the necessary context parts to the direct function
// The direct function needs to be adapted if it needs reportProgress
// We pass the original context's log, plus our wrapped reportProgress
const result = await operationFn(args, operation.log, {
reportProgress: (progress) =>
this._handleProgress(operationId, progress),
mcpLog: operation.log, // Pass log as mcpLog if direct fn expects it
session: operation.session
});
operation.status = result.success ? 'completed' : 'failed';
operation.result = result.success ? result.data : null;
operation.error = result.success ? null : result.error;
this.log(
operationId,
'info',
`Operation finished with status: ${operation.status}`
);
} catch (error) {
this.log(
operationId,
'error',
`Operation failed with error: ${error.message}`,
{ stack: error.stack }
);
operation.status = 'failed';
operation.error = {
code: 'OPERATION_EXECUTION_ERROR',
message: error.message
};
} finally {
operation.endTime = Date.now();
this.emit('statusChanged', {
operationId,
status: operation.status,
result: operation.result,
error: operation.error
});
// Move to completed operations if done or failed
if (operation.status === 'completed' || operation.status === 'failed') {
this._moveToCompleted(operationId);
}
}
}
/**
* Move an operation from active operations to completed operations history.
* @param {string} operationId - The ID of the operation to move.
* @private
*/
_moveToCompleted(operationId) {
const operation = this.operations.get(operationId);
if (!operation) return;
// Store only the necessary data in completed operations
const completedData = {
id: operation.id,
status: operation.status,
startTime: operation.startTime,
endTime: operation.endTime,
result: operation.result,
error: operation.error
};
this.completedOperations.set(operationId, completedData);
this.operations.delete(operationId);
// Trim completed operations if exceeding maximum
if (this.completedOperations.size > this.maxCompletedOperations) {
// Get the oldest operation (sorted by endTime)
const oldest = [...this.completedOperations.entries()].sort(
(a, b) => a[1].endTime - b[1].endTime
)[0];
if (oldest) {
this.completedOperations.delete(oldest[0]);
}
}
}
/**
* Handles progress updates from the running operation and forwards them.
* @param {string} operationId - The ID of the operation reporting progress.
* @param {Object} progress - The progress object { progress, total? }.
*/
_handleProgress(operationId, progress) {
const operation = this.operations.get(operationId);
if (operation && operation.reportProgress) {
try {
// Use the reportProgress function captured from the original context
operation.reportProgress(progress);
this.log(
operationId,
'debug',
`Reported progress: ${JSON.stringify(progress)}`
);
} catch (err) {
this.log(
operationId,
'warn',
`Failed to report progress: ${err.message}`
);
// Don't stop the operation, just log the reporting failure
}
}
}
/**
* Retrieves the status and result/error of an operation.
* @param {string} operationId - The ID of the operation.
* @returns {Object | null} The operation details or null if not found.
*/
getStatus(operationId) {
// First check active operations
const operation = this.operations.get(operationId);
if (operation) {
return {
id: operation.id,
status: operation.status,
startTime: operation.startTime,
endTime: operation.endTime,
result: operation.result,
error: operation.error
};
}
// Then check completed operations
const completedOperation = this.completedOperations.get(operationId);
if (completedOperation) {
return completedOperation;
}
// Operation not found in either active or completed
return {
error: {
code: 'OPERATION_NOT_FOUND',
message: `Operation ID ${operationId} not found. It may have been completed and removed from history, or the ID may be invalid.`
},
status: 'not_found'
};
}
/**
* Internal logging helper to prefix logs with the operation ID.
* @param {string} operationId - The ID of the operation.
* @param {'info'|'warn'|'error'|'debug'} level - Log level.
* @param {string} message - Log message.
* @param {Object} [meta] - Additional metadata.
*/
log(operationId, level, message, meta = {}) {
const operation = this.operations.get(operationId);
// Use the logger instance associated with the operation if available, otherwise console
const logger = operation?.log || console;
const logFn = logger[level] || logger.log || console.log; // Fallback
logFn(`[AsyncOp ${operationId}] ${message}`, meta);
}
// --- Basic Event Emitter ---
on(eventName, listener) {
if (!this.listeners.has(eventName)) {
this.listeners.set(eventName, []);
}
this.listeners.get(eventName).push(listener);
}
emit(eventName, data) {
if (this.listeners.has(eventName)) {
this.listeners.get(eventName).forEach((listener) => listener(data));
}
}
}
// Export a singleton instance
const asyncOperationManager = new AsyncOperationManager();
// Export the manager and potentially the class if needed elsewhere
export { asyncOperationManager, AsyncOperationManager };

View File

@@ -0,0 +1,47 @@
/**
* Temporarily sets environment variables from session.env, executes an action,
* and restores the original environment variables.
* @param {object | undefined} sessionEnv - The environment object from the session.
* @param {Function} actionFn - An async function to execute with the temporary environment.
* @returns {Promise<any>} The result of the actionFn.
*/
export async function withSessionEnv(sessionEnv, actionFn) {
if (
!sessionEnv ||
typeof sessionEnv !== 'object' ||
Object.keys(sessionEnv).length === 0
) {
// If no sessionEnv is provided, just run the action directly
return await actionFn();
}
const originalEnv = {};
const keysToRestore = [];
// Set environment variables from sessionEnv
for (const key in sessionEnv) {
if (Object.prototype.hasOwnProperty.call(sessionEnv, key)) {
// Store original value if it exists, otherwise mark for deletion
if (process.env[key] !== undefined) {
originalEnv[key] = process.env[key];
}
keysToRestore.push(key);
process.env[key] = sessionEnv[key];
}
}
try {
// Execute the provided action function
return await actionFn();
} finally {
// Restore original environment variables
for (const key of keysToRestore) {
if (Object.prototype.hasOwnProperty.call(originalEnv, key)) {
process.env[key] = originalEnv[key];
} else {
// If the key didn't exist originally, delete it
delete process.env[key];
}
}
}
}

View File

@@ -0,0 +1,393 @@
/**
* path-utils.js
* Utility functions for file path operations in Task Master
*
* This module provides robust path resolution for both:
* 1. PACKAGE PATH: Where task-master code is installed
* (global node_modules OR local ./node_modules/task-master OR direct from repo)
* 2. PROJECT PATH: Where user's tasks.json resides (typically user's project root)
*/
import path from 'path';
import fs from 'fs';
import { fileURLToPath } from 'url';
import os from 'os';
// Store last found project root to improve performance on subsequent calls (primarily for CLI)
export let lastFoundProjectRoot = null;
// Project marker files that indicate a potential project root
export const PROJECT_MARKERS = [
// Task Master specific
'tasks.json',
'tasks/tasks.json',
// Common version control
'.git',
'.svn',
// Common package files
'package.json',
'pyproject.toml',
'Gemfile',
'go.mod',
'Cargo.toml',
// Common IDE/editor folders
'.cursor',
'.vscode',
'.idea',
// Common dependency directories (check if directory)
'node_modules',
'venv',
'.venv',
// Common config files
'.env',
'.eslintrc',
'tsconfig.json',
'babel.config.js',
'jest.config.js',
'webpack.config.js',
// Common CI/CD files
'.github/workflows',
'.gitlab-ci.yml',
'.circleci/config.yml'
];
/**
* Gets the path to the task-master package installation directory
* NOTE: This might become unnecessary if CLI fallback in MCP utils is removed.
* @returns {string} - Absolute path to the package installation directory
*/
export function getPackagePath() {
// When running from source, __dirname is the directory containing this file
// When running from npm, we need to find the package root
const thisFilePath = fileURLToPath(import.meta.url);
const thisFileDir = path.dirname(thisFilePath);
// Navigate from core/utils up to the package root
// In dev: /path/to/task-master/mcp-server/src/core/utils -> /path/to/task-master
// In npm: /path/to/node_modules/task-master/mcp-server/src/core/utils -> /path/to/node_modules/task-master
return path.resolve(thisFileDir, '../../../../');
}
/**
* Finds the absolute path to the tasks.json file based on project root and arguments.
* @param {Object} args - Command arguments, potentially including 'projectRoot' and 'file'.
* @param {Object} log - Logger object.
* @returns {string} - Absolute path to the tasks.json file.
* @throws {Error} - If tasks.json cannot be found.
*/
export function findTasksJsonPath(args, log) {
// PRECEDENCE ORDER for finding tasks.json:
// 1. Explicitly provided `projectRoot` in args (Highest priority, expected in MCP context)
// 2. Previously found/cached `lastFoundProjectRoot` (primarily for CLI performance)
// 3. Search upwards from current working directory (`process.cwd()`) - CLI usage
// 1. If project root is explicitly provided (e.g., from MCP session), use it directly
if (args.projectRoot) {
const projectRoot = args.projectRoot;
log.info(`Using explicitly provided project root: ${projectRoot}`);
try {
// This will throw if tasks.json isn't found within this root
return findTasksJsonInDirectory(projectRoot, args.file, log);
} catch (error) {
// Include debug info in error
const debugInfo = {
projectRoot,
currentDir: process.cwd(),
serverDir: path.dirname(process.argv[1]),
possibleProjectRoot: path.resolve(
path.dirname(process.argv[1]),
'../..'
),
lastFoundProjectRoot,
searchedPaths: error.message
};
error.message = `Tasks file not found in any of the expected locations relative to project root "${projectRoot}" (from session).\nDebug Info: ${JSON.stringify(debugInfo, null, 2)}`;
throw error;
}
}
// --- Fallback logic primarily for CLI or when projectRoot isn't passed ---
// 2. If we have a last known project root that worked, try it first
if (lastFoundProjectRoot) {
log.info(`Trying last known project root: ${lastFoundProjectRoot}`);
try {
// Use the cached root
const tasksPath = findTasksJsonInDirectory(
lastFoundProjectRoot,
args.file,
log
);
return tasksPath; // Return if found in cached root
} catch (error) {
log.info(
`Task file not found in last known project root, continuing search.`
);
// Continue with search if not found in cache
}
}
// 3. Start search from current directory (most common CLI scenario)
const startDir = process.cwd();
log.info(
`Searching for tasks.json starting from current directory: ${startDir}`
);
// Try to find tasks.json by walking up the directory tree from cwd
try {
// This will throw if not found in the CWD tree
return findTasksJsonWithParentSearch(startDir, args.file, log);
} catch (error) {
// If all attempts fail, augment and throw the original error from CWD search
error.message = `${error.message}\n\nPossible solutions:\n1. Run the command from your project directory containing tasks.json\n2. Use --project-root=/path/to/project to specify the project location (if using CLI)\n3. Ensure the project root is correctly passed from the client (if using MCP)\n\nCurrent working directory: ${startDir}\nLast known project root: ${lastFoundProjectRoot}\nProject root from args: ${args.projectRoot}`;
throw error;
}
}
/**
* Check if a directory contains any project marker files or directories
* @param {string} dirPath - Directory to check
* @returns {boolean} - True if the directory contains any project markers
*/
function hasProjectMarkers(dirPath) {
return PROJECT_MARKERS.some((marker) => {
const markerPath = path.join(dirPath, marker);
// Check if the marker exists as either a file or directory
return fs.existsSync(markerPath);
});
}
/**
* Search for tasks.json in a specific directory
* @param {string} dirPath - Directory to search in
* @param {string} explicitFilePath - Optional explicit file path relative to dirPath
* @param {Object} log - Logger object
* @returns {string} - Absolute path to tasks.json
* @throws {Error} - If tasks.json cannot be found
*/
function findTasksJsonInDirectory(dirPath, explicitFilePath, log) {
const possiblePaths = [];
// 1. If a file is explicitly provided relative to dirPath
if (explicitFilePath) {
possiblePaths.push(path.resolve(dirPath, explicitFilePath));
}
// 2. Check the standard locations relative to dirPath
possiblePaths.push(
path.join(dirPath, 'tasks.json'),
path.join(dirPath, 'tasks', 'tasks.json')
);
log.info(`Checking potential task file paths: ${possiblePaths.join(', ')}`);
// Find the first existing path
for (const p of possiblePaths) {
log.info(`Checking if exists: ${p}`);
const exists = fs.existsSync(p);
log.info(`Path ${p} exists: ${exists}`);
if (exists) {
log.info(`Found tasks file at: ${p}`);
// Store the project root for future use
lastFoundProjectRoot = dirPath;
return p;
}
}
// If no file was found, throw an error
const error = new Error(
`Tasks file not found in any of the expected locations relative to ${dirPath}: ${possiblePaths.join(', ')}`
);
error.code = 'TASKS_FILE_NOT_FOUND';
throw error;
}
/**
* Recursively search for tasks.json in the given directory and parent directories
* Also looks for project markers to identify potential project roots
* @param {string} startDir - Directory to start searching from
* @param {string} explicitFilePath - Optional explicit file path
* @param {Object} log - Logger object
* @returns {string} - Absolute path to tasks.json
* @throws {Error} - If tasks.json cannot be found in any parent directory
*/
function findTasksJsonWithParentSearch(startDir, explicitFilePath, log) {
let currentDir = startDir;
const rootDir = path.parse(currentDir).root;
// Keep traversing up until we hit the root directory
while (currentDir !== rootDir) {
// First check for tasks.json directly
try {
return findTasksJsonInDirectory(currentDir, explicitFilePath, log);
} catch (error) {
// If tasks.json not found but the directory has project markers,
// log it as a potential project root (helpful for debugging)
if (hasProjectMarkers(currentDir)) {
log.info(`Found project markers in ${currentDir}, but no tasks.json`);
}
// Move up to parent directory
const parentDir = path.dirname(currentDir);
// Check if we've reached the root
if (parentDir === currentDir) {
break;
}
log.info(
`Tasks file not found in ${currentDir}, searching in parent directory: ${parentDir}`
);
currentDir = parentDir;
}
}
// If we've searched all the way to the root and found nothing
const error = new Error(
`Tasks file not found in ${startDir} or any parent directory.`
);
error.code = 'TASKS_FILE_NOT_FOUND';
throw error;
}
// Note: findTasksWithNpmConsideration is not used by findTasksJsonPath and might be legacy or used elsewhere.
// If confirmed unused, it could potentially be removed in a separate cleanup.
function findTasksWithNpmConsideration(startDir, log) {
// First try our recursive parent search from cwd
try {
return findTasksJsonWithParentSearch(startDir, null, log);
} catch (error) {
// If that fails, try looking relative to the executable location
const execPath = process.argv[1];
const execDir = path.dirname(execPath);
log.info(`Looking for tasks file relative to executable at: ${execDir}`);
try {
return findTasksJsonWithParentSearch(execDir, null, log);
} catch (secondError) {
// If that also fails, check standard locations in user's home directory
const homeDir = os.homedir();
log.info(`Looking for tasks file in home directory: ${homeDir}`);
try {
// Check standard locations in home dir
return findTasksJsonInDirectory(
path.join(homeDir, '.task-master'),
null,
log
);
} catch (thirdError) {
// If all approaches fail, throw the original error
throw error;
}
}
}
}
/**
* Finds potential PRD document files based on common naming patterns
* @param {string} projectRoot - The project root directory
* @param {string|null} explicitPath - Optional explicit path provided by the user
* @param {Object} log - Logger object
* @returns {string|null} - The path to the first found PRD file, or null if none found
*/
export function findPRDDocumentPath(projectRoot, explicitPath, log) {
// If explicit path is provided, check if it exists
if (explicitPath) {
const fullPath = path.isAbsolute(explicitPath)
? explicitPath
: path.resolve(projectRoot, explicitPath);
if (fs.existsSync(fullPath)) {
log.info(`Using provided PRD document path: ${fullPath}`);
return fullPath;
} else {
log.warn(
`Provided PRD document path not found: ${fullPath}, will search for alternatives`
);
}
}
// Common locations and file patterns for PRD documents
const commonLocations = [
'', // Project root
'scripts/'
];
const commonFileNames = ['PRD.md', 'prd.md', 'PRD.txt', 'prd.txt'];
// Check all possible combinations
for (const location of commonLocations) {
for (const fileName of commonFileNames) {
const potentialPath = path.join(projectRoot, location, fileName);
if (fs.existsSync(potentialPath)) {
log.info(`Found PRD document at: ${potentialPath}`);
return potentialPath;
}
}
}
log.warn(`No PRD document found in common locations within ${projectRoot}`);
return null;
}
/**
* Resolves the tasks output directory path
* @param {string} projectRoot - The project root directory
* @param {string|null} explicitPath - Optional explicit output path provided by the user
* @param {Object} log - Logger object
* @returns {string} - The resolved tasks directory path
*/
export function resolveTasksOutputPath(projectRoot, explicitPath, log) {
// If explicit path is provided, use it
if (explicitPath) {
const outputPath = path.isAbsolute(explicitPath)
? explicitPath
: path.resolve(projectRoot, explicitPath);
log.info(`Using provided tasks output path: ${outputPath}`);
return outputPath;
}
// Default output path: tasks/tasks.json in the project root
const defaultPath = path.resolve(projectRoot, 'tasks', 'tasks.json');
log.info(`Using default tasks output path: ${defaultPath}`);
// Ensure the directory exists
const outputDir = path.dirname(defaultPath);
if (!fs.existsSync(outputDir)) {
log.info(`Creating tasks directory: ${outputDir}`);
fs.mkdirSync(outputDir, { recursive: true });
}
return defaultPath;
}
/**
* Resolves various file paths needed for MCP operations based on project root
* @param {string} projectRoot - The project root directory
* @param {Object} args - Command arguments that may contain explicit paths
* @param {Object} log - Logger object
* @returns {Object} - An object containing resolved paths
*/
export function resolveProjectPaths(projectRoot, args, log) {
const prdPath = findPRDDocumentPath(projectRoot, args.input, log);
const tasksJsonPath = resolveTasksOutputPath(projectRoot, args.output, log);
// You can add more path resolutions here as needed
return {
projectRoot,
prdPath,
tasksJsonPath
// Add additional path properties as needed
};
}

View File

@@ -1,10 +1,11 @@
import { FastMCP } from "fastmcp";
import path from "path";
import dotenv from "dotenv";
import { fileURLToPath } from "url";
import fs from "fs";
import logger from "./logger.js";
import { registerTaskMasterTools } from "./tools/index.js";
import { FastMCP } from 'fastmcp';
import path from 'path';
import dotenv from 'dotenv';
import { fileURLToPath } from 'url';
import fs from 'fs';
import logger from './logger.js';
import { registerTaskMasterTools } from './tools/index.js';
import { asyncOperationManager } from './core/utils/async-manager.js';
// Load environment variables
dotenv.config();
@@ -19,20 +20,23 @@ const __dirname = path.dirname(__filename);
class TaskMasterMCPServer {
constructor() {
// Get version from package.json using synchronous fs
const packagePath = path.join(__dirname, "../../package.json");
const packageJson = JSON.parse(fs.readFileSync(packagePath, "utf8"));
const packagePath = path.join(__dirname, '../../package.json');
const packageJson = JSON.parse(fs.readFileSync(packagePath, 'utf8'));
this.options = {
name: "Task Master MCP Server",
version: packageJson.version,
name: 'Task Master MCP Server',
version: packageJson.version
};
this.server = new FastMCP(this.options);
this.initialized = false;
// this.server.addResource({});
this.server.addResource({});
// this.server.addResourceTemplate({});
this.server.addResourceTemplate({});
// Make the manager accessible (e.g., pass it to tool registration)
this.asyncManager = asyncOperationManager;
// Bind methods
this.init = this.init.bind(this);
@@ -49,8 +53,8 @@ class TaskMasterMCPServer {
async init() {
if (this.initialized) return;
// Register Task Master tools
registerTaskMasterTools(this.server);
// Pass the manager instance to the tool registration function
registerTaskMasterTools(this.server, this.asyncManager);
this.initialized = true;
@@ -65,9 +69,10 @@ class TaskMasterMCPServer {
await this.init();
}
// Start the FastMCP server
// Start the FastMCP server with increased timeout
await this.server.start({
transportType: "stdio",
transportType: 'stdio',
timeout: 120000 // 2 minutes timeout (in milliseconds)
});
return this;
@@ -83,4 +88,7 @@ class TaskMasterMCPServer {
}
}
// Export the manager from here as well, if needed elsewhere
export { asyncOperationManager };
export default TaskMasterMCPServer;

View File

@@ -1,4 +1,5 @@
import chalk from "chalk";
import chalk from 'chalk';
import { isSilentMode } from '../../scripts/modules/utils.js';
// Define log levels
const LOG_LEVELS = {
@@ -6,12 +7,12 @@ const LOG_LEVELS = {
info: 1,
warn: 2,
error: 3,
success: 4,
success: 4
};
// Get log level from environment or default to info
const LOG_LEVEL = process.env.LOG_LEVEL
? LOG_LEVELS[process.env.LOG_LEVEL.toLowerCase()]
? (LOG_LEVELS[process.env.LOG_LEVEL.toLowerCase()] ?? LOG_LEVELS.info)
: LOG_LEVELS.info;
/**
@@ -20,44 +21,85 @@ const LOG_LEVEL = process.env.LOG_LEVEL
* @param {...any} args - Arguments to log
*/
function log(level, ...args) {
const icons = {
debug: chalk.gray("🔍"),
info: chalk.blue(""),
warn: chalk.yellow("⚠️"),
error: chalk.red("❌"),
success: chalk.green("✅"),
// Skip logging if silent mode is enabled
if (isSilentMode()) {
return;
}
// Use text prefixes instead of emojis
const prefixes = {
debug: chalk.gray('[DEBUG]'),
info: chalk.blue('[INFO]'),
warn: chalk.yellow('[WARN]'),
error: chalk.red('[ERROR]'),
success: chalk.green('[SUCCESS]')
};
if (LOG_LEVELS[level] >= LOG_LEVEL) {
const icon = icons[level] || "";
if (LOG_LEVELS[level] !== undefined && LOG_LEVELS[level] >= LOG_LEVEL) {
const prefix = prefixes[level] || '';
let coloredArgs = args;
if (level === "error") {
console.error(icon, chalk.red(...args));
} else if (level === "warn") {
console.warn(icon, chalk.yellow(...args));
} else if (level === "success") {
console.log(icon, chalk.green(...args));
} else if (level === "info") {
console.log(icon, chalk.blue(...args));
} else {
console.log(icon, ...args);
try {
switch (level) {
case 'error':
coloredArgs = args.map((arg) =>
typeof arg === 'string' ? chalk.red(arg) : arg
);
break;
case 'warn':
coloredArgs = args.map((arg) =>
typeof arg === 'string' ? chalk.yellow(arg) : arg
);
break;
case 'success':
coloredArgs = args.map((arg) =>
typeof arg === 'string' ? chalk.green(arg) : arg
);
break;
case 'info':
coloredArgs = args.map((arg) =>
typeof arg === 'string' ? chalk.blue(arg) : arg
);
break;
case 'debug':
coloredArgs = args.map((arg) =>
typeof arg === 'string' ? chalk.gray(arg) : arg
);
break;
// default: use original args (no color)
}
} catch (colorError) {
// Fallback if chalk fails on an argument
// Use console.error here for internal logger errors, separate from normal logging
console.error('Internal Logger Error applying chalk color:', colorError);
coloredArgs = args;
}
// Revert to console.log - FastMCP's context logger (context.log)
// is responsible for directing logs correctly (e.g., to stderr)
// during tool execution without upsetting the client connection.
// Logs outside of tool execution (like startup) will go to stdout.
console.log(prefix, ...coloredArgs);
}
}
/**
* Create a logger object with methods for different log levels
* Can be used as a drop-in replacement for existing logger initialization
* @returns {Object} Logger object with info, error, debug, warn, and success methods
*/
export function createLogger() {
const createLogMethod =
(level) =>
(...args) =>
log(level, ...args);
return {
debug: (message) => log("debug", message),
info: (message) => log("info", message),
warn: (message) => log("warn", message),
error: (message) => log("error", message),
success: (message) => log("success", message),
log: log, // Also expose the raw log function
debug: createLogMethod('debug'),
info: createLogMethod('info'),
warn: createLogMethod('warn'),
error: createLogMethod('error'),
success: createLogMethod('success'),
log: log // Also expose the raw log function
};
}

View File

@@ -1 +0,0 @@

View File

@@ -0,0 +1,97 @@
/**
* tools/add-dependency.js
* Tool for adding a dependency to a task
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { addDependencyDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the addDependency tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerAddDependencyTool(server) {
server.addTool({
name: 'add_dependency',
description: 'Add a dependency relationship between two tasks',
parameters: z.object({
id: z.string().describe('ID of task that will depend on another task'),
dependsOn: z
.string()
.describe('ID of task that will become a dependency'),
file: z
.string()
.optional()
.describe(
'Absolute path to the tasks file (default: tasks/tasks.json)'
),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(
`Adding dependency for task ${args.id} to depend on ${args.dependsOn}`
);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
// Call the direct function with the resolved path
const result = await addDependencyDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
id: args.id,
dependsOn: args.dependsOn
},
log
// Remove context object
);
// Log result
if (result.success) {
log.info(`Successfully added dependency: ${result.data.message}`);
} else {
log.error(`Failed to add dependency: ${result.error.message}`);
}
// Use handleApiResult to format the response
return handleApiResult(result, log, 'Error adding dependency');
} catch (error) {
log.error(`Error in addDependency tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,118 @@
/**
* tools/add-subtask.js
* Tool for adding subtasks to existing tasks
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { addSubtaskDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the addSubtask tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerAddSubtaskTool(server) {
server.addTool({
name: 'add_subtask',
description: 'Add a subtask to an existing task',
parameters: z.object({
id: z.string().describe('Parent task ID (required)'),
taskId: z
.string()
.optional()
.describe('Existing task ID to convert to subtask'),
title: z
.string()
.optional()
.describe('Title for the new subtask (when creating a new subtask)'),
description: z
.string()
.optional()
.describe('Description for the new subtask'),
details: z
.string()
.optional()
.describe('Implementation details for the new subtask'),
status: z
.string()
.optional()
.describe("Status for the new subtask (default: 'pending')"),
dependencies: z
.string()
.optional()
.describe('Comma-separated list of dependency IDs for the new subtask'),
file: z
.string()
.optional()
.describe(
'Absolute path to the tasks file (default: tasks/tasks.json)'
),
skipGenerate: z
.boolean()
.optional()
.describe('Skip regenerating task files'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Adding subtask with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
const result = await addSubtaskDirect(
{
tasksJsonPath: tasksJsonPath,
id: args.id,
taskId: args.taskId,
title: args.title,
description: args.description,
details: args.details,
status: args.status,
dependencies: args.dependencies,
skipGenerate: args.skipGenerate
},
log
);
if (result.success) {
log.info(`Subtask added successfully: ${result.data.message}`);
} else {
log.error(`Failed to add subtask: ${result.error.message}`);
}
return handleApiResult(result, log, 'Error adding subtask');
} catch (error) {
log.error(`Error in addSubtask tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,120 @@
/**
* tools/add-task.js
* Tool to add a new task using AI
*/
import { z } from 'zod';
import {
createErrorResponse,
createContentResponse,
getProjectRootFromSession,
executeTaskMasterCommand,
handleApiResult
} from './utils.js';
import { addTaskDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the addTask tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerAddTaskTool(server) {
server.addTool({
name: 'add_task',
description: 'Add a new task using AI',
parameters: z.object({
prompt: z
.string()
.optional()
.describe(
'Description of the task to add (required if not using manual fields)'
),
title: z
.string()
.optional()
.describe('Task title (for manual task creation)'),
description: z
.string()
.optional()
.describe('Task description (for manual task creation)'),
details: z
.string()
.optional()
.describe('Implementation details (for manual task creation)'),
testStrategy: z
.string()
.optional()
.describe('Test strategy (for manual task creation)'),
dependencies: z
.string()
.optional()
.describe('Comma-separated list of task IDs this task depends on'),
priority: z
.string()
.optional()
.describe('Task priority (high, medium, low)'),
file: z
.string()
.optional()
.describe('Path to the tasks file (default: tasks/tasks.json)'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.'),
research: z
.boolean()
.optional()
.describe('Whether to use research capabilities for task creation')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Starting add-task with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
// Call the direct function
const result = await addTaskDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
prompt: args.prompt,
dependencies: args.dependencies,
priority: args.priority,
research: args.research
},
log,
{ session }
);
// Return the result
return handleApiResult(result, log);
} catch (error) {
log.error(`Error in add-task tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -1,66 +0,0 @@
/**
* tools/addTask.js
* Tool to add a new task using AI
*/
import { z } from "zod";
import {
executeTaskMasterCommand,
createContentResponse,
createErrorResponse,
} from "./utils.js";
/**
* Register the addTask tool with the MCP server
* @param {FastMCP} server - FastMCP server instance
*/
export function registerAddTaskTool(server) {
server.addTool({
name: "addTask",
description: "Add a new task using AI",
parameters: z.object({
prompt: z.string().describe("Description of the task to add"),
dependencies: z
.string()
.optional()
.describe("Comma-separated list of task IDs this task depends on"),
priority: z
.string()
.optional()
.describe("Task priority (high, medium, low)"),
file: z.string().optional().describe("Path to the tasks file"),
projectRoot: z
.string()
.describe(
"Root directory of the project (default: current working directory)"
),
}),
execute: async (args, { log }) => {
try {
log.info(`Adding new task: ${args.prompt}`);
const cmdArgs = [`--prompt="${args.prompt}"`];
if (args.dependencies)
cmdArgs.push(`--dependencies=${args.dependencies}`);
if (args.priority) cmdArgs.push(`--priority=${args.priority}`);
if (args.file) cmdArgs.push(`--file=${args.file}`);
const result = executeTaskMasterCommand(
"add-task",
log,
cmdArgs,
projectRoot
);
if (!result.success) {
throw new Error(result.error);
}
return createContentResponse(result.stdout);
} catch (error) {
log.error(`Error adding task: ${error.message}`);
return createErrorResponse(`Error adding task: ${error.message}`);
}
},
});
}

View File

@@ -0,0 +1,123 @@
/**
* tools/analyze.js
* Tool for analyzing task complexity and generating recommendations
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { analyzeTaskComplexityDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
import path from 'path';
/**
* Register the analyze tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerAnalyzeTool(server) {
server.addTool({
name: 'analyze_project_complexity',
description:
'Analyze task complexity and generate expansion recommendations',
parameters: z.object({
output: z
.string()
.optional()
.describe(
'Output file path for the report (default: scripts/task-complexity-report.json)'
),
model: z
.string()
.optional()
.describe(
'LLM model to use for analysis (defaults to configured model)'
),
threshold: z.coerce
.number()
.min(1)
.max(10)
.optional()
.describe(
'Minimum complexity score to recommend expansion (1-10) (default: 5)'
),
file: z
.string()
.optional()
.describe(
'Absolute path to the tasks file (default: tasks/tasks.json)'
),
research: z
.boolean()
.optional()
.describe('Use Perplexity AI for research-backed complexity analysis'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(
`Analyzing task complexity with args: ${JSON.stringify(args)}`
);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
const outputPath = args.output
? path.resolve(rootFolder, args.output)
: path.resolve(rootFolder, 'scripts', 'task-complexity-report.json');
const result = await analyzeTaskComplexityDirect(
{
tasksJsonPath: tasksJsonPath,
outputPath: outputPath,
model: args.model,
threshold: args.threshold,
research: args.research
},
log,
{ session }
);
if (result.success) {
log.info(`Task complexity analysis complete: ${result.data.message}`);
log.info(
`Report summary: ${JSON.stringify(result.data.reportSummary)}`
);
} else {
log.error(
`Failed to analyze task complexity: ${result.error.message}`
);
}
return handleApiResult(result, log, 'Error analyzing task complexity');
} catch (error) {
log.error(`Error in analyze tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,98 @@
/**
* tools/clear-subtasks.js
* Tool for clearing subtasks from parent tasks
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { clearSubtasksDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the clearSubtasks tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerClearSubtasksTool(server) {
server.addTool({
name: 'clear_subtasks',
description: 'Clear subtasks from specified tasks',
parameters: z
.object({
id: z
.string()
.optional()
.describe('Task IDs (comma-separated) to clear subtasks from'),
all: z.boolean().optional().describe('Clear subtasks from all tasks'),
file: z
.string()
.optional()
.describe(
'Absolute path to the tasks file (default: tasks/tasks.json)'
),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
})
.refine((data) => data.id || data.all, {
message: "Either 'id' or 'all' parameter must be provided",
path: ['id', 'all']
}),
execute: async (args, { log, session }) => {
try {
log.info(`Clearing subtasks with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
const result = await clearSubtasksDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
id: args.id,
all: args.all
},
log
// Remove context object as clearSubtasksDirect likely doesn't need session/reportProgress
);
if (result.success) {
log.info(`Subtasks cleared successfully: ${result.data.message}`);
} else {
log.error(`Failed to clear subtasks: ${result.error.message}`);
}
return handleApiResult(result, log, 'Error clearing subtasks');
} catch (error) {
log.error(`Error in clearSubtasks tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,89 @@
/**
* tools/complexity-report.js
* Tool for displaying the complexity analysis report
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { complexityReportDirect } from '../core/task-master-core.js';
import path from 'path';
/**
* Register the complexityReport tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerComplexityReportTool(server) {
server.addTool({
name: 'complexity_report',
description: 'Display the complexity analysis report in a readable format',
parameters: z.object({
file: z
.string()
.optional()
.describe(
'Path to the report file (default: scripts/task-complexity-report.json)'
),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(
`Getting complexity report with args: ${JSON.stringify(args)}`
);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to the complexity report file
// Default to scripts/task-complexity-report.json relative to root
const reportPath = args.file
? path.resolve(rootFolder, args.file)
: path.resolve(rootFolder, 'scripts', 'task-complexity-report.json');
const result = await complexityReportDirect(
{
// Pass the explicitly resolved path
reportPath: reportPath
// No other args specific to this tool
},
log
);
if (result.success) {
log.info(
`Successfully retrieved complexity report${result.fromCache ? ' (from cache)' : ''}`
);
} else {
log.error(
`Failed to retrieve complexity report: ${result.error.message}`
);
}
return handleApiResult(
result,
log,
'Error retrieving complexity report'
);
} catch (error) {
log.error(`Error in complexity-report tool: ${error.message}`);
return createErrorResponse(
`Failed to retrieve complexity report: ${error.message}`
);
}
}
});
}

View File

@@ -0,0 +1,112 @@
/**
* tools/expand-all.js
* Tool for expanding all pending tasks with subtasks
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { expandAllTasksDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the expandAll tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerExpandAllTool(server) {
server.addTool({
name: 'expand_all',
description: 'Expand all pending tasks into subtasks',
parameters: z.object({
num: z
.string()
.optional()
.describe('Number of subtasks to generate for each task'),
research: z
.boolean()
.optional()
.describe(
'Enable Perplexity AI for research-backed subtask generation'
),
prompt: z
.string()
.optional()
.describe('Additional context to guide subtask generation'),
force: z
.boolean()
.optional()
.describe(
'Force regeneration of subtasks for tasks that already have them'
),
file: z
.string()
.optional()
.describe(
'Absolute path to the tasks file (default: tasks/tasks.json)'
),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Expanding all tasks with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
const result = await expandAllTasksDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
num: args.num,
research: args.research,
prompt: args.prompt,
force: args.force
},
log,
{ session }
);
if (result.success) {
log.info(`Successfully expanded all tasks: ${result.data.message}`);
} else {
log.error(
`Failed to expand all tasks: ${result.error?.message || 'Unknown error'}`
);
}
return handleApiResult(result, log, 'Error expanding all tasks');
} catch (error) {
log.error(`Error in expand-all tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,98 @@
/**
* tools/expand-task.js
* Tool to expand a task into subtasks
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { expandTaskDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
import fs from 'fs';
import path from 'path';
/**
* Register the expand-task tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerExpandTaskTool(server) {
server.addTool({
name: 'expand_task',
description: 'Expand a task into subtasks for detailed implementation',
parameters: z.object({
id: z.string().describe('ID of task to expand'),
num: z.string().optional().describe('Number of subtasks to generate'),
research: z
.boolean()
.optional()
.describe('Use Perplexity AI for research-backed generation'),
prompt: z
.string()
.optional()
.describe('Additional context for subtask generation'),
file: z.string().optional().describe('Absolute path to the tasks file'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.'),
force: z.boolean().optional().describe('Force the expansion')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Starting expand-task with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
log.info(`Project root resolved to: ${rootFolder}`);
// Resolve the path to tasks.json using the utility
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
// Call direct function with only session in the context, not reportProgress
// Use the pattern recommended in the MCP guidelines
const result = await expandTaskDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
id: args.id,
num: args.num,
research: args.research,
prompt: args.prompt,
force: args.force // Need to add force to parameters
},
log,
{ session }
); // Only pass session, NOT reportProgress
// Return the result
return handleApiResult(result, log, 'Error expanding task');
} catch (error) {
log.error(`Error in expand task tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -1,78 +0,0 @@
/**
* tools/expandTask.js
* Tool to break down a task into detailed subtasks
*/
import { z } from "zod";
import {
executeTaskMasterCommand,
createContentResponse,
createErrorResponse,
} from "./utils.js";
/**
* Register the expandTask tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerExpandTaskTool(server) {
server.addTool({
name: "expandTask",
description: "Break down a task into detailed subtasks",
parameters: z.object({
id: z.string().describe("Task ID to expand"),
num: z.number().optional().describe("Number of subtasks to generate"),
research: z
.boolean()
.optional()
.describe(
"Enable Perplexity AI for research-backed subtask generation"
),
prompt: z
.string()
.optional()
.describe("Additional context to guide subtask generation"),
force: z
.boolean()
.optional()
.describe(
"Force regeneration of subtasks for tasks that already have them"
),
file: z.string().optional().describe("Path to the tasks file"),
projectRoot: z
.string()
.describe(
"Root directory of the project (default: current working directory)"
),
}),
execute: async (args, { log }) => {
try {
log.info(`Expanding task ${args.id}`);
const cmdArgs = [`--id=${args.id}`];
if (args.num) cmdArgs.push(`--num=${args.num}`);
if (args.research) cmdArgs.push("--research");
if (args.prompt) cmdArgs.push(`--prompt="${args.prompt}"`);
if (args.force) cmdArgs.push("--force");
if (args.file) cmdArgs.push(`--file=${args.file}`);
const projectRoot = args.projectRoot;
const result = executeTaskMasterCommand(
"expand",
log,
cmdArgs,
projectRoot
);
if (!result.success) {
throw new Error(result.error);
}
return createContentResponse(result.stdout);
} catch (error) {
log.error(`Error expanding task: ${error.message}`);
return createErrorResponse(`Error expanding task: ${error.message}`);
}
},
});
}

View File

@@ -0,0 +1,76 @@
/**
* tools/fix-dependencies.js
* Tool for automatically fixing invalid task dependencies
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { fixDependenciesDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Register the fixDependencies tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerFixDependenciesTool(server) {
server.addTool({
name: 'fix_dependencies',
description: 'Fix invalid dependencies in tasks automatically',
parameters: z.object({
file: z.string().optional().describe('Absolute path to the tasks file'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Fixing dependencies with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
const result = await fixDependenciesDirect(
{
tasksJsonPath: tasksJsonPath
},
log
);
if (result.success) {
log.info(`Successfully fixed dependencies: ${result.data.message}`);
} else {
log.error(`Failed to fix dependencies: ${result.error.message}`);
}
return handleApiResult(result, log, 'Error fixing dependencies');
} catch (error) {
log.error(`Error in fixDependencies tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,94 @@
/**
* tools/generate.js
* Tool to generate individual task files from tasks.json
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { generateTaskFilesDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
import path from 'path';
/**
* Register the generate tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerGenerateTool(server) {
server.addTool({
name: 'generate',
description:
'Generates individual task files in tasks/ directory based on tasks.json',
parameters: z.object({
file: z.string().optional().describe('Absolute path to the tasks file'),
output: z
.string()
.optional()
.describe('Output directory (default: same directory as tasks file)'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
try {
log.info(`Generating task files with args: ${JSON.stringify(args)}`);
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
// Determine output directory: use explicit arg or default to tasks.json directory
const outputDir = args.output
? path.resolve(rootFolder, args.output) // Resolve relative to root if needed
: path.dirname(tasksJsonPath);
const result = await generateTaskFilesDirect(
{
// Pass the explicitly resolved paths
tasksJsonPath: tasksJsonPath,
outputDir: outputDir
// No other args specific to this tool
},
log
);
if (result.success) {
log.info(`Successfully generated task files: ${result.data.message}`);
} else {
log.error(
`Failed to generate task files: ${result.error?.message || 'Unknown error'}`
);
}
return handleApiResult(result, log, 'Error generating task files');
} catch (error) {
log.error(`Error in generate tool: ${error.message}`);
return createErrorResponse(error.message);
}
}
});
}

View File

@@ -0,0 +1,47 @@
// mcp-server/src/tools/get-operation-status.js
import { z } from 'zod';
import { createErrorResponse, createContentResponse } from './utils.js'; // Assuming these utils exist
/**
* Register the get_operation_status tool.
* @param {FastMCP} server - FastMCP server instance.
* @param {AsyncOperationManager} asyncManager - The async operation manager.
*/
export function registerGetOperationStatusTool(server, asyncManager) {
server.addTool({
name: 'get_operation_status',
description:
'Retrieves the status and result/error of a background operation.',
parameters: z.object({
operationId: z.string().describe('The ID of the operation to check.')
}),
execute: async (args, { log }) => {
try {
const { operationId } = args;
log.info(`Checking status for operation ID: ${operationId}`);
const status = asyncManager.getStatus(operationId);
// Status will now always return an object, but it might have status='not_found'
if (status.status === 'not_found') {
log.warn(`Operation ID not found: ${operationId}`);
return createErrorResponse(
status.error?.message || `Operation ID not found: ${operationId}`,
status.error?.code || 'OPERATION_NOT_FOUND'
);
}
log.info(`Status for ${operationId}: ${status.status}`);
return createContentResponse(status);
} catch (error) {
log.error(`Error in get_operation_status tool: ${error.message}`, {
stack: error.stack
});
return createErrorResponse(
`Failed to get operation status: ${error.message}`,
'GET_STATUS_ERROR'
);
}
}
});
}

View File

@@ -0,0 +1,123 @@
/**
* tools/get-task.js
* Tool to get task details by ID
*/
import { z } from 'zod';
import {
handleApiResult,
createErrorResponse,
getProjectRootFromSession
} from './utils.js';
import { showTaskDirect } from '../core/task-master-core.js';
import { findTasksJsonPath } from '../core/utils/path-utils.js';
/**
* Custom processor function that removes allTasks from the response
* @param {Object} data - The data returned from showTaskDirect
* @returns {Object} - The processed data with allTasks removed
*/
function processTaskResponse(data) {
if (!data) return data;
// If we have the expected structure with task and allTasks
if (data.task) {
// Return only the task object, removing the allTasks array
return data.task;
}
// If structure is unexpected, return as is
return data;
}
/**
* Register the get-task tool with the MCP server
* @param {Object} server - FastMCP server instance
*/
export function registerShowTaskTool(server) {
server.addTool({
name: 'get_task',
description: 'Get detailed information about a specific task',
parameters: z.object({
id: z.string().describe('Task ID to get'),
file: z.string().optional().describe('Absolute path to the tasks file'),
projectRoot: z
.string()
.describe('The directory of the project. Must be an absolute path.')
}),
execute: async (args, { log, session }) => {
// Log the session right at the start of execute
log.info(
`Session object received in execute: ${JSON.stringify(session)}`
); // Use JSON.stringify for better visibility
try {
log.info(`Getting task details for ID: ${args.id}`);
log.info(
`Session object received in execute: ${JSON.stringify(session)}`
); // Use JSON.stringify for better visibility
// Get project root from args or session
const rootFolder =
args.projectRoot || getProjectRootFromSession(session, log);
// Ensure project root was determined
if (!rootFolder) {
return createErrorResponse(
'Could not determine project root. Please provide it explicitly or ensure your session contains valid root information.'
);
}
log.info(`Attempting to use project root: ${rootFolder}`); // Log the final resolved root
log.info(`Root folder: ${rootFolder}`); // Log the final resolved root
// Resolve the path to tasks.json
let tasksJsonPath;
try {
tasksJsonPath = findTasksJsonPath(
{ projectRoot: rootFolder, file: args.file },
log
);
} catch (error) {
log.error(`Error finding tasks.json: ${error.message}`);
return createErrorResponse(
`Failed to find tasks.json: ${error.message}`
);
}
log.info(`Attempting to use tasks file path: ${tasksJsonPath}`);
const result = await showTaskDirect(
{
// Pass the explicitly resolved path
tasksJsonPath: tasksJsonPath,
// Pass other relevant args
id: args.id
},
log
);
if (result.success) {
log.info(
`Successfully retrieved task details for ID: ${args.id}${result.fromCache ? ' (from cache)' : ''}`
);
} else {
log.error(`Failed to get task: ${result.error.message}`);
}
// Use our custom processor function to remove allTasks from the response
return handleApiResult(
result,
log,
'Error retrieving task details',
processTaskResponse
);
} catch (error) {
log.error(`Error in get-task tool: ${error.message}\n${error.stack}`); // Add stack trace
return createErrorResponse(`Failed to get task: ${error.message}`);
}
}
});
}

Some files were not shown because too many files have changed in this diff Show More