feat: add support for code context in more commands#1162
Conversation
- code context for: - add-task - update-subtask - update-task - update
🦋 Changeset detectedLatest commit: 7112a1d The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughAdds isClaudeCode detection to config-manager and propagates it, along with projectRoot, into task-manager modules and prompt schemas for add/update operations. Prompts conditionally include a codebase-analysis preface when using Claude Code. Tests update mocks to include isClaudeCode. Also adds a changeset marking a minor release. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant CLI as CLI Command
participant TM as Task Manager (add/update)
participant CM as Config Manager
participant PM as Prompt Manager
participant AI as AI Provider
CLI->>TM: invoke add/update(..., useResearch, projectRoot)
TM->>CM: isClaudeCode(useResearch, projectRoot)
CM-->>TM: true/false
TM->>PM: build prompt params { ..., isClaudeCode, projectRoot }
PM->>AI: send prompt (conditional codebase analysis block if isClaudeCode)
AI-->>PM: task/update suggestions
PM-->>TM: formatted result
TM-->>CLI: output
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
scripts/modules/task-manager/add-task.js (2)
706-713: Bug: AI usage summary gated onoutputTypethat may be undefined in CLI.CLI path sets
outputFormat='text', butoutputTypecan be unset, suppressing usage summary.Apply this fix to compute and reuse an effective output type:
@@ - const { session, mcpLog, projectRoot, commandName, outputType, tag } = + const { session, mcpLog, projectRoot, commandName, outputType, tag } = context; const isMCP = !!mcpLog; + const effectiveOutputType = outputType || (isMCP ? 'mcp' : 'cli'); @@ - outputType: outputType || (isMCP ? 'mcp' : 'cli') // Use passed outputType or derive + outputType: effectiveOutputType // normalized }); @@ - if ( - aiServiceResponse && - aiServiceResponse.telemetryData && - (outputType === 'cli' || outputType === 'text') - ) { - displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli'); - } + if (aiServiceResponse?.telemetryData && effectiveOutputType === 'cli') { + displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli'); + }
456-468: Consider generateTextService + manual JSON parsing for robustness.Given known reliability issues with
generateObjectServiceacross providers, prefer text generation + explicit parsing/validation (you already have Zod) where feasible.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (9)
.changeset/wet-candies-accept.md(1 hunks)scripts/modules/task-manager/add-task.js(3 hunks)scripts/modules/task-manager/update-subtask-by-id.js(3 hunks)scripts/modules/task-manager/update-task-by-id.js(3 hunks)scripts/modules/task-manager/update-tasks.js(3 hunks)src/prompts/add-task.json(1 hunks)src/prompts/update-subtask.json(1 hunks)src/prompts/update-task.json(1 hunks)src/prompts/update-tasks.json(1 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
.changeset/*.md
📄 CodeRabbit inference engine (.cursor/rules/changeset.mdc)
.changeset/*.md: When runningnpm run changesetornpx changeset add, provide a concise summary of the changes for theCHANGELOG.mdin imperative mood, typically a single line, and not a detailed Git commit message.
The changeset summary should be user-facing, describing what changed in the released version that is relevant to users or consumers of the package.
Do not use your detailed Git commit message body as the changeset summary.
Files:
.changeset/wet-candies-accept.md
.changeset/*
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
Create appropriate changesets for new features, use semantic versioning, include tagged system information in release notes, and document breaking changes if any.
Files:
.changeset/wet-candies-accept.md
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
🧠 Learnings (35)
📓 Common learnings
Learnt from: eyaltoledano
PR: eyaltoledano/claude-task-master#1069
File: .changeset/floppy-news-buy.md:7-38
Timestamp: 2025-08-02T14:54:52.216Z
Learning: For major feature additions like new CLI commands, eyaltoledano prefers detailed changesets with comprehensive descriptions, usage examples, and feature explanations rather than minimal single-line summaries.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Commands such as `analyze-complexity`, `expand-task`, `update-task`, and `add-task` should consider adopting the context gathering pattern for improved AI-powered assistance.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-11T12:30:23.843Z
Learning: Import Task Master's development workflow commands and guidelines; treat the contents of ./.taskmaster/CLAUDE.md as if included in the main CLAUDE.md
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guidelines for integrating new features into the Task Master CLI with tagged system considerations (new_features.mdc).
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: When implementation differs significantly from planned approach, call `node scripts/dev.js update --from=<futureTaskId> --prompt="<explanation>"` to update tasks.json.
Applied to files:
src/prompts/update-tasks.jsonsrc/prompts/update-subtask.jsonscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jssrc/prompts/update-task.json
📚 Learning: 2025-07-18T05:38:17.352Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#943
File: scripts/modules/task-manager/move-task.js:24-24
Timestamp: 2025-07-18T05:38:17.352Z
Learning: In the Claude Task Master system, core task-manager functions are designed with fallback mechanisms for missing projectRoot parameters using the pattern `const projectRoot = providedProjectRoot || findProjectRoot();`. The readJSON and writeJSON functions have default parameters (projectRoot = null, tag = null) and handle missing parameters gracefully. Adding strict validation to these core functions would break the established flexible architecture pattern.
Applied to files:
src/prompts/update-tasks.jsonsrc/prompts/update-subtask.jsonsrc/prompts/update-task.jsonsrc/prompts/add-task.json
📚 Learning: 2025-08-11T12:30:23.843Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-11T12:30:23.843Z
Learning: Import Task Master's development workflow commands and guidelines; treat the contents of ./.taskmaster/CLAUDE.md as if included in the main CLAUDE.md
Applied to files:
src/prompts/update-tasks.json.changeset/wet-candies-accept.mdscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-tasks.jssrc/prompts/update-task.jsonsrc/prompts/add-task.json
📚 Learning: 2025-07-18T17:10:53.657Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-07-18T17:10:53.657Z
Learning: Guidelines for integrating new features into the Task Master CLI with tagged system considerations (new_features.mdc).
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-07-17T21:33:57.585Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1002
File: .changeset/puny-friends-give.md:2-3
Timestamp: 2025-07-17T21:33:57.585Z
Learning: In the eyaltoledano/claude-task-master repository, the MCP server code in mcp-server/src/ is part of the main "task-master-ai" package, not a separate "mcp-server" package. When creating changesets for MCP server changes, use "task-master-ai" as the package name.
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-08-06T21:16:02.300Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1095
File: .github/scripts/check-pre-release-mode.mjs:33-34
Timestamp: 2025-08-06T21:16:02.300Z
Learning: In the claude-task-master project, the .changeset directory is guaranteed to exist as part of the fundamental project structure, so validation checks for its existence are unnecessary.
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-07-18T17:10:12.881Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-07-18T17:10:12.881Z
Learning: For CLI usage, install Taskmaster globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: Use `task-master add-task` to add a new task to tasks.json using AI.
Applied to files:
.changeset/wet-candies-accept.mdscripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:09:13.815Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Commands such as `analyze-complexity`, `expand-task`, `update-task`, and `add-task` should consider adopting the context gathering pattern for improved AI-powered assistance.
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-07-31T21:48:00.389Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#997
File: apps/extension/src/services/task-repository.ts:25-57
Timestamp: 2025-07-31T21:48:00.389Z
Learning: In the eyaltoledano/claude-task-master repository, every task is always part of a tag - there is no concept of untagged tasks. The tag system is mandatory and comprehensive, meaning all tasks exist within a tag context (with 'master' as the default tag if none specified).
Applied to files:
.changeset/wet-candies-accept.md
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
.changeset/wet-candies-accept.mdscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : For AI-powered commands that benefit from project context, use the ContextGatherer utility for multi-source context extraction, support task IDs, file paths, custom context, and project tree, implement fuzzy search for automatic task discovery, and display detailed token breakdown for transparency.
Applied to files:
src/prompts/update-subtask.jsonscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jssrc/prompts/update-task.jsonscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI, create them in the current tag context (defaulting to 'master'), provide clear prompts to guide AI task generation, and validate/clean up AI-generated tasks.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/task-manager/**/*.js : Do not call AI-specific getters (like `getMainModelId`, `getMainMaxTokens`) from core logic functions in `scripts/modules/task-manager/*`; instead, pass the `role` to the unified AI service.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not fetch AI-specific parameters (model ID, max tokens, temp) using `config-manager.js` getters for the AI call. Pass the `role` instead.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Provider modules must import the provider's create<ProviderName> function from ai-sdk/<provider-name>, and import generateText, streamText, generateObject from the core ai package, as well as the log utility from ../../scripts/modules/utils.js.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Be aware of potential reliability issues with `generateObjectService` across different providers and complex schemas. Prefer `generateTextService` + manual parsing as a more robust alternative for structured data needs.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Implement generate<ProviderName>Text, stream<ProviderName>Text, and generate<ProviderName>Object functions in provider modules with basic validation and try/catch error handling.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Determine the appropriate `role` (`main`, `research`, `fallback`) in your core logic and pass it to the service.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Centralize all LLM calls through `generateTextService` or `generateObjectService`.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/commands.js : Be aware of potential reliability issues with `generateObjectService` across different providers and complex schemas. Prefer `generateTextService` + manual parsing as a more robust alternative for structured data needs.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not implement fallback or retry logic outside `ai-services-unified.js`.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/task-manager.js : Features that create, read, update, or delete tasks belong in 'scripts/modules/task-manager.js'.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/*.js : Ensure new features work with existing projects seamlessly, supporting both legacy and tagged task data formats, and support silent migration during feature usage.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to scripts/modules/ai-services-unified.js : Integrate the new provider module with scripts/modules/ai-services-unified.js by importing it and adding an entry to the PROVIDER_FUNCTIONS map.
Applied to files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils/contextGatherer.js : Use `ContextGatherer` in `scripts/modules/utils/contextGatherer.js` for AI-powered commands that need project context, supporting tasks, files, custom text, project tree context, token counting, and multiple output formats.
Applied to files:
scripts/modules/task-manager/update-task-by-id.jsscripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/ai-services-unified.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:54.131Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/telemetry.mdc:0-0
Timestamp: 2025-07-18T17:14:54.131Z
Learning: Applies to scripts/modules/task-manager/**/*.js : If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.
Applied to files:
scripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Implement reusable task finding utilities that support both task and subtask lookups and add context to subtask results.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:09:13.815Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Applies to scripts/modules/utils/contextGatherer.js : Use the `ContextGatherer` class from `scripts/modules/utils/contextGatherer.js` as the centralized utility for extracting context from multiple sources in Task Master commands.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:09:16.839Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:16.839Z
Learning: Applies to scripts/modules/utils/contextGatherer.js : Use the `ContextGatherer` class in `scripts/modules/utils/contextGatherer.js` as the centralized utility for extracting context from multiple sources in Task Master commands.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.js
🧬 Code graph analysis (4)
scripts/modules/task-manager/add-task.js (7)
scripts/modules/task-manager/update-subtask-by-id.js (2)
isClaudeCode(59-65)projectRoot(102-102)scripts/modules/task-manager/update-task-by-id.js (2)
isClaudeCode(286-292)projectRoot(330-330)scripts/modules/task-manager/update-tasks.js (2)
isClaudeCode(307-313)projectRoot(328-328)scripts/modules/task-manager/expand-task.js (3)
isClaudeCode(464-464)currentProvider(461-463)projectRoot(324-324)scripts/modules/task-manager/analyze-task-complexity.js (4)
isClaudeCode(421-421)currentProvider(418-420)useResearch(96-96)projectRoot(97-97)scripts/modules/task-manager/expand-all-tasks.js (1)
projectRoot(47-47)scripts/modules/task-manager/research.js (1)
projectRoot(76-76)
scripts/modules/task-manager/update-task-by-id.js (5)
scripts/modules/task-manager/add-task.js (2)
isClaudeCode(116-121)gatheredContext(408-408)scripts/modules/task-manager/update-subtask-by-id.js (4)
isClaudeCode(59-65)projectRoot(102-102)providedProjectRoot(52-52)gatheredContext(152-152)scripts/modules/task-manager/update-tasks.js (4)
isClaudeCode(307-313)projectRoot(328-328)providedProjectRoot(298-298)gatheredContext(351-351)scripts/modules/task-manager/expand-task.js (4)
isClaudeCode(464-464)projectRoot(324-324)currentProvider(461-463)gatheredContext(365-365)scripts/modules/utils.js (2)
projectRoot(576-578)projectRoot(671-671)
scripts/modules/task-manager/update-tasks.js (5)
scripts/modules/task-manager/add-task.js (1)
isClaudeCode(116-121)scripts/modules/task-manager/update-subtask-by-id.js (3)
isClaudeCode(59-65)projectRoot(102-102)providedProjectRoot(52-52)scripts/modules/task-manager/update-task-by-id.js (3)
isClaudeCode(286-292)projectRoot(330-330)providedProjectRoot(279-279)scripts/modules/task-manager/expand-task.js (3)
isClaudeCode(464-464)projectRoot(324-324)currentProvider(461-463)src/utils/path-utils.js (7)
projectRoot(108-108)projectRoot(197-197)projectRoot(269-269)projectRoot(340-340)projectRoot(386-386)projectRoot(445-445)findProjectRoot(53-86)
scripts/modules/task-manager/update-subtask-by-id.js (3)
scripts/modules/task-manager/add-task.js (2)
isClaudeCode(116-121)gatheredContext(408-408)scripts/modules/task-manager/update-task-by-id.js (4)
isClaudeCode(286-292)projectRoot(330-330)providedProjectRoot(279-279)gatheredContext(374-374)src/utils/path-utils.js (6)
projectRoot(108-108)projectRoot(197-197)projectRoot(269-269)projectRoot(340-340)projectRoot(386-386)findProjectRoot(53-86)
🪛 LanguageTool
.changeset/wet-candies-accept.md
[grammar] ~5-~5: Use correct spacing
Context: ...ic codebase analysis for task operations When using Claude Code as the AI provide...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🪛 markdownlint-cli2 (0.17.2)
.changeset/wet-candies-accept.md
5-5: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🔇 Additional comments (14)
src/prompts/update-subtask.json (1)
48-58: Additions of isClaudeCode/projectRoot params look correctMatches the wiring in task-manager modules and keeps both optional with sane defaults.
scripts/modules/task-manager/update-subtask-by-id.js (2)
23-24: Imports align with provider-aware detection; no AI param getters usedConforms to the service-layer and provider rules.
246-249: Correctly threads provider context into promptsPassing gatheredContext, isClaudeCode(), and projectRoot matches the updated prompt schema.
scripts/modules/task-manager/update-tasks.js (2)
22-23: Provider imports look goodKeeps logic within config-manager and constants as required.
451-453: Prompt params updated correctlyprojectContext, isClaudeCode(), and projectRoot passed as expected for the updated prompt.
src/prompts/update-task.json (1)
47-58: Additions of isClaudeCode/projectRoot params look correctMatches new wiring in task-manager; optional with defaults.
scripts/modules/task-manager/update-task-by-id.js (2)
26-27: Provider/constant imports are correctStays within config-manager and central constants per guidelines.
468-471: Threads isClaudeCode and projectRoot into prompts correctlyMatches the updated prompt schema; no issues.
src/prompts/update-tasks.json (2)
31-41: LGTM: added isClaudeCode/projectRoot parameters are backward-compatible.Optional fields with sensible defaults keep prior flows stable.
47-47: Good conditional codebase-analysis preface.Clear steps for Glob/Grep/Read and scoping via Project Root look solid.
src/prompts/add-task.json (1)
49-60: LGTM: prompt parameters extended for provider context.Optional flags and defaults are appropriate.
scripts/modules/task-manager/add-task.js (2)
28-30: LGTM: provider detection imports adhere to service-layer rules.Using getMainProvider/getResearchProvider and CUSTOM_PROVIDERS avoids model/param getters and direct client init.
291-302: I've added scripts to:
- Locate
getCurrentTagdefinitions and invocations.- Confirm whether
add-task.jsimportstaskMaster.Proceeding with these checks.
.changeset/wet-candies-accept.md (1)
1-8: Condense changeset summary and remove unverified claim
Apply:---- -"task-master-ai": minor ---- - -Enhanced Claude Code and Google CLI integration with automatic codebase analysis for task operations - -When using Claude Code as the AI provider, task management commands now automatically analyze your codebase before generating or updating tasks. This provides more accurate, context-aware implementation details that align with your project's existing architecture and patterns. +--- +"task-master-ai": minor +--- + +Add provider-aware codebase analysis when Claude Code is active across add/update commands.
| dependencies: numericDependencies, | ||
| isClaudeCode: isClaudeCode(), | ||
| projectRoot: projectRoot | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pass-through looks correct; ensure prompt actually uses dependencies.
You now pass dependencies, isClaudeCode(), and projectRoot to the prompt. After updating the template to surface dependencies, this will materially improve outputs.
🏁 Script executed:
#!/bin/bash
# Verify the add-task prompt now references {{dependencies}}
rg -nP '\{\{\s*dependencies\s*\}\}' src/prompts/add-task.json -C2Length of output: 67
🏁 Script executed:
#!/bin/bash
# Locate add-task.json anywhere in the repository
fd --hidden --follow --exclude .git --type f add-task.jsonLength of output: 86
Add {{dependencies}} placeholder to add-task prompt template
The template at src/prompts/add-task.json doesn’t reference the passed dependencies; insert {{dependencies}} (and likewise {{projectRoot}}/{{isClaudeCode}}) where appropriate so the prompt actually uses these values.
🤖 Prompt for AI Agents
In scripts/modules/task-manager/add-task.js around lines 439 to 442, the code
passes dependencies, projectRoot and isClaudeCode into the add-task prompt but
the template at src/prompts/add-task.json doesn't reference them; open
src/prompts/add-task.json and insert the {{dependencies}} placeholder where the
task's dependency list should be injected, add {{projectRoot}} where the project
root/path context should be included, and add {{isClaudeCode}} (or a
boolean-driven branch) where the template needs to know if Claude code mode is
active so the prompt consumes those values; ensure placeholder names exactly
match the keys passed from add-task.js so the template renderer injects the
values.
| /** | ||
| * Check if Claude Code is being used | ||
| */ | ||
| const isClaudeCode = () => { | ||
| const projectRoot = providedProjectRoot || findProjectRoot(); | ||
| const currentProvider = useResearch | ||
| ? getResearchProvider(projectRoot) | ||
| : getMainProvider(projectRoot); | ||
| return currentProvider === CUSTOM_PROVIDERS.CLAUDE_CODE; | ||
| }; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Duplicate provider detection helper across modules
The same isClaudeCode() appears in multiple task-manager files. Consider centralizing into a small utility (e.g., utils/providerUtils.js: isClaudeCodeActive(useResearch, projectRoot)) to avoid drift.
🤖 Prompt for AI Agents
In scripts/modules/task-manager/update-subtask-by-id.js around lines 56-66 you
have a local isClaudeCode() helper duplicated across modules; extract this logic
to a new utility (e.g., scripts/modules/task-manager/utils/providerUtils.js or
shared utils/providerUtils.js) as an exported function
isClaudeCodeActive(useResearch, providedProjectRoot) that encapsulates
providedProjectRoot || findProjectRoot(), selects the correct provider via
getResearchProvider/getMainProvider, and compares to
CUSTOM_PROVIDERS.CLAUDE_CODE; then replace the local helper with an import and
call to the new utility (update other modules using the duplicate helper
similarly), keep the same return semantics and imports (findProjectRoot,
getResearchProvider, getMainProvider, CUSTOM_PROVIDERS), and run tests/lint to
ensure no import paths break.
| /** | ||
| * Check if Claude Code is being used | ||
| */ | ||
| const isClaudeCode = () => { | ||
| const projectRoot = providedProjectRoot || findProjectRoot(); | ||
| const currentProvider = useResearch | ||
| ? getResearchProvider(projectRoot) | ||
| : getMainProvider(projectRoot); | ||
| return currentProvider === CUSTOM_PROVIDERS.CLAUDE_CODE; | ||
| }; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Avoid repeating isClaudeCode logic in each module
Extract to a shared util to keep provider checks consistent and testable across commands.
🤖 Prompt for AI Agents
In scripts/modules/task-manager/update-task-by-id.js around lines 283 to 293,
the inline isClaudeCode() provider-check logic should be extracted to a shared
utility; create a new util (e.g., src/utils/providerChecks.js) that exports
isClaudeCode(projectRoot?, useResearch?) which contains the current logic using
providedProjectRoot/findProjectRoot and getResearchProvider/getMainProvider and
CUSTOM_PROVIDERS, update this file to import and call the shared isClaudeCode
util (passing providedProjectRoot and useResearch), and replace any other
modules that duplicate this logic to import the same util so provider checks are
consistent and unit-testable. Ensure to add/update tests for the new util and
update imports/exports accordingly.
| /** | ||
| * Check if Claude Code is being used | ||
| */ | ||
| const isClaudeCode = () => { | ||
| const projectRoot = providedProjectRoot || findProjectRoot(); | ||
| const currentProvider = useResearch | ||
| ? getResearchProvider(projectRoot) | ||
| : getMainProvider(projectRoot); | ||
| return currentProvider === CUSTOM_PROVIDERS.CLAUDE_CODE; | ||
| }; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Centralize isClaudeCode helper to reduce duplication
Same detection pattern exists in add-task, update-task-by-id, update-subtask-by-id. Extract to shared util and import here.
🤖 Prompt for AI Agents
In scripts/modules/task-manager/update-tasks.js around lines 304 to 314, the
isClaudeCode helper is duplicated across multiple modules (add-task,
update-task-by-id, update-subtask-by-id); extract this detection logic into a
shared utility (e.g., scripts/utils/provider.js or similar), export a single
isClaudeCode(projectRoot?, useResearch?, providedProjectRoot?) function that
encapsulates findProjectRoot, getResearchProvider/getMainProvider, and
CUSTOM_PROVIDERS.CLAUDE_CODE comparison, then replace the local helper with an
import of that shared function and update callers to pass necessary params or
let the util derive projectRoot when omitted.
| "default": { | ||
| "system": "You are a helpful assistant that creates well-structured tasks for a software development project. Generate a single new task based on the user's description, adhering strictly to the provided JSON schema. Pay special attention to dependencies between tasks, ensuring the new task correctly references any tasks it depends on.\n\nWhen determining dependencies for a new task, follow these principles:\n1. Select dependencies based on logical requirements - what must be completed before this task can begin.\n2. Prioritize task dependencies that are semantically related to the functionality being built.\n3. Consider both direct dependencies (immediately prerequisite) and indirect dependencies.\n4. Avoid adding unnecessary dependencies - only include tasks that are genuinely prerequisite.\n5. Consider the current status of tasks - prefer completed tasks as dependencies when possible.\n6. Pay special attention to foundation tasks (1-5) but don't automatically include them without reason.\n7. Recent tasks (higher ID numbers) may be more relevant for newer functionality.\n\nThe dependencies array should contain task IDs (numbers) of prerequisite tasks.{{#if useResearch}}\n\nResearch current best practices and technologies relevant to this task.{{/if}}", | ||
| "user": "You are generating the details for Task #{{newTaskId}}. Based on the user's request: \"{{prompt}}\", create a comprehensive new task for a software development project.\n \n {{gatheredContext}}\n \n {{#if useResearch}}Research current best practices, technologies, and implementation patterns relevant to this task. {{/if}}Based on the information about existing tasks provided above, include appropriate dependencies in the \"dependencies\" array. Only include task IDs that this new task directly depends on.\n \n Return your answer as a single JSON object matching the schema precisely:\n \n {\n \"title\": \"Task title goes here\",\n \"description\": \"A concise one or two sentence description of what the task involves\",\n \"details\": \"Detailed implementation steps, considerations, code examples, or technical approach\",\n \"testStrategy\": \"Specific steps to verify correct implementation and functionality\",\n \"dependencies\": [1, 3] // Example: IDs of tasks that must be completed before this task\n }\n \n Make sure the details and test strategy are comprehensive and specific{{#if useResearch}}, incorporating current best practices from your research{{/if}}. DO NOT include the task ID in the title.\n {{#if contextFromArgs}}{{contextFromArgs}}{{/if}}" | ||
| "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\n\nYou have access to powerful codebase analysis tools. Before generating the task:\n\n1. Use the Glob tool to explore the project structure (e.g., \"**/*.js\", \"**/*.json\", \"**/README.md\")\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\n3. Use the Read tool to examine key files like package.json, main entry points, and relevant source files\n4. Analyze the current implementation to understand what already exists\n\nBased on your analysis:\n- Identify existing components/features that relate to this new task\n- Understand the technology stack, frameworks, and patterns in use\n- Generate implementation details that align with the project's current architecture\n- Reference specific files, functions, or patterns from the codebase in your details\n\nProject Root: {{projectRoot}}\n\n{{/if}}You are generating the details for Task #{{newTaskId}}. Based on the user's request: \"{{prompt}}\", create a comprehensive new task for a software development project.\n \n {{gatheredContext}}\n \n {{#if useResearch}}Research current best practices, technologies, and implementation patterns relevant to this task. {{/if}}Based on the information about existing tasks provided above, include appropriate dependencies in the \"dependencies\" array. Only include task IDs that this new task directly depends on.\n \n Return your answer as a single JSON object matching the schema precisely:\n \n {\n \"title\": \"Task title goes here\",\n \"description\": \"A concise one or two sentence description of what the task involves\",\n \"details\": \"Detailed implementation steps, considerations, code examples, or technical approach\",\n \"testStrategy\": \"Specific steps to verify correct implementation and functionality\",\n \"dependencies\": [1, 3] // Example: IDs of tasks that must be completed before this task\n }\n \n Make sure the details and test strategy are comprehensive and specific{{#if useResearch}}, incorporating current best practices from your research{{/if}}. DO NOT include the task ID in the title.\n {{#if contextFromArgs}}{{contextFromArgs}}{{/if}}" |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Surface user-provided dependencies to the model.
You pass dependencies into the prompt params but the template never shows them; the model can miss required prerequisites. Insert a short, non-JSON preface line to enumerate them before the JSON instructions.
Apply this diff within the "user" template (additions shown):
-{{/if}}You are generating the details for Task #{{newTaskId}}. Based on the user's request: "{{prompt}}", create a comprehensive new task for a software development project.
+{{/if}}You are generating the details for Task #{{newTaskId}}. Based on the user's request: "{{prompt}}", create a comprehensive new task for a software development project.
+
+{{#if dependencies}}
+Pre-selected dependency candidates (IDs): {{dependencies}}
+- Include these only if they are truly prerequisite; otherwise omit, but reflect the rationale in "testStrategy".
+{{/if}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\n\nYou have access to powerful codebase analysis tools. Before generating the task:\n\n1. Use the Glob tool to explore the project structure (e.g., \"**/*.js\", \"**/*.json\", \"**/README.md\")\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\n3. Use the Read tool to examine key files like package.json, main entry points, and relevant source files\n4. Analyze the current implementation to understand what already exists\n\nBased on your analysis:\n- Identify existing components/features that relate to this new task\n- Understand the technology stack, frameworks, and patterns in use\n- Generate implementation details that align with the project's current architecture\n- Reference specific files, functions, or patterns from the codebase in your details\n\nProject Root: {{projectRoot}}\n\n{{/if}}You are generating the details for Task #{{newTaskId}}. Based on the user's request: \"{{prompt}}\", create a comprehensive new task for a software development project.\n \n {{gatheredContext}}\n \n {{#if useResearch}}Research current best practices, technologies, and implementation patterns relevant to this task. {{/if}}Based on the information about existing tasks provided above, include appropriate dependencies in the \"dependencies\" array. Only include task IDs that this new task directly depends on.\n \n Return your answer as a single JSON object matching the schema precisely:\n \n {\n \"title\": \"Task title goes here\",\n \"description\": \"A concise one or two sentence description of what the task involves\",\n \"details\": \"Detailed implementation steps, considerations, code examples, or technical approach\",\n \"testStrategy\": \"Specific steps to verify correct implementation and functionality\",\n \"dependencies\": [1, 3] // Example: IDs of tasks that must be completed before this task\n }\n \n Make sure the details and test strategy are comprehensive and specific{{#if useResearch}}, incorporating current best practices from your research{{/if}}. DO NOT include the task ID in the title.\n {{#if contextFromArgs}}{{contextFromArgs}}{{/if}}" | |
| "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\n\nYou have access to powerful codebase analysis tools. Before generating the task:\n\n1. Use the Glob tool to explore the project structure (e.g., \"**/*.js\", \"**/*.json\", \"**/README.md\")\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\n3. Use the Read tool to examine key files like package.json, main entry points, and relevant source files\n4. Analyze the current implementation to understand what already exists\n\nBased on your analysis:\n- Identify existing components/features that relate to this new task\n- Understand the technology stack, frameworks, and patterns in use\n- Generate implementation details that align with the project's current architecture\n- Reference specific files, functions, or patterns from the codebase in your details\n\nProject Root: {{projectRoot}}\n\n{{/if}}You are generating the details for Task #{{newTaskId}}. Based on the user's request: \"{{prompt}}\", create a comprehensive new task for a software development project.\n \n {{#if dependencies}}\n Pre-selected dependency candidates (IDs): {{dependencies}}\n - Include these only if they are truly prerequisite; otherwise omit, but reflect the rationale in \"testStrategy\".\n {{/if}}\n \n {{gatheredContext}}\n \n {{#if useResearch}}Research current best practices, technologies, and implementation patterns relevant to this task. {{/if}}Based on the information about existing tasks provided above, include appropriate dependencies in the \"dependencies\" array. Only include task IDs that this new task directly depends on.\n \n Return your answer as a single JSON object matching the schema precisely:\n \n {\n \"title\": \"Task title goes here\",\n \"description\": \"A concise one or two sentence description of what the task involves\",\n \"details\": \"Detailed implementation steps, considerations, code examples, or technical approach\",\n \"testStrategy\": \"Specific steps to verify correct implementation and functionality\",\n \"dependencies\": [1, 3] // Example: IDs of tasks that must be completed before this task\n }\n \n Make sure the details and test strategy are comprehensive and specific{{#if useResearch}}, incorporating current best practices from your research{{/if}}. DO NOT include the task ID in the title.\n {{#if contextFromArgs}}{{contextFromArgs}}{{/if}}" |
🤖 Prompt for AI Agents
In src/prompts/add-task.json around line 65, the template never surfaces the
passed-in dependencies so the model may miss prerequisites; insert a short
non-JSON preface line right before the "Return your answer as a single JSON
object..." section that enumerates the dependencies (for example: a single line
like "Dependencies: {{#if dependencies}}{{dependencies}}{{else}}None{{/if}}"
followed by a blank line) so it appears to the model but is not part of the JSON
payload; ensure formatting stays plain text and does not break existing
handlebars or the subsequent JSON block.
There was a problem hiding this comment.
Actionable comments posted: 8
♻️ Duplicate comments (8)
scripts/modules/task-manager/update-subtask-by-id.js (1)
23-26: Good: provider detection centralized via config-managerSwitching to
isClaudeCodefrom config-manager removes prior duplication across modules. Nice cleanup.scripts/modules/task-manager/update-task-by-id.js (1)
26-30: Good: reuse sharedisClaudeCodehelperConsistent with the centralization guideline; avoids per-file provider checks.
scripts/modules/task-manager/update-tasks.js (1)
22-25: Good: importisClaudeCodefrom config-managerConsistent with other modules and guideline to centralize provider logic.
src/prompts/update-subtask.json (1)
64-64: Invalid JSON: unescaped newlines/quotes in "user" string will break parsingEscape internal quotes and newlines so the file remains valid JSON.
Apply this diff:
- "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\n\nYou have access to powerful codebase analysis tools. Before generating the subtask update:\n\n1. Use the Glob tool to explore the project structure (e.g., \"**/*.js\", \"**/*.json\", \"**/README.md\")\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\n3. Use the Read tool to examine relevant files and understand current implementation\n4. Analyze the current codebase to inform your subtask update\n\nBased on your analysis:\n- Include specific file references, code patterns, or implementation details\n- Ensure suggestions align with the project's current architecture\n- Reference existing components or patterns when relevant\n- Make implementation notes specific to the codebase structure\n\nProject Root: {{projectRoot}}\n\n{{/if}}Task Context:\n\nParent Task: {{{json parentTask}}}\n{{#if prevSubtask}}Previous Subtask: {{{json prevSubtask}}}\n{{/if}}{{#if nextSubtask}}Next Subtask: {{{json nextSubtask}}}\n{{/if}}Current Subtask Details (for context only):\n{{currentDetails}}\n\nUser Request: \"{{updatePrompt}}\"\n\n{{#if useResearch}}Research and incorporate current best practices, latest stable versions, and proven approaches into your update. {{/if}}Based on the User Request and all the Task Context (including current subtask details provided above), what is the new information or text that should be appended to this subtask's details? Return ONLY this new text as a plain string.{{#if useResearch}} Include specific technical recommendations based on current industry standards.{{/if}}\n{{#if gatheredContext}}\n\n# Additional Project Context\n\n{{gatheredContext}}\n{{/if}}" + "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\\n\\nYou have access to powerful codebase analysis tools. Before generating the subtask update:\\n\\n1. Use the Glob tool to explore the project structure (e.g., \\\"**/*.js\\\", \\\"**/*.json\\\", \\\"**/README.md\\\")\\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\\n3. Use the Read tool to examine relevant files and understand current implementation\\n4. Analyze the current codebase to inform your subtask update\\n\\nBased on your analysis:\\n- Include specific file references, code patterns, or implementation details\\n- Ensure suggestions align with the project's current architecture\\n- Reference existing components or patterns when relevant\\n- Make implementation notes specific to the codebase structure\\n\\nProject Root: {{projectRoot}}\\n\\n{{/if}}Task Context:\\n\\nParent Task: {{{json parentTask}}}\\n{{#if prevSubtask}}Previous Subtask: {{{json prevSubtask}}}\\n{{/if}}{{#if nextSubtask}}Next Subtask: {{{json nextSubtask}}}\\n{{/if}}Current Subtask Details (for context only):\\n{{currentDetails}}\\n\\nUser Request: \\\"{{updatePrompt}}\\\"\\n\\n{{#if useResearch}}Research and incorporate current best practices, latest stable versions, and proven approaches into your update. {{/if}}Based on the User Request and all the Task Context (including current subtask details provided above), what is the new information or text that should be appended to this subtask's details? Return ONLY this new text as a plain string.{{#if useResearch}} Include specific technical recommendations based on current industry standards.{{/if}}\\n\\n{{#if gatheredContext}}\\n\\n# Additional Project Context\\n\\n{{gatheredContext}}\\n{{/if}}"#!/bin/bash # Validate JSON after the fix jq -e . src/prompts/update-subtask.json >/dev/null && echo "update-subtask.json is valid"src/prompts/update-task.json (2)
63-63: Fix invalid JSON: unescaped newlines/quotes in "user" (default prompt).The multi-line value breaks JSON parsing. Keep it as a single escaped string.
Apply:
- "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required - -You have access to powerful codebase analysis tools. Before updating the task: - -1. Use the Glob tool to explore the project structure (e.g., "**/*.js", "**/*.json", "**/README.md") -2. Use the Grep tool to search for existing implementations, patterns, and technologies -3. Use the Read tool to examine relevant files and understand current implementation -4. Analyze how the task changes relate to the existing codebase - -Based on your analysis: -- Update task details to reference specific files, functions, or patterns from the codebase -- Ensure implementation details align with the project's current architecture -- Include specific code examples or file references where appropriate -- Consider how changes impact existing components - -Project Root: {{projectRoot}} - -{{/if}}Here is the task to update{{#if useResearch}} with research-backed information{{/if}}: -{{{taskJson}}} - -Please {{#if useResearch}}research and {{/if}}update this task based on the following {{#if useResearch}}context: -{{updatePrompt}} - -Incorporate current best practices, latest stable versions, and proven approaches.{{/if}}{{#if (not useResearch)}}new context: -{{updatePrompt}}{{/if}} - -IMPORTANT: {{#if useResearch}}Preserve any subtasks marked as "done" or "completed".{{/if}}{{#if (not useResearch)}}In the task JSON above, any subtasks with "status": "done" or "status": "completed" should be preserved exactly as is. Build your changes around these completed items.{{/if}} -{{#if gatheredContext}} - -# Project Context - -{{gatheredContext}} -{{/if}} - -Return only the updated task as a valid JSON object{{#if useResearch}} with research-backed improvements{{/if}}." + "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\\n\\nYou have access to powerful codebase analysis tools. Before updating the task:\\n\\n1. Use the Glob tool to explore the project structure (e.g., \\\"**/*.js\\\", \\\"**/*.json\\\", \\\"**/README.md\\\")\\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\\n3. Use the Read tool to examine relevant files and understand current implementation\\n4. Analyze how the task changes relate to the existing codebase\\n\\nBased on your analysis:\\n- Update task details to reference specific files, functions, or patterns from the codebase\\n- Ensure implementation details align with the project's current architecture\\n- Include specific code examples or file references where appropriate\\n- Consider how changes impact existing components\\n\\nProject Root: {{projectRoot}}\\n\\n{{/if}}Here is the task to update{{#if useResearch}} with research-backed information{{/if}}:\\n{{{taskJson}}}\\n\\nPlease {{#if useResearch}}research and {{/if}}update this task based on the following {{#if useResearch}}context:\\n{{updatePrompt}}\\n\\nIncorporate current best practices, latest stable versions, and proven approaches.{{/if}}{{#if (not useResearch)}}new context:\\n{{updatePrompt}}{{/if}}\\n\\nIMPORTANT: {{#if useResearch}}Preserve any subtasks marked as \\\"done\\\" or \\\"completed\\\".{{/if}}{{#if (not useResearch)}}In the task JSON above, any subtasks with \\\"status\\\": \\\"done\\\" or \\\"status\\\": \\\"completed\\\" should be preserved exactly as is. Build your changes around these completed items.{{/if}}\\n{{#if gatheredContext}}\\n\\n# Project Context\\n\\n{{gatheredContext}}\\n{{/if}}\\n\\nReturn only the updated task as a valid JSON object{{#if useResearch}} with research-backed improvements{{/if}}."#!/bin/bash jq -e . src/prompts/update-task.json >/dev/null && echo "update-task.json is valid"
68-68: Fix invalid JSON: unescaped newlines/quotes in "user" (append prompt).Same issue; escape and consolidate.
Apply:
- "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required - -You have access to powerful codebase analysis tools. Before generating the task update: - -1. Use the Glob tool to explore the project structure (e.g., "**/*.js", "**/*.json", "**/README.md") -2. Use the Grep tool to search for existing implementations, patterns, and technologies -3. Use the Read tool to examine relevant files and understand current implementation -4. Analyze the current codebase to inform your update - -Based on your analysis: -- Include specific file references, code patterns, or implementation details -- Ensure suggestions align with the project's current architecture -- Reference existing components or patterns when relevant - -Project Root: {{projectRoot}} - -{{/if}}Task Context: - -Task: {{{json task}}} -Current Task Details (for context only): -{{currentDetails}} - -User Request: "{{updatePrompt}}" - -Based on the User Request and all the Task Context (including current task details provided above), what is the new information or text that should be appended to this task's details? Return ONLY this new text as a plain string. -{{#if gatheredContext}} - -# Additional Project Context - -{{gatheredContext}} -{{/if}}" + "user": "{{#if isClaudeCode}}## IMPORTANT: Codebase Analysis Required\\n\\nYou have access to powerful codebase analysis tools. Before generating the task update:\\n\\n1. Use the Glob tool to explore the project structure (e.g., \\\"**/*.js\\\", \\\"**/*.json\\\", \\\"**/README.md\\\")\\n2. Use the Grep tool to search for existing implementations, patterns, and technologies\\n3. Use the Read tool to examine relevant files and understand current implementation\\n4. Analyze the current codebase to inform your update\\n\\nBased on your analysis:\\n- Include specific file references, code patterns, or implementation details\\n- Ensure suggestions align with the project's current architecture\\n- Reference existing components or patterns when relevant\\n\\nProject Root: {{projectRoot}}\\n\\n{{/if}}Task Context:\\n\\nTask: {{{json task}}}\\nCurrent Task Details (for context only):\\n{{currentDetails}}\\n\\nUser Request: \\\"{{updatePrompt}}\\\"\\n\\nBased on the User Request and all the Task Context (including current task details provided above), what is the new information or text that should be appended to this task's details? Return ONLY this new text as a plain string.\\n{{#if gatheredContext}}\\n\\n# Additional Project Context\\n\\n{{gatheredContext}}\\n{{/if}}"#!/bin/bash jq -e . src/prompts/update-task.json >/dev/null && echo "update-task.json is valid"scripts/modules/task-manager/add-task.js (2)
28-31: Good: centralized provider detection via config-manager.Importing
isClaudeCodehere removes duplicated logic across modules.
432-435: Pass-through ofdependencies,isClaudeCode, andprojectRootto prompt is correct; ensure template consumes them.Avoid dead params—verify
src/prompts/add-task.jsonuses these placeholders.#!/bin/bash rg -nP '\{\{\s*dependencies\s*\}\}|\{\{\s*projectRoot\s*\}\}|\{\{\s*isClaudeCode\s*\}\}' src/prompts/add-task.json -C2 || true
| Enhanced Claude Code and Google CLI integration with automatic codebase analysis for task operations | ||
|
|
||
| When using Claude Code as the AI provider, task management commands now automatically analyze your codebase before generating or updating tasks. This provides more accurate, context-aware implementation details that align with your project's existing architecture and patterns. | ||
|
|
||
| Commands contextualised: | ||
|
|
||
| - add-task | ||
| - update-subtask | ||
| - update-task | ||
| - update |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Use a single-line, user-facing changeset summary (imperative mood)
Current body is long and mentions "Google CLI" (unverified). Compress to one line per project guidelines.
Apply this diff:
-Enhanced Claude Code and Google CLI integration with automatic codebase analysis for task operations
-
-When using Claude Code as the AI provider, task management commands now automatically analyze your codebase before generating or updating tasks. This provides more accurate, context-aware implementation details that align with your project's existing architecture and patterns.
-
-Commands contextualised:
-
-- add-task
-- update-subtask
-- update-task
-- update
+Enable automatic codebase analysis for add-task, update-subtask, update-task, and update when using Claude Code.🏁 Script executed:
#!/bin/bash
# Optional: verify whether "Google CLI" is actually introduced in this PR
rg -n "Google CLI" -S || trueLength of output: 30
🏁 Script executed:
#!/bin/bash
# List all files in .changeset
ls -R .changeset
# Show first 30 lines of the changeset file
sed -n '1,30p' .changeset/wet-candies-accept.md
# Verify presence of key strings
rg -n "Claude Code"
rg -n "Google CLI"Length of output: 24849
Use an imperative single-line changeset summary and remove the erroneous “Google CLI” reference
Replace the current multi-line description with a concise one-line summary. For example:
--- a/.changeset/wet-candies-accept.md
+++ b/.changeset/wet-candies-accept.md
@@
-Enhanced Claude Code and Google CLI integration with automatic codebase analysis for task operations
+Enable automatic codebase analysis for add-task, update-subtask, update-task, and update when using Claude Code.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Enhanced Claude Code and Google CLI integration with automatic codebase analysis for task operations | |
| When using Claude Code as the AI provider, task management commands now automatically analyze your codebase before generating or updating tasks. This provides more accurate, context-aware implementation details that align with your project's existing architecture and patterns. | |
| Commands contextualised: | |
| - add-task | |
| - update-subtask | |
| - update-task | |
| - update | |
| Enable automatic codebase analysis for add-task, update-subtask, update-task, and update when using Claude Code. | |
| When using Claude Code as the AI provider, task management commands now automatically analyze your codebase before generating or updating tasks. This provides more accurate, context-aware implementation details that align with your project's existing architecture and patterns. | |
| Commands contextualised: | |
| - add-task | |
| - update-subtask | |
| - update-task | |
| - update |
🧰 Tools
🪛 LanguageTool
[grammar] ~5-~5: Use correct spacing
Context: ...ic codebase analysis for task operations When using Claude Code as the AI provide...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~7-~7: Use correct spacing
Context: ...ct's existing architecture and patterns. Commands contextualised: - add-task - u...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~9-~9: Consider adjusting word choice based on regional variation
Context: ...ng architecture and patterns. Commands contextualised: - add-task - update-subtask - update-task ...
(QB_NEW_EN_OTHER_ERROR_IDS_26)
🪛 markdownlint-cli2 (0.17.2)
5-5: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🤖 Prompt for AI Agents
.changeset/wet-candies-accept.md lines 5-14: the changeset body is multi-line
and includes an incorrect "Google CLI" reference; replace the multi-line
description with a single-line, imperative summary (e.g., "Enhance Claude Code
integration to perform automatic codebase analysis for task operations") and
remove any mention of "Google CLI", ensuring the file contains only a one-line
imperative summary describing the change.
| "models": { | ||
| "main": { | ||
| "provider": "claude-code", | ||
| "modelId": "sonnet", | ||
| "maxTokens": 64000, | ||
| "temperature": 0.2 | ||
| }, | ||
| "research": { | ||
| "provider": "perplexity", | ||
| "modelId": "sonar", | ||
| "maxTokens": 8700, | ||
| "temperature": 0.1 | ||
| }, | ||
| "fallback": { | ||
| "provider": "anthropic", | ||
| "modelId": "claude-3-5-sonnet-20241022", | ||
| "maxTokens": 8192, | ||
| "temperature": 0.2 | ||
| } | ||
| }, | ||
| "global": { | ||
| "logLevel": "info", | ||
| "debug": false, | ||
| "defaultNumTasks": 10, | ||
| "defaultSubtasks": 5, | ||
| "defaultPriority": "medium", | ||
| "projectName": "Taskmaster", | ||
| "ollamaBaseURL": "http://localhost:11434/api", | ||
| "bedrockBaseURL": "https://bedrock.us-east-1.amazonaws.com", | ||
| "responseLanguage": "English", | ||
| "userId": "1234567890", | ||
| "azureBaseURL": "https://your-endpoint.azure.com/", | ||
| "defaultTag": "master" | ||
| }, | ||
| "claudeCode": {} | ||
| } No newline at end of file |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Do not commit .taskmaster/config.json; configure via CLI/MCP instead. Revert this file from the PR.
Per repo guidelines, config changes (provider, modelId, tokens, etc.) must not be made via direct edits. Use the Task Master CLI or Models MCP and keep user-local config out of VCS.
Run to revert and apply locally:
🏁 Script executed:
# Revert file from PR
git restore --staged .taskmaster/config.json
git checkout -- .taskmaster/config.json
# Apply intended settings locally via CLI (examples)
task-master models set main.provider claude-code
task-master models set main.modelId sonnet
task-master models set main.maxTokens 64000
task-master models set research.provider perplexity
task-master models set research.modelId sonar-pro # if that's the intended model
task-master models set fallback.provider anthropic
task-master models set fallback.modelId claude-3.5-sonnet-20240620Length of output: 1175
🏁 Script executed:
#!/bin/bash
# Search for CLI command references in the repository
rg -n 'task-master models' -g '*' || true
rg -n 'taskmaster models' -g '*' || true
# Inspect package.json for configured CLI binary names
rg -n '"bin"' -g 'package.json' | sed -n '1,10p' || true
# Search for usage of "models set" to find example invocations
rg -n 'models set' -g '*' || trueLength of output: 30021
Revert .taskmaster/config.json edits; manage models via CLI/MCP instead
Manual edits to .taskmaster/config.json violate repo guidelines—use task-master models (or the models MCP tool) to set providers, model IDs, tokens, etc.
🤖 Prompt for AI Agents
In .taskmaster/config.json around lines 2 to 37, the file was manually edited to
add/modify model entries which violates repo guidelines; revert these manual
changes (restore the previous committed version or remove the added/modified
"models" section) and do not commit model/provider changes directly to this
config file; instead manage models via the official tooling by running the
documented CLI command (task-master models ...) or using the models MCP tool to
set provider, modelId, maxTokens, and temperature so configuration changes are
applied and tracked correctly.
| }, | ||
| { | ||
| "id": 105, | ||
| "title": "Implement Code Context Analysis for Task Generation", | ||
| "description": "Create a module that analyzes the project codebase to provide relevant context when generating new tasks, enhancing task quality with code-aware suggestions.", | ||
| "status": "pending", | ||
| "dependencies": [ | ||
| 17, | ||
| 19, | ||
| 94 | ||
| ], | ||
| "priority": "medium", | ||
| "details": "This task involves implementing a CodeContextAnalyzer module that follows the same architectural patterns as the existing ConfigManager at `scripts/modules/config-manager.js`. After analyzing the ConfigManager, here's how it works and what patterns should be adopted:\n\n## How ConfigManager Works (scripts/modules/config-manager.js)\n\nThe ConfigManager is a sophisticated configuration management system with these key components:\n\n**1. Configuration Loading & Caching:**\n- Uses a global cache (`loadedConfig`, `loadedConfigRoot`) to avoid repeated file reads\n- Implements `_loadAndValidateConfig()` for the core loading logic with intelligent root detection\n- Falls back gracefully through: explicit root → findProjectRoot() → process.cwd()\n- Supports both new (.taskmaster/config.json) and legacy (taskmaster.config.json) locations\n\n**2. Validation & Error Handling:**\n- Uses Zod schemas for structured validation (especially for Claude Code settings)\n- Implements custom ConfigurationError class for specific error types\n- Validates providers against MODEL_MAP loaded from supported-models.json\n- Graceful degradation: warns about issues but continues with defaults\n\n**3. API Design Patterns:**\n- Role-specific getters: `getMainProvider()`, `getResearchProvider()`, `getFallbackProvider()`\n- Parameter-specific getters: `getMainMaxTokens()`, `getResearchTemperature()`\n- Generic getters with role parameter: `getModelConfigForRole(role, explicitRoot)`\n- Deep merging of defaults with loaded config using spread operators\n\n**4. Environment Integration:**\n- Resolves environment variables via `resolveEnvVariable()` utility\n- Supports multiple environment contexts (process.env, session.env, .env files)\n- API key validation across multiple providers with placeholder detection\n\n**5. Performance Optimizations:**\n- Lazy loading of configuration files only when project markers exist\n- Caching with invalidation based on explicitRoot changes\n- Model-specific parameter overrides from MODEL_MAP for efficiency\n\n## CodeContextAnalyzer Implementation Plan\n\nFollowing these ConfigManager patterns, implement:\n\n**1. Core Module Structure (`src/utils/CodeContextAnalyzer.js`):**\n```javascript\n// Similar imports and structure as ConfigManager\nimport fs from 'fs';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\nimport { z } from 'zod';\n\n// Global cache variables (like ConfigManager)\nlet loadedContext = null;\nlet loadedContextRoot = null;\n\n// Main context loading function (mirrors _loadAndValidateConfig pattern)\nfunction _loadAndAnalyzeContext(explicitRoot = null) {\n // Follow ConfigManager's root resolution logic\n // Implement caching similar to ConfigManager\n}\n\n// Public API following ConfigManager getter patterns\nexport function getCodeContext(explicitRoot = null, forceReload = false) {\n // Mirror getConfig() caching logic\n}\n```\n\n**2. Context Analysis Capabilities:**\n- File structure scanning with configurable ignore patterns (like node_modules)\n- Package.json dependency analysis using ConfigManager's JSON parsing patterns \n- AST parsing with lazy loading of heavy parsing libraries\n- Function/class/module identification with validation schemas\n- Caching mechanism following ConfigManager's cache invalidation patterns\n\n**3. Integration Points:**\n- Add `--context` flag to task creation commands (similar to ConfigManager's role-specific flags)\n- Context relevance scoring algorithm with configurable thresholds\n- Integration with existing task generation workflow using ConfigManager's merge patterns\n\n**4. Configuration & Validation:**\n- Use Zod schemas for context analyzer settings validation (like validateClaudeCodeSettings)\n- Support configuration options for analysis depth, ignore patterns, cache settings\n- Follow ConfigManager's graceful degradation patterns for malformed code files\n\n**5. Performance Considerations:**\n- Implement file change detection and selective re-analysis\n- Use ConfigManager's lazy loading patterns for expensive operations\n- Cache analysis results with TTL similar to ConfigManager's cache strategy", |
There was a problem hiding this comment.
Do not manually edit tasks.json; regenerate via Taskmaster CLI.
Per repo guidelines, .taskmaster/tasks/tasks.json is generated. This manual insertion of task 105 (and the timestamp change) should be reverted and re-created using Taskmaster commands (e.g., task-master add-task …) to avoid drift and migration issues.
Apply this diff to revert the manual block (then re-add via CLI):
- {
- "id": 105,
- "title": "Implement Code Context Analysis for Task Generation",
- "description": "Create a module that analyzes the project codebase to provide relevant context when generating new tasks, enhancing task quality with code-aware suggestions.",
- "status": "pending",
- "dependencies": [
- 17,
- 19,
- 94
- ],
- "priority": "medium",
- "details": "This task involves implementing a CodeContextAnalyzer module that follows the same architectural patterns as the existing ConfigManager at `scripts/modules/config-manager.js`. After analyzing the ConfigManager, here's how it works and what patterns should be adopted:\n\n## How ConfigManager Works (scripts/modules/config-manager.js)\n\nThe ConfigManager is a sophisticated configuration management system with these key components:\n\n**1. Configuration Loading & Caching:**\n- Uses a global cache (`loadedConfig`, `loadedConfigRoot`) to avoid repeated file reads\n- Implements `_loadAndValidateConfig()` for the core loading logic with intelligent root detection\n- Falls back gracefully through: explicit root → findProjectRoot() → process.cwd()\n- Supports both new (.taskmaster/config.json) and legacy (taskmaster.config.json) locations\n\n**2. Validation & Error Handling:**\n- Uses Zod schemas for structured validation (especially for Claude Code settings)\n- Implements custom ConfigurationError class for specific error types\n- Validates providers against MODEL_MAP loaded from supported-models.json\n- Graceful degradation: warns about issues but continues with defaults\n\n**3. API Design Patterns:**\n- Role-specific getters: `getMainProvider()`, `getResearchProvider()`, `getFallbackProvider()`\n- Parameter-specific getters: `getMainMaxTokens()`, `getResearchTemperature()`\n- Generic getters with role parameter: `getModelConfigForRole(role, explicitRoot)`\n- Deep merging of defaults with loaded config using spread operators\n\n**4. Environment Integration:**\n- Resolves environment variables via `resolveEnvVariable()` utility\n- Supports multiple environment contexts (process.env, session.env, .env files)\n- API key validation across multiple providers with placeholder detection\n\n**5. Performance Optimizations:**\n- Lazy loading of configuration files only when project markers exist\n- Caching with invalidation based on explicitRoot changes\n- Model-specific parameter overrides from MODEL_MAP for efficiency\n\n## CodeContextAnalyzer Implementation Plan\n\nFollowing these ConfigManager patterns, implement:\n\n**1. Core Module Structure (`src/utils/CodeContextAnalyzer.js`):**\n```javascript\n// Similar imports and structure as ConfigManager\nimport fs from 'fs';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\nimport { z } from 'zod';\n\n// Global cache variables (like ConfigManager)\nlet loadedContext = null;\nlet loadedContextRoot = null;\n\n// Main context loading function (mirrors _loadAndValidateConfig pattern)\nfunction _loadAndAnalyzeContext(explicitRoot = null) {\n // Follow ConfigManager's root resolution logic\n // Implement caching similar to ConfigManager\n}\n\n// Public API following ConfigManager getter patterns\nexport function getCodeContext(explicitRoot = null, forceReload = false) {\n // Mirror getConfig() caching logic\n}\n```\n\n**2. Context Analysis Capabilities:**\n- File structure scanning with configurable ignore patterns (like node_modules)\n- Package.json dependency analysis using ConfigManager's JSON parsing patterns \n- AST parsing with lazy loading of heavy parsing libraries\n- Function/class/module identification with validation schemas\n- Caching mechanism following ConfigManager's cache invalidation patterns\n\n**3. Integration Points:**\n- Add `--context` flag to task creation commands (similar to ConfigManager's role-specific flags)\n- Context relevance scoring algorithm with configurable thresholds\n- Integration with existing task generation workflow using ConfigManager's merge patterns\n\n**4. Configuration & Validation:**\n- Use Zod schemas for context analyzer settings validation (like validateClaudeCodeSettings)\n- Support configuration options for analysis depth, ignore patterns, cache settings\n- Follow ConfigManager's graceful degradation patterns for malformed code files\n\n**5. Performance Considerations:**\n- Implement file change detection and selective re-analysis\n- Use ConfigManager's lazy loading patterns for expensive operations\n- Cache analysis results with TTL similar to ConfigManager's cache strategy",
- "testStrategy": "Testing should verify both the analysis capabilities and integration with task generation, following ConfigManager's testing patterns:\n\n1. **Unit Tests (mirror ConfigManager validation tests):**\n - Test context loading with various project structures (like ConfigManager's root detection tests)\n - Verify caching mechanism matches ConfigManager's cache behavior\n - Test file scanning with mock directory structures\n - Verify AST parsing with sample code files using validation patterns from ConfigManager\n - Test context relevance scoring algorithm with known inputs\n - Test graceful degradation following ConfigManager's error handling patterns\n\n2. **Integration Tests (following ConfigManager's integration patterns):**\n - Test end-to-end context-aware task creation workflow\n - Verify context merging follows ConfigManager's deep merge patterns\n - Test with various project structures and configurations\n - Performance testing with larger codebases using ConfigManager's optimization strategies\n\n3. **Validation Tests (using ConfigManager's validation approach):**\n - Test Zod schema validation for context analyzer configuration\n - Test error handling for malformed or unusual code structures\n - Verify API key-style checks for required analysis dependencies\n - Test configuration migration paths similar to ConfigManager's legacy support\n\n4. **Edge Case Testing (following ConfigManager's robustness patterns):**\n - Test behavior with empty files or directories (like ConfigManager's empty config handling)\n - Test graceful degradation when analysis fails (mirror ConfigManager's fallback behavior)\n - Test performance with very large files using ConfigManager's optimization techniques\n - Verify cache invalidation works correctly across different project roots",
- "subtasks": [
- {
- "id": 1,
- "title": "Study ConfigManager Architecture and Patterns",
- "description": "Analyze the ConfigManager module at scripts/modules/config-manager.js to understand its caching, validation, error handling, and API design patterns that should be replicated in the CodeContextAnalyzer.",
- "status": "pending",
- "dependencies": [],
- "details": "Deep dive into ConfigManager's architecture at scripts/modules/config-manager.js to understand:\n\n**Caching Strategy:**\n- Global cache variables: `loadedConfig`, `loadedConfigRoot` (lines 81-82)\n- Cache invalidation logic in `getConfig()` function (lines 250-272)\n- When to reload vs use cached values based on explicitRoot changes\n\n**Configuration Loading Patterns:**\n- `_loadAndValidateConfig()` core loading function (lines 92-241)\n- Root path resolution logic: explicitRoot → findProjectRoot() → process.cwd() (lines 99-111)\n- Deep merging of defaults with loaded config (lines 138-153)\n- Support for both new and legacy config locations (lines 129-132)\n\n**Validation & Error Handling:**\n- Custom ConfigurationError class (lines 85-90)\n- Provider validation using MODEL_MAP (lines 281-294)\n- Zod schema validation for complex settings (lines 321-373)\n- Graceful degradation with warnings vs hard failures\n\n**API Design Patterns:**\n- Role-specific getters: getMainProvider(), getResearchProvider() (lines 408-441)\n- Generic role-based getter: getModelConfigForRole() (lines 395-406)\n- Parameter-specific getters with fallbacks (lines 412-475)\n- Consistent explicitRoot parameter handling across all functions\n\nDocument these patterns with specific line references and code examples.",
- "testStrategy": "Create comprehensive documentation of ConfigManager patterns with code snippets and line references. Have the documentation reviewed for accuracy and completeness by team members familiar with the ConfigManager implementation."
- },
- {
- "id": 2,
- "title": "Create CodeContextAnalyzer Module Skeleton",
- "description": "Create the basic module structure for CodeContextAnalyzer following ConfigManager's patterns including imports, cache variables, error classes, and core function signatures.",
- "status": "pending",
- "dependencies": [
- 1
- ],
- "details": "Create `src/utils/CodeContextAnalyzer.js` with structure matching ConfigManager:\n\n**Module Setup (following lines 1-42 of ConfigManager):**\n- Import statements: fs, path, fileURLToPath, chalk, z (Zod)\n- Constants for analysis configuration (similar to DEFAULTS on lines 43-78)\n- Global cache variables: `loadedContext`, `loadedContextRoot` (mirroring lines 81-82)\n- Load analysis configuration from JSON file (similar to MODEL_MAP loading lines 25-41)\n\n**Error Handling (following lines 85-90):**\n- Custom ContextAnalysisError class\n- Error types for different analysis failures\n\n**Core Function Signatures (matching ConfigManager patterns):**\n- `_loadAndAnalyzeContext(explicitRoot = null)` - core analysis function\n- `getCodeContext(explicitRoot = null, forceReload = false)` - public API\n- Validation functions following validateProvider pattern (lines 281-294)\n- Getter functions following role-specific pattern (lines 408-441)\n\n**Configuration Defaults:**\n- Analysis depth settings\n- File type patterns to analyze\n- Ignore patterns (node_modules, .git, etc.)\n- Cache settings and TTL values\n- Performance thresholds\n\nEnsure all function signatures match ConfigManager's parameter patterns and naming conventions.",
- "testStrategy": "Test module imports correctly, cache variables initialize properly, error classes work as expected, and all core functions can be called without errors. Verify the module structure matches ConfigManager's organization."
- },
- {
- "id": 3,
- "title": "Implement Context Caching System",
- "description": "Implement the caching mechanism for code context analysis following ConfigManager's caching patterns, including cache invalidation, root-based caching, and performance optimizations.",
- "status": "pending",
- "dependencies": [
- 2
- ],
- "details": "Implement caching system based on ConfigManager's patterns:\n\n**Cache Management (following lines 250-272 of ConfigManager):**\n- Implement cache invalidation logic similar to `getConfig()`\n- Root-based cache tracking following `loadedConfigRoot` pattern\n- Force reload mechanism matching ConfigManager's forceReload parameter\n\n**Context Loading (following _loadAndValidateConfig pattern lines 92-241):**\n- File system scanning with project marker detection (similar to lines 119-127)\n- Root path resolution using same logic as ConfigManager (lines 99-111)\n- Analysis result merging and validation\n- Error handling with warnings vs failures\n\n**Performance Optimizations:**\n- File modification time tracking for selective re-analysis\n- Lazy loading of expensive analysis operations\n- Configurable analysis depth to control performance\n- Memory-efficient storage of analysis results\n\n**Cache Invalidation Triggers:**\n- File system changes in analyzed directories\n- Configuration changes to analysis settings\n- Project root changes\n- Manual force reload requests\n\nImplement cache persistence to disk for large projects following ConfigManager's file I/O patterns.",
- "testStrategy": "Test cache invalidation works correctly when files change, project root changes, or force reload is requested. Verify cache performance with large codebases and ensure cache persistence survives application restarts. Test memory usage remains reasonable with large projects."
- },
- {
- "id": 4,
- "title": "Implement File System Analysis with ConfigManager Patterns",
- "description": "Implement file system scanning and analysis capabilities using ConfigManager's robust file handling, error management, and validation patterns.",
- "status": "pending",
- "dependencies": [
- 3
- ],
- "details": "Implement file system analysis following ConfigManager's file handling patterns:\n\n**File Discovery (following ConfigManager's config file discovery lines 113-127):**\n- Project structure scanning with ignore pattern support\n- File type detection and filtering\n- Recursive directory traversal with depth limits\n- Support for .gitignore-style ignore patterns\n\n**File Analysis (using ConfigManager's JSON parsing approach lines 133-154):**\n- AST parsing for JavaScript/TypeScript files\n- Package.json dependency extraction (similar to ConfigManager's JSON parsing)\n- Configuration file analysis (following ConfigManager's config parsing patterns)\n- Function/class/module identification\n\n**Error Handling (following ConfigManager's error patterns lines 198-207):**\n- Graceful handling of malformed files\n- Warnings for analysis failures without stopping the process\n- Fallback behavior when parsing fails\n- Detailed error reporting with file paths and line numbers\n\n**Validation (using ConfigManager's validation approach lines 167-197):**\n- File content validation before analysis\n- Analysis result validation using Zod schemas\n- Provider-style validation for analysis plugins\n- Configuration validation for analysis settings\n\n**Integration with ConfigManager utilities:**\n- Use findProjectRoot() for consistent project detection\n- Leverage resolveEnvVariable() for configuration overrides\n- Follow ConfigManager's path resolution patterns\n- Use ConfigManager's logging patterns for consistency",
- "testStrategy": "Test file system scanning with various project structures and ignore patterns. Verify AST parsing handles malformed code gracefully. Test error handling matches ConfigManager's robustness. Verify analysis results are validated correctly and integration with ConfigManager utilities works seamlessly."
- }
- ]
- },Also revert the metadata.updated change; Taskmaster should manage it.
🤖 Prompt for AI Agents
In .taskmaster/tasks/tasks.json around lines 6576-6588, a manual insertion of
task 105 and a metadata.updated timestamp change was detected; revert that
manual block and timestamp change and recreate the task using the Taskmaster CLI
instead. Remove the manually added JSON snippet for task 105 and restore the
file to the repository version (or regenerate via Taskmaster CLI restore/rebuild
command); then run the Taskmaster command to add the task (e.g., task-master
add-task ... with the intended fields) so Taskmaster updates metadata.updated
and manages IDs/migrations; do not hand-edit tasks.json in future.
| "dependencies": [ | ||
| 17, | ||
| 19, | ||
| 94 | ||
| ], |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Validate dependency IDs 17, 19, 94 exist in the same tag.
Broken deps will block planners and status rollups.
Run:
Expected: depPresence is all true.
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show whether tasks 17,19,94 exist under the same tag block as task 105
jq -r '
to_entries[]
| {tag:.key, tasks:(.value.tasks // [])}
| . as $t
| ($t.tasks[] | select(.id==105)) as $cur
| {
tag:$t.tag,
deps:$cur.dependencies,
depPresence: ($cur.dependencies | map(
any($t.tasks[]; .id==.)
))
}
' .taskmaster/tasks/tasks.jsonLength of output: 438
Ensure dependencies 17, 19, and 94 are defined under the “master” tag for task 105
All three IDs are currently missing (depPresence=false), which will block planners and status rollups.
. taskmaster/tasks/tasks.json (around lines 6582–6586)
🤖 Prompt for AI Agents
In .taskmaster/tasks/tasks.json around lines 6582–6586, task id 105 is missing
dependencies 17, 19, and 94 under its "master" tag; update the task 105 "master"
dependencies array to include entries for dependency IDs 17, 19, and 94 (each
with the same dependency object shape used by other entries, e.g., id,
type/status fields) so they are present and marked as active/present per schema
(depPresence true or equivalent), ensuring commas/JSON syntax remain valid.
| "details": "This task involves implementing a CodeContextAnalyzer module that follows the same architectural patterns as the existing ConfigManager at `scripts/modules/config-manager.js`. After analyzing the ConfigManager, here's how it works and what patterns should be adopted:\n\n## How ConfigManager Works (scripts/modules/config-manager.js)\n\nThe ConfigManager is a sophisticated configuration management system with these key components:\n\n**1. Configuration Loading & Caching:**\n- Uses a global cache (`loadedConfig`, `loadedConfigRoot`) to avoid repeated file reads\n- Implements `_loadAndValidateConfig()` for the core loading logic with intelligent root detection\n- Falls back gracefully through: explicit root → findProjectRoot() → process.cwd()\n- Supports both new (.taskmaster/config.json) and legacy (taskmaster.config.json) locations\n\n**2. Validation & Error Handling:**\n- Uses Zod schemas for structured validation (especially for Claude Code settings)\n- Implements custom ConfigurationError class for specific error types\n- Validates providers against MODEL_MAP loaded from supported-models.json\n- Graceful degradation: warns about issues but continues with defaults\n\n**3. API Design Patterns:**\n- Role-specific getters: `getMainProvider()`, `getResearchProvider()`, `getFallbackProvider()`\n- Parameter-specific getters: `getMainMaxTokens()`, `getResearchTemperature()`\n- Generic getters with role parameter: `getModelConfigForRole(role, explicitRoot)`\n- Deep merging of defaults with loaded config using spread operators\n\n**4. Environment Integration:**\n- Resolves environment variables via `resolveEnvVariable()` utility\n- Supports multiple environment contexts (process.env, session.env, .env files)\n- API key validation across multiple providers with placeholder detection\n\n**5. Performance Optimizations:**\n- Lazy loading of configuration files only when project markers exist\n- Caching with invalidation based on explicitRoot changes\n- Model-specific parameter overrides from MODEL_MAP for efficiency\n\n## CodeContextAnalyzer Implementation Plan\n\nFollowing these ConfigManager patterns, implement:\n\n**1. Core Module Structure (`src/utils/CodeContextAnalyzer.js`):**\n```javascript\n// Similar imports and structure as ConfigManager\nimport fs from 'fs';\nimport path from 'path';\nimport { fileURLToPath } from 'url';\nimport { z } from 'zod';\n\n// Global cache variables (like ConfigManager)\nlet loadedContext = null;\nlet loadedContextRoot = null;\n\n// Main context loading function (mirrors _loadAndValidateConfig pattern)\nfunction _loadAndAnalyzeContext(explicitRoot = null) {\n // Follow ConfigManager's root resolution logic\n // Implement caching similar to ConfigManager\n}\n\n// Public API following ConfigManager getter patterns\nexport function getCodeContext(explicitRoot = null, forceReload = false) {\n // Mirror getConfig() caching logic\n}\n```\n\n**2. Context Analysis Capabilities:**\n- File structure scanning with configurable ignore patterns (like node_modules)\n- Package.json dependency analysis using ConfigManager's JSON parsing patterns \n- AST parsing with lazy loading of heavy parsing libraries\n- Function/class/module identification with validation schemas\n- Caching mechanism following ConfigManager's cache invalidation patterns\n\n**3. Integration Points:**\n- Add `--context` flag to task creation commands (similar to ConfigManager's role-specific flags)\n- Context relevance scoring algorithm with configurable thresholds\n- Integration with existing task generation workflow using ConfigManager's merge patterns\n\n**4. Configuration & Validation:**\n- Use Zod schemas for context analyzer settings validation (like validateClaudeCodeSettings)\n- Support configuration options for analysis depth, ignore patterns, cache settings\n- Follow ConfigManager's graceful degradation patterns for malformed code files\n\n**5. Performance Considerations:**\n- Implement file change detection and selective re-analysis\n- Use ConfigManager's lazy loading patterns for expensive operations\n- Cache analysis results with TTL similar to ConfigManager's cache strategy", | ||
| "testStrategy": "Testing should verify both the analysis capabilities and integration with task generation, following ConfigManager's testing patterns:\n\n1. **Unit Tests (mirror ConfigManager validation tests):**\n - Test context loading with various project structures (like ConfigManager's root detection tests)\n - Verify caching mechanism matches ConfigManager's cache behavior\n - Test file scanning with mock directory structures\n - Verify AST parsing with sample code files using validation patterns from ConfigManager\n - Test context relevance scoring algorithm with known inputs\n - Test graceful degradation following ConfigManager's error handling patterns\n\n2. **Integration Tests (following ConfigManager's integration patterns):**\n - Test end-to-end context-aware task creation workflow\n - Verify context merging follows ConfigManager's deep merge patterns\n - Test with various project structures and configurations\n - Performance testing with larger codebases using ConfigManager's optimization strategies\n\n3. **Validation Tests (using ConfigManager's validation approach):**\n - Test Zod schema validation for context analyzer configuration\n - Test error handling for malformed or unusual code structures\n - Verify API key-style checks for required analysis dependencies\n - Test configuration migration paths similar to ConfigManager's legacy support\n\n4. **Edge Case Testing (following ConfigManager's robustness patterns):**\n - Test behavior with empty files or directories (like ConfigManager's empty config handling)\n - Test graceful degradation when analysis fails (mirror ConfigManager's fallback behavior)\n - Test performance with very large files using ConfigManager's optimization techniques\n - Verify cache invalidation works correctly across different project roots", | ||
| "subtasks": [ |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Avoid brittle line-number references inside task details.
Embedding exact line numbers from scripts/modules/config-manager.js will rot. Prefer referencing stable symbols (function names) or link to docs.
🤖 Prompt for AI Agents
In .taskmaster/tasks/tasks.json around lines 6588-6590, the task details
currently embed brittle exact line-number references into
scripts/modules/config-manager.js; update the task text to remove numeric line
references and instead reference stable symbols (e.g., function or constant
names) and the file path, or add a link to the relevant documentation/README;
ensure the description names the function(s) users should inspect (or points to
the docs) and optionally include a short code-path hint (file path + function)
so the task won't break when lines shift.
| "metadata": { | ||
| "created": "2025-06-13T23:52:56.848Z", | ||
| "updated": "2025-08-02T14:13:14.826Z", | ||
| "updated": "2025-08-28T15:00:06.183Z", |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Timestamp should be system-managed.
metadata.updated should be touched by Taskmaster, not manual edits. Revert and let the CLI regenerate.
🤖 Prompt for AI Agents
In .taskmaster/tasks/tasks.json around line 6638, the review notes that
metadata.updated was manually edited but should be system-managed; revert your
manual change to metadata.updated back to the prior value (or remove the manual
timestamp mutation) and ensure you do not hardcode timestamps in the JSON—leave
metadata.updated for Taskmaster/CLI to regenerate at runtime or via the CLI
tooling, then re-run the CLI or its task-save command to produce the correct
system-managed timestamp.
| /** | ||
| * Check if Claude Code is being used as the provider | ||
| * @param {boolean} useResearch - Whether to check research provider or main provider | ||
| * @param {string|null} projectRoot - Project root path (optional) | ||
| * @returns {boolean} True if Claude Code is the current provider | ||
| */ | ||
| function isClaudeCode(useResearch = false, projectRoot = null) { | ||
| const currentProvider = useResearch | ||
| ? getResearchProvider(projectRoot) | ||
| : getMainProvider(projectRoot); | ||
| return currentProvider === CUSTOM_PROVIDERS.CLAUDE_CODE; | ||
| } | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Solid helper: centralizes Claude Code detection.
Matches existing ad-hoc logic and improves reuse.
Refactor callers (e.g., scripts/modules/task-manager/expand-task.js, analyze-task-complexity.js) to import and use this helper to remove duplicated provider checks.
🏁 Script executed:
#!/bin/bash
# Find duplicated inline provider checks that can be replaced by isClaudeCode()
rg -nP -C2 '(getResearchProvider\(|getMainProvider\().*currentProvider|\bconst\s+isClaudeCode\s*=\s*currentProvider\s*===\s*CUSTOM_PROVIDERS\.CLAUDE_CODE' --type=jsLength of output: 1103
Replace inline provider checks with the isClaudeCode helper.
Duplicated logic found in
scripts/modules/task-manager/expand-task.js(lines 462–464)scripts/modules/task-manager/analyze-task-complexity.js(lines 419–421)
Refactor both to call isClaudeCode(useResearch, projectRoot) instead of inlining getResearchProvider/getMainProvider and the currentProvider === CUSTOM_PROVIDERS.CLAUDE_CODE check.
🤖 Prompt for AI Agents
In scripts/modules/config-manager.js around lines 430-442 you added
isClaudeCode(useResearch = false, projectRoot = null) to encapsulate the
provider check; update the two call sites that still inline the
check—scripts/modules/task-manager/expand-task.js (lines ~462–464) and
scripts/modules/task-manager/analyze-task-complexity.js (lines ~419–421) —to use
that helper. Replace the inline getResearchProvider/getMainProvider +
CUSTOM_PROVIDERS.CLAUDE_CODE comparison with a call to isClaudeCode(useResearch,
projectRoot), importing/require-ing the helper from
scripts/modules/config-manager.js if needed, and pass the correct useResearch
flag and projectRoot (or null) available in that module; remove the duplicated
logic so both files rely on the single helper.
| getResearchModelId, | ||
| getResearchMaxTokens, | ||
| getResearchTemperature, | ||
| isClaudeCode, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Export looks correct; also align API-keyless providers with Claude Code.
Since Claude Code is first-class now, include it in providersWithoutApiKeys and drop the special-case branch to avoid inconsistent checks across modules.
Apply:
@@
export const providersWithoutApiKeys = [
CUSTOM_PROVIDERS.OLLAMA,
CUSTOM_PROVIDERS.BEDROCK,
CUSTOM_PROVIDERS.GEMINI_CLI,
- CUSTOM_PROVIDERS.MCP
+ CUSTOM_PROVIDERS.MCP,
+ CUSTOM_PROVIDERS.CLAUDE_CODE
];And simplify isApiKeySet:
- // Claude Code doesn't require an API key
- if (providerName?.toLowerCase() === 'claude-code') {
- return true; // No API key needed
- }
+ // covered by providersWithoutApiKeys📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| isClaudeCode, | |
| // In scripts/modules/config-manager.js | |
| // --- Update the list of API-keyless providers to include Claude Code | |
| export const providersWithoutApiKeys = [ | |
| CUSTOM_PROVIDERS.OLLAMA, | |
| CUSTOM_PROVIDERS.BEDROCK, | |
| CUSTOM_PROVIDERS.GEMINI_CLI, | |
| CUSTOM_PROVIDERS.MCP, | |
| CUSTOM_PROVIDERS.CLAUDE_CODE | |
| ]; | |
| // ... elsewhere in this file ... | |
| export function isApiKeySet(providerName, session) { | |
| // covered by providersWithoutApiKeys | |
| if (!providerName) { | |
| return false; | |
| } | |
| // existing logic that checks providersWithoutApiKeys and falls back to key lookup | |
| return !providersWithoutApiKeys.includes(providerName) | |
| ? /* check actual API key in config */ | |
| Boolean(getConfig(`${providerName}.apiKey`, session)) | |
| : true; | |
| } |
🤖 Prompt for AI Agents
In scripts/modules/config-manager.js around line 999, the export includes
isClaudeCode but the providersWithoutApiKeys list and isApiKeySet logic still
treat Claude Code as a special case; update providersWithoutApiKeys to include
the Claude Code provider so it is treated the same as other API-keyless
providers, remove the special-case branch that checks for Claude Code
separately, and simplify isApiKeySet to rely solely on the
providersWithoutApiKeys membership check (no extra conditional) so all
API-keyless providers are handled consistently across modules.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
scripts/modules/task-manager/update-subtask-by-id.js (1)
23-23: Importing isClaudeCode from config-manager is good; keep provider checks centralized.This aligns with the guideline to avoid inline provider detection in core logic. Ensure other task-manager modules use the same helper for consistency.
scripts/modules/task-manager/add-task.js (1)
428-431: Prompt parameters added; ensure the template consumes them.Past comments flagged
add-task.jsonnot usingdependencies. Verify thatsrc/prompts/add-task.jsonreferencesdependencies,isClaudeCode, andprojectRoot. If not, update the template or temporarily pass bothgatheredContext/projectContextas needed.#!/bin/bash # Verify add-task prompt actually uses these placeholders rg -nP --hidden --glob 'src/prompts/add-task.json' -C2 '\{\{\s*(dependencies|isClaudeCode|projectRoot|gatheredContext|projectContext)\s*\}\}'
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
scripts/modules/task-manager/add-task.js(2 hunks)scripts/modules/task-manager/update-subtask-by-id.js(2 hunks)scripts/modules/task-manager/update-task-by-id.js(2 hunks)scripts/modules/task-manager/update-tasks.js(2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
🧠 Learnings (36)
📓 Common learnings
Learnt from: eyaltoledano
PR: eyaltoledano/claude-task-master#1069
File: .changeset/floppy-news-buy.md:7-38
Timestamp: 2025-08-02T14:54:52.216Z
Learning: For major feature additions like new CLI commands, eyaltoledano prefers detailed changesets with comprehensive descriptions, usage examples, and feature explanations rather than minimal single-line summaries.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Commands such as `analyze-complexity`, `expand-task`, `update-task`, and `add-task` should consider adopting the context gathering pattern for improved AI-powered assistance.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-11T12:30:23.843Z
Learning: Import Task Master's development workflow commands and guidelines; treat the contents of ./.taskmaster/CLAUDE.md as if included in the main CLAUDE.md
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI, create them in the current tag context (defaulting to 'master'), provide clear prompts to guide AI task generation, and validate/clean up AI-generated tasks.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Provide functions for updating task status within the current tag context, handling both individual tasks and subtasks, and considering subtask status when updating parent tasks.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: When implementation differs significantly from planned approach, call `node scripts/dev.js update --from=<futureTaskId> --prompt="<explanation>"` to update tasks.json.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-08-11T12:30:23.843Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-11T12:30:23.843Z
Learning: Import Task Master's development workflow commands and guidelines; treat the contents of ./.taskmaster/CLAUDE.md as if included in the main CLAUDE.md
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent formatting for task files, include all task properties in text files, and format dependencies with status indicators.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-08-06T21:12:43.715Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1091
File: assets/claude/agents/task-orchestrator.md:1-6
Timestamp: 2025-08-06T21:12:43.715Z
Learning: In the eyaltoledano/claude-task-master repository, agent files are intentionally duplicated between `.claude/agents/` (for internal project use) and `assets/claude/agents/` (as template files for users to copy). This duplication serves different purposes and should be maintained to support both internal development and user distribution needs.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-08-06T21:12:20.981Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1091
File: assets/claude/agents/task-executor.md:1-6
Timestamp: 2025-08-06T21:12:20.981Z
Learning: In the eyaltoledano/claude-task-master repository, agent files in assets/claude/agents/ are intended for distribution to users (for copying), while identical files in .claude/agents/ are for internal project use. This intentional duplication serves different purposes and is not a DRY violation.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not implement fallback or retry logic outside `ai-services-unified.js`.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Place utilities used primarily by the core `task-master` CLI logic and command modules (`scripts/modules/*`) into `scripts/modules/utils.js`.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (`task-manager/`) or MCP direct functions.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-31T22:07:49.716Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-31T22:07:49.716Z
Learning: Applies to scripts/modules/commands.js : For AI-powered commands that benefit from project context, use the ContextGatherer utility for multi-source context extraction, support task IDs, file paths, custom context, and project tree, implement fuzzy search for automatic task discovery, and display detailed token breakdown for transparency.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Generate task files from the current tag context, include tag information in generated files, and do not mix tasks from different tags in file generation.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Implement reusable task finding utilities that support both task and subtask lookups and add context to subtask results.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils/contextGatherer.js : Use `ContextGatherer` in `scripts/modules/utils/contextGatherer.js` for AI-powered commands that need project context, supporting tasks, files, custom text, project tree context, token counting, and multiple output formats.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Centralize all LLM calls through `generateTextService` or `generateObjectService`.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:13.815Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Applies to scripts/modules/utils/contextGatherer.js : Gracefully handle missing files with warnings, validate task IDs, continue processing even if some context sources fail, and provide fallback behavior when context gathering fails.
Applied to files:
scripts/modules/task-manager/update-subtask-by-id.jsscripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/*.js : Ensure new features work with existing projects seamlessly, supporting both legacy and tagged task data formats, and support silent migration during feature usage.
Applied to files:
scripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Implement silent migration from legacy to tagged format in the readJSON() function, detect legacy format, convert automatically, and preserve all existing task data during migration.
Applied to files:
scripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/task-manager.js : Features that create, read, update, or delete tasks belong in 'scripts/modules/task-manager.js'.
Applied to files:
scripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Applies to scripts/modules/task-manager/*.js : Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Applied to files:
scripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:14:54.131Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/telemetry.mdc:0-0
Timestamp: 2025-07-18T17:14:54.131Z
Learning: Applies to scripts/modules/task-manager/**/*.js : If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.
Applied to files:
scripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:54.131Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/telemetry.mdc:0-0
Timestamp: 2025-07-18T17:14:54.131Z
Learning: Applies to scripts/modules/task-manager/**/*.js : Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Applied to files:
scripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/task-manager/**/*.js : Do not call AI-specific getters (like `getMainModelId`, `getMainMaxTokens`) from core logic functions in `scripts/modules/task-manager/*`; instead, pass the `role` to the unified AI service.
Applied to files:
scripts/modules/task-manager/update-tasks.jsscripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:14:54.131Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/telemetry.mdc:0-0
Timestamp: 2025-07-18T17:14:54.131Z
Learning: Applies to scripts/modules/commands.js : CLI command definitions in scripts/modules/commands.js must call the appropriate core logic function with outputFormat: 'text', and must not call displayAiUsageSummary directly if the core logic function already handles it.
Applied to files:
scripts/modules/task-manager/update-tasks.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not fetch AI-specific parameters (model ID, max tokens, temp) using `config-manager.js` getters for the AI call. Pass the `role` instead.
Applied to files:
scripts/modules/task-manager/add-task.jsscripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: Use `task-master add-task` to add a new task to tasks.json using AI.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-08-06T21:13:05.240Z
Learnt from: Crunchyman-ralph
PR: eyaltoledano/claude-task-master#1091
File: assets/claude/agents/task-orchestrator.md:69-78
Timestamp: 2025-08-06T21:13:05.240Z
Learning: For Claude agent instruction files in .claude/agents/ and assets/claude/agents/ directories, ignore markdownlint issues (like MD031 blanks-around-fences, MD040 fenced-code-language, MD041 missing top-level heading) as these files follow Claude's specific agent format requirements rather than standard markdown documentation conventions.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Be aware of potential reliability issues with `generateObjectService` across different providers and complex schemas. Prefer `generateTextService` + manual parsing as a more robust alternative for structured data needs.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:18:17.759Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-07-18T17:18:17.759Z
Learning: Applies to scripts/modules/utils.js : Implement complete migration for all related files in the tagged task system, handle configuration and state file creation, and provide migration status tracking.
Applied to files:
scripts/modules/task-manager/add-task.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Applies to scripts/modules/*.js : Each module in scripts/modules/ should be focused on a single responsibility, following the modular architecture (e.g., commands.js for CLI command handling, task-manager.js for task data and core logic, dependency-manager.js for dependency management, ui.js for CLI output formatting, ai-services-unified.js for AI service integration, config-manager.js for configuration management, utils.js for utility functions).
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/*.js : Use consistent file naming conventions: 'task_${id.toString().padStart(3, '0')}.txt', use path.join for composing file paths, and use appropriate file extensions (.txt for tasks, .json for data).
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:06:04.909Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_providers.mdc:0-0
Timestamp: 2025-07-18T17:06:04.909Z
Learning: Applies to src/ai-providers/*.js : Provider modules must import the provider's create<ProviderName> function from ai-sdk/<provider-name>, and import generateText, streamText, generateObject from the core ai package, as well as the log utility from ../../scripts/modules/utils.js.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
📚 Learning: 2025-07-18T17:09:13.815Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Applies to scripts/modules/utils/fuzzyTaskSearch.js : Export `FuzzyTaskSearch`, `PURPOSE_CATEGORIES`, and `RELEVANCE_THRESHOLDS` from the fuzzy search module.
Applied to files:
scripts/modules/task-manager/update-task-by-id.js
🧬 Code graph analysis (4)
scripts/modules/task-manager/update-subtask-by-id.js (2)
scripts/modules/task-manager/update-task-by-id.js (2)
gatheredContext(362-362)projectRoot(318-318)scripts/modules/task-manager/expand-task.js (3)
gatheredContext(365-365)isClaudeCode(464-464)projectRoot(324-324)
scripts/modules/task-manager/update-tasks.js (7)
scripts/modules/task-manager/add-task.js (1)
gatheredContext(397-397)scripts/modules/task-manager/update-subtask-by-id.js (2)
gatheredContext(140-140)projectRoot(90-90)scripts/modules/task-manager/update-task-by-id.js (2)
gatheredContext(362-362)projectRoot(318-318)scripts/modules/task-manager/expand-task.js (3)
gatheredContext(365-365)isClaudeCode(464-464)projectRoot(324-324)scripts/modules/task-manager/analyze-task-complexity.js (4)
gatheredContext(234-234)isClaudeCode(421-421)useResearch(96-96)projectRoot(97-97)scripts/modules/task-manager/research.js (2)
gatheredContext(193-193)projectRoot(76-76)scripts/modules/utils.js (2)
projectRoot(576-578)projectRoot(671-671)
scripts/modules/task-manager/add-task.js (2)
scripts/modules/task-manager/expand-task.js (2)
isClaudeCode(464-464)projectRoot(324-324)scripts/modules/task-manager/analyze-task-complexity.js (3)
isClaudeCode(421-421)useResearch(96-96)projectRoot(97-97)
scripts/modules/task-manager/update-task-by-id.js (10)
scripts/modules/task-manager/add-task.js (1)
gatheredContext(397-397)scripts/modules/task-manager/update-subtask-by-id.js (2)
gatheredContext(140-140)projectRoot(90-90)scripts/modules/task-manager/update-tasks.js (2)
gatheredContext(339-339)projectRoot(316-316)scripts/modules/task-manager/expand-task.js (3)
gatheredContext(365-365)isClaudeCode(464-464)projectRoot(324-324)scripts/modules/task-manager/analyze-task-complexity.js (4)
gatheredContext(234-234)isClaudeCode(421-421)useResearch(96-96)projectRoot(97-97)scripts/modules/task-manager/research.js (2)
gatheredContext(193-193)projectRoot(76-76)scripts/modules/utils.js (2)
projectRoot(576-578)projectRoot(671-671)scripts/modules/ui.js (1)
projectRoot(2357-2357)src/utils/path-utils.js (5)
projectRoot(108-108)projectRoot(197-197)projectRoot(269-269)projectRoot(340-340)projectRoot(386-386)scripts/modules/task-manager/expand-all-tasks.js (1)
projectRoot(47-47)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (6)
scripts/modules/task-manager/update-subtask-by-id.js (1)
234-237: Prompt template correctly references all new parameters.src/prompts/update-subtask.jsonusesisClaudeCode(line 64),projectRoot(line 64), andgatheredContext(lines 63–65). No changes needed.scripts/modules/task-manager/update-tasks.js (2)
22-22: Good: provider detection moved to config-manager.Keeps core logic clean and consistent with guidelines.
438-441: All placeholders consumed in template
Verified thatprojectContext,isClaudeCode, andprojectRootare referenced insrc/prompts/update-tasks.json. No further changes required.scripts/modules/task-manager/update-task-by-id.js (2)
26-26: Importing isApiKeySet and isClaudeCode here is appropriate.Pre-checking the research provider key and centralizing provider detection match the architectural rules.
456-459: AddprojectContextparameter and prompt placeholder
- In scripts/modules/task-manager/update-task-by-id.js, insert
projectContext: gatheredContext || ''intopromptParams.- In src/prompts/update-task.json, add a Handlebars block for
projectContextalongsidegatheredContextso the prompt can consume it.--- a/scripts/modules/task-manager/update-task-by-id.js +++ b/scripts/modules/task-manager/update-task-by-id.js @@ const promptParams = { - gatheredContext: gatheredContext || '', + gatheredContext: gatheredContext || '', + projectContext: gatheredContext || '',--- a/src/prompts/update-task.json +++ b/src/prompts/update-task.json @@ -{{#if gatheredContext}} - -# Project Context - -{{gatheredContext}} -{{/if}} +{{#if gatheredContext}} +# Project Context + +{{gatheredContext}} +{{/if}} +{{#if projectContext}} +# Project Context (alias) + +{{projectContext}} +{{/if}}⛔ Skipped due to learnings
Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/commands.mdc:0-0 Timestamp: 2025-07-31T22:07:49.716Z Learning: Applies to scripts/modules/commands.js : For AI-powered commands that benefit from project context, use the ContextGatherer utility for multi-source context extraction, support task IDs, file paths, custom context, and project tree, implement fuzzy search for automatic task discovery, and display detailed token breakdown for transparency.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/commands.mdc:0-0 Timestamp: 2025-07-18T17:08:48.695Z Learning: Applies to scripts/modules/commands.js : For AI-powered commands that benefit from project context, use the ContextGatherer utility for multi-source context extraction, support task IDs, file paths, custom context, and project tree, implement fuzzy search for automatic task discovery, and display detailed token breakdown for transparency.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/utilities.mdc:0-0 Timestamp: 2025-07-18T17:18:17.759Z Learning: Applies to scripts/modules/utils/contextGatherer.js : Use `ContextGatherer` in `scripts/modules/utils/contextGatherer.js` for AI-powered commands that need project context, supporting tasks, files, custom text, project tree context, token counting, and multiple output formats.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/tags.mdc:0-0 Timestamp: 2025-07-18T17:13:30.188Z Learning: Applies to scripts/modules/task-manager/* : All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tagLearnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:16.839Z Learning: Applies to scripts/modules/utils/contextGatherer.js : Use the `ContextGatherer` class in `scripts/modules/utils/contextGatherer.js` as the centralized utility for extracting context from multiple sources in Task Master commands.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:13.815Z Learning: Applies to scripts/modules/utils/contextGatherer.js : Use the `ContextGatherer` class from `scripts/modules/utils/contextGatherer.js` as the centralized utility for extracting context from multiple sources in Task Master commands.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:13.815Z Learning: When implementing AI-powered commands that benefit from project context, use the context gathering pattern: validate parameters, initialize `ContextGatherer`, auto-discover relevant tasks with `FuzzyTaskSearch` if none specified, gather context with token breakdown, and display token breakdown for CLI.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/tags.mdc:0-0 Timestamp: 2025-07-18T17:13:30.188Z Learning: Applies to scripts/modules/* : All commands must pass { projectRoot, tag } as context to core functionsLearnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:13.815Z Learning: Applies to scripts/modules/utils/contextGatherer.js : Gracefully handle missing files with warnings, validate task IDs, continue processing even if some context sources fail, and provide fallback behavior when context gathering fails.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:13.815Z Learning: Use context gathering for AI-powered commands that benefit from project context, when users might want to reference specific tasks or files, or for research, analysis, or generation commands. Do not use for simple CRUD operations that don't need AI context.Learnt from: CR PR: eyaltoledano/claude-task-master#0 File: .cursor/rules/context_gathering.mdc:0-0 Timestamp: 2025-07-18T17:09:13.815Z Learning: Applies to scripts/modules/utils/contextGatherer.js : Set reasonable file size limits (50KB default) and limit project tree depth (3-5 levels) when gathering context for AI-powered commands.scripts/modules/task-manager/add-task.js (1)
28-28: Centralized provider detection import looks good.Matches the guideline to keep provider logic out of core flow.
| dependencies: numericDependencies, | ||
| isClaudeCode: isClaudeCode(useResearch, projectRoot), | ||
| projectRoot: projectRoot | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Prefer generateTextService + manual parse for reliability (optional).
Given provider variance of generateObjectService, consider switching to generateTextService with explicit JSON extraction and Zod validation (pattern already implemented in update-task/update-tasks).
🤖 Prompt for AI Agents
In scripts/modules/task-manager/add-task.js around lines 428 to 431, the call
using generateObjectService is fragile across providers; replace it with
generateTextService, then manually extract the JSON payload from the returned
text (robustly strip surrounding text/markdown/code fences and parse JSON), and
validate the parsed object with the existing Zod schema pattern used in
update-task/update-tasks; update error handling to log parsing/validation
failures and fall back or retry as appropriate.
| gatheredContext: gatheredContext || '', | ||
| isClaudeCode: isClaudeCode(useResearch, projectRoot), | ||
| projectRoot: projectRoot | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Unify context param naming across prompts; also pass both keys to be safe.
Other modules use projectContext, while this one passes gatheredContext. To avoid template/key drift, pass both (aliasing to the same value).
Apply:
const promptParams = {
parentTask: parentContext,
prevSubtask: prevSubtask,
nextSubtask: nextSubtask,
currentDetails: subtask.details || '(No existing details)',
updatePrompt: prompt,
useResearch: useResearch,
- gatheredContext: gatheredContext || '',
+ gatheredContext: gatheredContext || '',
+ projectContext: gatheredContext || '',
isClaudeCode: isClaudeCode(useResearch, projectRoot),
projectRoot: projectRoot
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| gatheredContext: gatheredContext || '', | |
| isClaudeCode: isClaudeCode(useResearch, projectRoot), | |
| projectRoot: projectRoot | |
| }; | |
| const promptParams = { | |
| parentTask: parentContext, | |
| prevSubtask: prevSubtask, | |
| nextSubtask: nextSubtask, | |
| currentDetails: subtask.details || '(No existing details)', | |
| updatePrompt: prompt, | |
| useResearch: useResearch, | |
| gatheredContext: gatheredContext || '', | |
| projectContext: gatheredContext || '', | |
| isClaudeCode: isClaudeCode(useResearch, projectRoot), | |
| projectRoot: projectRoot | |
| }; |
🤖 Prompt for AI Agents
In scripts/modules/task-manager/update-subtask-by-id.js around lines 234 to 237,
the prompt context key is named gatheredContext while other modules expect
projectContext; modify the object to include both keys (projectContext and
gatheredContext) aliased to the same value (e.g., const ctx = gatheredContext ||
'' then set projectContext: ctx, gatheredContext: ctx) so both
templates/consumers work without breaking changes.
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
tests/unit/scripts/modules/task-manager/add-task.test.js(1 hunks)tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.js(1 hunks)tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.js(1 hunks)tests/unit/scripts/modules/task-manager/update-task-by-id.test.js(1 hunks)tests/unit/scripts/modules/task-manager/update-tasks.test.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (8)
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
🧠 Learnings (15)
📓 Common learnings
Learnt from: eyaltoledano
PR: eyaltoledano/claude-task-master#1069
File: .changeset/floppy-news-buy.md:7-38
Timestamp: 2025-08-02T14:54:52.216Z
Learning: For major feature additions like new CLI commands, eyaltoledano prefers detailed changesets with comprehensive descriptions, usage examples, and feature explanations rather than minimal single-line summaries.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Commands such as `analyze-complexity`, `expand-task`, `update-task`, and `add-task` should consider adopting the context gathering pattern for improved AI-powered assistance.
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-11T12:30:23.843Z
Learning: Import Task Master's development workflow commands and guidelines; treat the contents of ./.taskmaster/CLAUDE.md as if included in the main CLAUDE.md
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Do not import real AI service clients in tests; create fully mocked versions that return predictable responses.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Verify modifications on the in-memory task objects passed to writeJSON.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-task-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Always mock tests properly based on the way the tested functions are defined and used.
Applied to files:
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:07:39.336Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-07-18T17:07:39.336Z
Learning: Module dependencies should be mocked before importing the test module, following Jest's hoisting behavior.
Applied to files:
tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Applied to files:
tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Be careful with how you mock or stub functions that depend on module state; use factory functions in mocks to ensure proper initialization order.
Applied to files:
tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Follow the mock-first-then-import pattern and use jest.spyOn() for testing in Jest, clearing mocks between tests.
Applied to files:
tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.jstests/unit/scripts/modules/task-manager/update-tasks.test.jstests/unit/scripts/modules/task-manager/add-task.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{integration,e2e}/**/*.test.js : Properly mock session objects when required by functions, and reset environment variables between tests if modified.
Applied to files:
tests/unit/scripts/modules/task-manager/update-tasks.test.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Test CLI and MCP interfaces with real task data, verify end-to-end workflows across tag contexts, and test error scenarios and recovery in integration tests.
Applied to files:
tests/unit/scripts/modules/task-manager/update-tasks.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Troubleshoot mock functions not being called by ensuring mocks are defined before imports, referencing the correct mock instance, and verifying import paths.
Applied to files:
tests/unit/scripts/modules/task-manager/update-tasks.test.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Test core logic independently with both data formats, mock file system operations, test tag resolution behavior, and verify migration compatibility in unit tests.
Applied to files:
tests/unit/scripts/modules/task-manager/update-tasks.test.js
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (1)
tests/unit/scripts/modules/task-manager/analyze-task-complexity.test.js (1)
190-192: LGTM – mock alignmentAdding
isClaudeCodeto the config-manager mock keeps mocks consistent across the suite. No further changes needed here since this command isn’t part of the code-context expansion in this PR.
| getDefaultPriority: jest.fn(() => 'medium'), | ||
| isClaudeCode: jest.fn(() => false) | ||
| }) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Verify isClaudeCode is used in add-task path
The new mock is good. Strengthen the test to ensure the flag is actually used.
After other imports:
const { isClaudeCode } = await import('../../../../../scripts/modules/config-manager.js');In test "should add a new task using AI", after the call:
expect(isClaudeCode).toHaveBeenCalledWith(false, '/mock/project/root');
const aiArg = generateObjectService.mock.calls[0][0];
expect(aiArg).toEqual(expect.objectContaining({ projectRoot: '/mock/project/root' }));
expect(aiArg.promptParams || aiArg).toEqual(
expect.objectContaining({ isClaudeCode: false, projectRoot: '/mock/project/root' })
);Optionally, a dedicated test toggling:
isClaudeCode.mockReturnValueOnce(true);
// ... call addTask(...)
const aiArg2 = generateObjectService.mock.calls.at(-1)[0];
expect(aiArg2.promptParams || aiArg2).toEqual(expect.objectContaining({ isClaudeCode: true }));🤖 Prompt for AI Agents
In tests/unit/scripts/modules/task-manager/add-task.test.js around lines 102 to
104, strengthen the "should add a new task using AI" test to verify the new
isClaudeCode mock is actually used: import isClaudeCode from the config-manager
after other imports, then after calling addTask assert isClaudeCode was called
with (false, '/mock/project/root'); inspect
generateObjectService.mock.calls[0][0] and assert it (or its promptParams)
contains { isClaudeCode: false, projectRoot: '/mock/project/root' }; optionally
add a separate short test that sets isClaudeCode.mockReturnValueOnce(true),
calls addTask again, and asserts the last generateObjectService call contains
isClaudeCode: true.
| getDebugFlag: jest.fn(() => false), | ||
| isClaudeCode: jest.fn(() => false) | ||
| }) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Assert isClaudeCode invocation and AI payload inclusion
You introduced the mock but don’t verify it’s used. Add assertions in the happy-path test.
At imports:
const { isClaudeCode } = await import('../../../../../scripts/modules/config-manager.js');
const { generateTextService } = await import('../../../../../scripts/modules/ai-services-unified.js');In test "successfully updates subtask with valid inputs", after the call:
expect(isClaudeCode).toHaveBeenCalledWith(false, '/project');
const aiArg = generateTextService.mock.calls[0][0];
expect(aiArg).toEqual(expect.objectContaining({ projectRoot: '/project' }));
expect(aiArg.promptParams || aiArg).toEqual(
expect.objectContaining({ isClaudeCode: false, projectRoot: '/project' })
);🤖 Prompt for AI Agents
In tests/unit/scripts/modules/task-manager/update-subtask-by-id.test.js around
lines 55 to 57, the new mocks for isClaudeCode and generateTextService are not
being asserted in the happy-path test; add imports for isClaudeCode and
generateTextService from the specified modules near the other imports, then in
the "successfully updates subtask with valid inputs" test, after invoking the
function under test add assertions that isClaudeCode was called with (false,
'/project') and that generateTextService was called with an argument containing
projectRoot: '/project' and isClaudeCode: false (checking either
aiArg.promptParams or aiArg itself for those properties).
| isApiKeySet: jest.fn(() => true), | ||
| isClaudeCode: jest.fn(() => false) | ||
| }) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add a happy-path test that asserts isClaudeCode and AI payload fields
Current tests only cover validation error paths; they never exercise the new flag. Add a minimal success test to prevent regressions.
New test (append near the end):
const { isClaudeCode } = await import('../../../../../scripts/modules/config-manager.js');
const { generateTextService } = await import('../../../../../scripts/modules/ai-services-unified.js');
test('calls isClaudeCode with correct args and passes flag to AI (happy path)', async () => {
const fs = await import('fs');
fs.existsSync.mockReturnValue(true);
readJSON.mockReturnValue({ tag: 'master', tasks: [{ id: 1, title: 'T1' }] });
await expect(
updateTaskById('tasks/tasks.json', 1, 'update it', false, { tag: 'master' }, 'json')
).resolves.not.toThrow();
expect(isClaudeCode).toHaveBeenCalledWith(false, '/project');
const aiArg = generateTextService.mock.calls[0][0];
expect(aiArg).toEqual(expect.objectContaining({ projectRoot: '/project' }));
expect(aiArg.promptParams || aiArg).toEqual(
expect.objectContaining({ isClaudeCode: false, projectRoot: '/project' })
);
});🤖 Prompt for AI Agents
In tests/unit/scripts/modules/task-manager/update-task-by-id.test.js around
lines 54 to 56, add a new happy-path test that imports isClaudeCode and
generateTextService, sets fs.existsSync to true and readJSON to return a tasks
file with id 1, then calls updateTaskById and asserts it resolves; verify
isClaudeCode was called with (false, '/project'); and inspect the first
generateTextService call argument to assert it contains projectRoot: '/project'
and that prompt params (or the arg itself) include isClaudeCode: false and
projectRoot: '/project'. Ensure mocks and imports match existing test patterns
and append the test near the end of the file.
| getDebugFlag: jest.fn(() => false), | ||
| isClaudeCode: jest.fn(() => false) | ||
| }) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Assert isClaudeCode propagation and call args
You mock isClaudeCode but never verify it’s called or that its value reaches the AI payload. Add minimal assertions to lock the feature:
Add after other imports:
const { isClaudeCode } = await import('../../../../../scripts/modules/config-manager.js');In test "should update tasks based on new context", after invoking updateTasks:
// Verify isClaudeCode is consulted with (useResearch=false, projectRoot from context)
expect(isClaudeCode).toHaveBeenCalledWith(false, '/mock/path');
// Verify AI payload contains the flag and projectRoot
const aiArg = generateTextService.mock.calls[0][0];
expect(aiArg).toEqual(expect.objectContaining({
projectRoot: '/mock/path'
}));
expect(aiArg.promptParams || aiArg).toEqual(
expect.objectContaining({ isClaudeCode: false, projectRoot: '/mock/path' })
);Optionally add a second test flipping the flag:
isClaudeCode.mockReturnValueOnce(true);
// ... call updateTasks(...)
const aiArg2 = generateTextService.mock.calls.at(-1)[0];
expect(aiArg2.promptParams || aiArg2).toEqual(
expect.objectContaining({ isClaudeCode: true })
);🤖 Prompt for AI Agents
In tests/unit/scripts/modules/task-manager/update-tasks.test.js around lines
47-49, the mocked isClaudeCode is not asserted or its value propagated into the
AI payload; import isClaudeCode from the config-manager at top of the test file,
then in the "should update tasks based on new context" test add assertions after
calling updateTasks to verify isClaudeCode was called with (false, '/mock/path')
and that the generateTextService call's first argument contains projectRoot:
'/mock/path' and includes isClaudeCode: false (checking either top-level or
promptParams), and optionally add a second test that sets isClaudeCode to return
true once, calls updateTasks, and asserts the last generateTextService call
contains isClaudeCode: true.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (6)
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js (2)
309-319: Make loadPrompt spy-able to assert isClaudeCode/projectRoot are passedExpose a shared mock so you can assert the prompt params when toggling isClaudeCode. Example change:
+// At file top (before mocks) +const loadPromptMock = jest.fn().mockResolvedValue({ + systemPrompt: 'Mocked system prompt', + userPrompt: 'Mocked user prompt' +}); + jest.unstable_mockModule( '../../../../../scripts/modules/prompt-manager.js', () => ({ - getPromptManager: jest.fn().mockReturnValue({ - loadPrompt: jest.fn().mockResolvedValue({ - systemPrompt: 'Mocked system prompt', - userPrompt: 'Mocked user prompt' - }) - }) + getPromptManager: jest.fn().mockReturnValue({ loadPrompt: loadPromptMock }) }) );Then add one test that sets isClaudeCode.mockReturnValue(true) and asserts loadPromptMock was called with params containing { isClaudeCode: true, projectRoot }. This validates the new code-context wiring.
582-601: Prefer non-async Jest tests per repo rulesRepo guideline says “Never use asynchronous operations in tests.” Convert tests to return Promises instead of using async/await. Example refactor for one case:
-test('should resolve master tag to default filename', async () => { - const options = { ... }; - await analyzeTaskComplexity(options, { projectRoot, mcpLog: { ... } }); - expect(resolveComplexityReportOutputPath).toHaveBeenCalledWith( ... ); - expect(mockWriteFileSync).toHaveBeenCalledWith( ... ); -}); +test('should resolve master tag to default filename', () => { + const options = { ... }; + return analyzeTaskComplexity(options, { projectRoot, mcpLog: { ... } }) + .then(() => { + expect(resolveComplexityReportOutputPath).toHaveBeenCalledWith( ... ); + expect(mockWriteFileSync).toHaveBeenCalledWith( ... ); + }); +});Apply similarly to other tests in this file.
Also applies to: 621-639, 660-724, 728-760, 762-794, 796-838, 842-886, 888-932, 936-1043, 1047-1144
scripts/modules/task-manager/analyze-task-complexity.js (4)
16-22: Tighten imports; delegate provider detection to isClaudeCode onlyYou no longer use getMainProvider/getResearchProvider here. Trim the import to avoid dead code.
-import { - getDebugFlag, - getProjectName, - getMainProvider, - getResearchProvider, - isClaudeCode -} from '../config-manager.js'; +import { getDebugFlag, getProjectName, isClaudeCode } from '../config-manager.js';Also consider removing the unused CUSTOM_PROVIDERS import on Line 28.
356-361: Ensure report directory exists before write to avoid ENOENTCreate the parent directory recursively prior to fs.writeFileSync.
+import path from 'path'; ... - fs.writeFileSync( + fs.mkdirSync(path.dirname(outputPath), { recursive: true }); + fs.writeFileSync( outputPath, JSON.stringify(emptyReport, null, '\t'), 'utf8' );And similarly for the final write:
- fs.writeFileSync(outputPath, JSON.stringify(report, null, '\t'), 'utf8'); + fs.mkdirSync(path.dirname(outputPath), { recursive: true }); + fs.writeFileSync(outputPath, JSON.stringify(report, null, '\t'), 'utf8');Also applies to: 603-605
41-73: Remove unused prompt buildergenerateInternalComplexityAnalysisPrompt is not invoked anymore; delete to reduce noise.
-function generateInternalComplexityAnalysisPrompt( - tasksData, - gatheredContext = '' -) { - const tasksString = JSON.stringify(tasksData.tasks, null, 2); - let prompt = `Analyze the following tasks to determine their complexity (1-10 scale) and recommend the number of subtasks for expansion. Provide a brief reasoning and an initial expansion prompt for each. -... - return prompt; -}
28-28: Clean up unused provider importCUSTOM_PROVIDERS is not referenced after the refactor; remove the import.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
scripts/modules/task-manager/analyze-task-complexity.js(2 hunks)tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (12)
tests/{unit,integration,e2e,fixtures}/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Test files must be organized as follows: unit tests in tests/unit/, integration tests in tests/integration/, end-to-end tests in tests/e2e/, and test fixtures in tests/fixtures/.
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
**/*.{test,spec}.{js,ts,jsx,tsx}
📄 CodeRabbit inference engine (.cursor/rules/git_workflow.mdc)
**/*.{test,spec}.{js,ts,jsx,tsx}: Create a test file and ensure all tests pass when all subtasks are complete; commit tests if added or modified
When all subtasks are complete, run final testing using the appropriate test runner (e.g., npm test, jest, or manual testing)
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Make all mocks return synchronous values when possible.
Always mock tests properly based on the way the tested functions are defined and used.
Follow the test file organization: mocks must be set up before importing modules under test, and spies on mocked modules should be set up after imports.
Use fixtures from tests/fixtures/ for consistent sample data across tests.
Always declare mocks before importing the modules being tested in Jest test files.
Use jest.spyOn() after imports to create spies on mock functions and reference these spies in test assertions.
When testing functions with callbacks, get the callback from your mock's call arguments, execute it directly with test inputs, and verify the results.
For ES modules, use jest.mock() before static imports and jest.unstable_mockModule() before dynamic imports to mock dependencies.
Reset mock functions (mockFn.mockReset()) before dynamic imports if they might have been called previously.
When verifying console assertions, assert against the actual arguments passed (single formatted string), not multiple arguments.
Use mock-fs to mock file system operations in tests, and restore the file system after each test.
Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Set mock environment variables in test setup and restore them after each test.
Maintain test fixtures separate from test logic.
Follow the mock-first-then-import pattern for all Jest mocks.
Do not define mock variables before jest.mock() calls (they won't be accessible due to hoisting).
Use test-specific file paths (e.g., 'test-tasks.json') for all file operations in tests.
Mock readJSON and writeJSON to avoid real file system interactions in tests.
Verify file operations use the correct paths in expect statements.
Use different file paths for each test to avoid test interdependence.
Verify modifications on the in-memory task objects passed to w...
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
tests/unit/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/unit/**/*.test.js: Unit tests must be located in tests/unit/, test individual functions and utilities in isolation, mock all external dependencies, and keep tests small, focused, and fast.
Do not include actual command execution in unit tests.
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
tests/{unit,integration,e2e}/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
tests/{unit,integration,e2e}/**/*.test.js: When testing CLI commands built with Commander.js, test the command action handlers directly rather than trying to mock the entire Commander.js chain.
When mocking the Commander.js chain, mock ALL chainable methods (option, argument, action, on, etc.) and return this (or the mock object) from all chainable method mocks.
Explicitly handle all options, including defaults and shorthand flags (e.g., -p for --prompt), and include null/undefined checks in test implementations for parameters that might be optional.
Do not try to use the real action implementation without proper mocking, and do not mock Commander partially—either mock it completely or test the action directly.
Mock the action handlers for CLI commands and verify they're called with correct arguments.
Use sample task fixtures for consistent test data, mock file system operations, and test both success and error paths for task operations.
Mock console output and verify correct formatting in UI function tests. Use flexible assertions like toContain() or toMatch() for formatted output.
Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.js: Declare and initialize global variables at the top of modules to avoid hoisting issues.
Use proper function declarations to avoid hoisting issues and initialize variables before they are referenced.
Do not reference variables before their declaration in module scope.
Use dynamic imports (import()) to avoid initialization order issues in modules.
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.jsscripts/modules/task-manager/analyze-task-complexity.js
**/*.{test,spec}.*
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Test files should follow naming conventions: .test., .spec., or _test. depending on the language
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
tests/{unit,integration,e2e}/**
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Organize test directories by test type (unit, integration, e2e) and mirror source structure where possible
Files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
scripts/modules/task-manager/*.js
📄 CodeRabbit inference engine (.cursor/rules/ai_services.mdc)
scripts/modules/task-manager/*.js: Centralize all LLM calls throughgenerateTextServiceorgenerateObjectService.
Do not import or call anything from the oldai-services.js,ai-client-factory.js, orai-client-utils.jsfiles.
Do not initialize AI clients (Anthropic, Perplexity, etc.) directly within core logic (task-manager/) or MCP direct functions.
Do not fetch AI-specific parameters (model ID, max tokens, temp) usingconfig-manager.jsgetters for the AI call. Pass theroleinstead.
Do not implement fallback or retry logic outsideai-services-unified.js.
Do not handle API key resolution outside the service layer (it usesutils.jsinternally).
Determine the appropriaterole(main,research,fallback) in your core logic and pass it to the service.
Pass thesessionobject (received in thecontextparameter, especially from direct function wrappers) to the service call when in MCP context.
UsegenerateTextServiceand implement robust manual JSON parsing (with Zod validation after parsing) when structured output is needed, asgenerateObjectServicehas shown unreliability with some providers/schemas.
Be aware of potential reliability issues withgenerateObjectServiceacross different providers and complex schemas. PrefergenerateTextService+ manual parsing as a more robust alternative for structured data needs.Files in scripts/modules/task-manager/ should each handle a specific action related to task management (e.g., add-task.js, expand-task.js), supporting the tagged task lists system and backward compatibility.
Files:
scripts/modules/task-manager/analyze-task-complexity.js
scripts/modules/**
📄 CodeRabbit inference engine (.cursor/rules/dev_workflow.mdc)
When using the MCP server, restart it if core logic in
scripts/modulesor MCP tool/direct function definitions change.
Files:
scripts/modules/task-manager/analyze-task-complexity.js
scripts/modules/task-manager/*
📄 CodeRabbit inference engine (.cursor/rules/tags.mdc)
scripts/modules/task-manager/*: All core functions in scripts/modules/task-manager/ must accept a context parameter and use it to extract projectRoot and tag
All core functions in scripts/modules/task-manager/ must use readJSON(tasksPath, projectRoot, tag) and writeJSON(tasksPath, data, projectRoot, tag)
Files:
scripts/modules/task-manager/analyze-task-complexity.js
scripts/modules/task-manager/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/telemetry.mdc)
scripts/modules/task-manager/**/*.js: Functions in scripts/modules/task-manager/ that invoke AI services must call the appropriate AI service function (e.g., generateObjectService), passing commandName and outputType in the params object.
Core logic functions in scripts/modules/task-manager/ must return an object that includes aiServiceResponse.telemetryData.
If the core logic function handles CLI output (outputFormat === 'text' or 'cli'), and aiServiceResponse.telemetryData is available, it must call displayAiUsageSummary(aiServiceResponse.telemetryData, 'cli') from scripts/modules/ui.js.Do not call AI-specific getters (like
getMainModelId,getMainMaxTokens) from core logic functions inscripts/modules/task-manager/*; instead, pass theroleto the unified AI service.
Files:
scripts/modules/task-manager/analyze-task-complexity.js
🧠 Learnings (13)
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Mock API calls (e.g., Anthropic/Claude) by mocking the entire module and providing predictable responses.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Do not import real AI service clients in tests; create fully mocked versions that return predictable responses.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Always mock tests properly based on the way the tested functions are defined and used.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Verify modifications on the in-memory task objects passed to writeJSON.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:12:57.903Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-07-18T17:12:57.903Z
Learning: Applies to scripts/modules/**/*.test.js : Test core logic independently with both data formats, mock file system operations, test tag resolution behavior, and verify migration compatibility in unit tests.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to tests/{unit,integration,e2e}/**/*.test.js : Mock chalk functions to return the input text to make testing easier while still verifying correct function calls.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Isolate tests by properly mocking shared resources and resetting state in beforeEach and afterEach hooks.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:16:13.793Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-07-18T17:16:13.793Z
Learning: Applies to **/*.test.js : Troubleshoot mock functions not being called by ensuring mocks are defined before imports, referencing the correct mock instance, and verifying import paths.
Applied to files:
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: Run `node scripts/dev.js analyze-complexity --research` for comprehensive analysis and review the complexity report in scripts/task-complexity-report.json.
Applied to files:
scripts/modules/task-manager/analyze-task-complexity.js
📚 Learning: 2025-07-18T17:09:13.815Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-07-18T17:09:13.815Z
Learning: Commands such as `analyze-complexity`, `expand-task`, `update-task`, and `add-task` should consider adopting the context gathering pattern for improved AI-powered assistance.
Applied to files:
scripts/modules/task-manager/analyze-task-complexity.js
📚 Learning: 2025-07-18T17:06:57.833Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-07-18T17:06:57.833Z
Learning: Applies to scripts/modules/task-manager/*.js : Do not import or call anything from the old `ai-services.js`, `ai-client-factory.js`, or `ai-client-utils.js` files.
Applied to files:
scripts/modules/task-manager/analyze-task-complexity.js
📚 Learning: 2025-07-18T17:14:29.399Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-07-18T17:14:29.399Z
Learning: Applies to scripts/modules/task-manager.js : Use AI to generate detailed subtasks within the current tag context, considering complexity analysis for subtask counts and ensuring proper IDs for newly created subtasks.
Applied to files:
scripts/modules/task-manager/analyze-task-complexity.js
📚 Learning: 2025-07-18T17:19:27.365Z
Learnt from: CR
PR: eyaltoledano/claude-task-master#0
File: assets/.windsurfrules:0-0
Timestamp: 2025-07-18T17:19:27.365Z
Learning: Analyze task complexity with `task-master analyze-complexity --research` before breaking down tasks.
Applied to files:
scripts/modules/task-manager/analyze-task-complexity.js
🧬 Code graph analysis (1)
scripts/modules/task-manager/analyze-task-complexity.js (1)
scripts/modules/task-manager/expand-task.js (1)
isClaudeCode(464-464)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (3)
tests/unit/scripts/modules/task-manager/complexity-report-tag-isolation.test.js (1)
304-306: Good addition: keep config-manager mock aligned with production APIAdding getVertexLocation and isClaudeCode prevents import-time failures and lets future tests toggle provider behavior.
scripts/modules/task-manager/analyze-task-complexity.js (2)
420-426: Correct: pass isClaudeCode and projectRoot into prompt paramsThis aligns analyze-complexity with the new code-context model and keeps prompt schemas consistent across commands.
428-433: analyze-complexity prompt already supports new params
TheisClaudeCodeandprojectRootparameters are defined in thesrc/prompts/analyze-complexity.jsontemplate and theisClaudeCodehelper is exported inscripts/modules/config-manager.js—no action needed.
| const promptParams = { | ||
| tasks: tasksData.tasks, | ||
| gatheredContext: gatheredContext || '', | ||
| useResearch: useResearch, | ||
| isClaudeCode: isClaudeCode, | ||
| isClaudeCode: isClaudeCode(useResearch, projectRoot), | ||
| projectRoot: projectRoot || '' | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Unify code-context detection across modules
expand-task.js still derives isClaudeCode via direct provider comparison (see Relevant snippet). For consistency and single-source-of-truth, migrate it to use config-manager.isClaudeCode(useResearch, projectRoot).
🤖 Prompt for AI Agents
In scripts/modules/task-manager/analyze-task-complexity.js around lines 420 to
426, replace the local/direct provider check for isClaudeCode with the
centralized helper: call config-manager.isClaudeCode(useResearch, projectRoot)
instead of the current isClaudeCode(useResearch, projectRoot), and add the
required import/require for config-manager at the top of the file if it’s not
already present; update the promptParams assignment to use the config-manager
result so code-context detection is unified across modules.
* feat: add support for claude code context - code context for: - add-task - update-subtask - update-task - update * feat: fix CI and format + refactor * chore: format * chore: fix broken tests * chore: fix test
What type of PR is this?
Description
Related Issues
How to Test This
# Example commands or stepsExpected result:
Contributor Checklist
npm run changesetnpm testnpm run format-check(ornpm run formatto fix)Changelog Entry
For Maintainers
Summary by CodeRabbit