Conversation
🦋 Changeset detectedLatest commit: fae3ccd 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 a new private package Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant CLI as CLI / scripts/init.js / commands.js
participant Config as scripts/modules/config-manager.js
participant Transformer as src/utils/rule-transformer.js
participant Profiles as `@tm/profiles` (getProfile / profile.addSlashCommands)
participant FS as Filesystem
CLI->>Config: getOperatingMode(explicitFlag?)
Config-->>CLI: resolved mode (solo|team)
CLI->>Transformer: convertAllRulesToProfileRules(projectRoot, profile, { mode })
Transformer->>Transformer: remove TaskMaster files for previous mode (cleanup)
Transformer->>Profiles: getProfile(profileName)
Profiles-->>Transformer: profile instance (or undefined)
alt profile supports commands
Transformer->>Profiles: addSlashCommands(projectRoot, commandsForMode)
Profiles->>FS: write command files (tm- namespace or flat)
FS-->>Profiles: write results (files list)
Profiles-->>Transformer: SlashCommandResult(success,count,files)
else no slash command support
Profiles-->>Transformer: null / undefined
end
Transformer->>FS: write converted rule files (mode-filtered)
FS-->>Transformer: write results
Transformer-->>CLI: conversion result / logs
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45–60 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (18)
tests/unit/profiles/rule-transformer-gemini.test.js (1)
24-36: Align subject under test with other cases in this fileThis suite is focused on
getRulesProfile('gemini'), but this test relies on the directly importedgeminiProfile. IfgetRulesProfileever decorates or clones the profile differently, this test could stop reflecting the actual runtime behavior while still passing.Consider changing it to:
- test('should have declarative slashCommands config', () => { - // Gemini has a slash command profile in @tm/profiles, so base-profile.js - // includes a declarative slashCommands config (execution handled by rule-transformer) - expect(geminiProfile.slashCommands).toBeDefined(); + test('should have declarative slashCommands config', () => { + const geminiProfile = getRulesProfile('gemini'); + + // Gemini has a slash command profile in @tm/profiles, so base-profile.js + // includes a declarative slashCommands config (execution handled by rule-transformer) + expect(geminiProfile.slashCommands).toBeDefined();and keep the remaining expectations against that local
geminiProfilefor consistency.packages/tm-profiles/src/slash-commands/commands/goham.ts (1)
14-343: Consider consistency: static command with argumentHint.This command uses
staticCommandbut includes anargumentHint: '[brief-url]'. While technically valid (staticCommand accepts optional argumentHint for metadata), this creates a design inconsistency:
- The signature suggests the command accepts a brief-url argument
- However, the content is entirely static and doesn't reference or use the argument
- Other commands that accept arguments use
dynamicCommandwith$ARGUMENTSplaceholderConsider either:
- Convert to
dynamicCommandand incorporate the brief-url into the workflow dynamically- Remove the
argumentHintif the content doesn't actually use the argumentThe workflow documentation itself is comprehensive and well-structured.
packages/tm-profiles/src/slash-commands/commands/convert-task-to-subtask.ts (1)
13-87: Align documented execution with canonical task move workflowThe dynamic command wiring and argument examples look good, but the Execution section documents
task-master add-subtask --parent=<parent-id> --task-id=<task-to-convert>, while the dev workflow guidelines describetask-master move --from=<id> --to=<id>as the standard way to move tasks between parent/standalone positions. To avoid drift and confusion, consider either:
- Updating the example to use the canonical
movecommand, or- Ensuring the CLI actually supports the documented
add-subtask --task-idconversion path and reflecting that consistently across docs.Based on learnings, the move command is the preferred mechanism for reorganizing tasks.
packages/tm-profiles/src/slash-commands/commands/to-cancelled.ts (1)
13-71: Clarify that this is a non-destructive status change, not deletionThe command correctly wires a status change via
set-status, but describing it as “Cancel a task permanently” can be read as destructive deletion. Consider rephrasing the short description to emphasize that this sets the task’s status tocancelledwhile preserving history (as detailed later in “Historical Preservation”), reinforcing the guidance to distinguish status changes from deletions.As per commands guidelines, it helps to clearly call out non-destructive alternatives.
packages/tm-profiles/src/slash-commands/commands/remove-subtask.ts (1)
13-100: Optionally document non-interactive confirmation flags for destructive removalThe remove-subtask command metadata and examples line up well with the CLI structure (required
--id, optional--convert). Since this is a destructive operation and you already show an interactive “Confirm deletion? (y/n)” flow, consider also documenting any--yes/-ystyle flag the CLI supports to skip confirmation, so slash-command users understand both interactive and non-interactive modes.As per commands guidelines, destructive commands typically surface both confirmation prompts and explicit “yes” flags.
packages/tm-profiles/src/slash-commands/profiles/gemini-profile.ts (1)
25-50: Use BaseSlashCommandProfile’s placeholder transformer for Gemini contentRooProfile and other profiles delegate through
transformArgumentPlaceholderso any present/future mapping of$ARGUMENTSto profile-specific placeholders stays centralized. GeminiProfile currently embedscommand.content.trim()directly, so it would miss any such transformation.You can keep behavior consistent by routing the content through the base helper:
- export class GeminiProfile extends BaseSlashCommandProfile { + export class GeminiProfile extends BaseSlashCommandProfile { @@ - format(command: SlashCommand): FormattedSlashCommand { - const description = this.escapeForPython(command.metadata.description); - const content = command.content.trim(); + format(command: SlashCommand): FormattedSlashCommand { + const description = this.escapeForPython(command.metadata.description); + const rawContent = command.content.trim(); + const content = this.transformArgumentPlaceholder(rawContent); @@ - content: `description="${description}" + content: `description="${description}" prompt = """ ${content} """ `This keeps Gemini in sync with any shared placeholder behavior across profiles.
packages/tm-profiles/tsconfig.json (1)
2-35: Consider settingrootDirtosrcto match included sourcesRight now
rootDiris"."but onlysrc/**/*is included. If you ever runtscdirectly (in addition to tsdown), this will make the emitted structure treat the whole package as the root rather than thesrctree. AligningrootDirwith the included sources makes the emit layout clearer and matches the usual internal package pattern:- "rootDir": ".", + "rootDir": "./src",Not mandatory for tsdown-only builds, but it improves consistency and avoids surprises if tsc is used.
packages/tm-profiles/src/slash-commands/profiles/roo-profile.spec.ts (1)
6-366: MakegetCommandsPathtests OS-agnostic by usingpath.joinin expectationsThe RooProfile behavior uses
path.joinunder the hood, but the tests currently assert hard-coded POSIX-style strings. This can break on non-POSIX environments even if the implementation is correct. You can make the tests portable by usingpath.joinin the expectations as well:-import { describe, it, expect } from 'vitest'; +import { describe, it, expect } from 'vitest'; +import path from 'path'; @@ it('should return correct absolute path for commands directory', () => { @@ - const commandsPath = profile.getCommandsPath(projectRoot); - - // Assert - expect(commandsPath).toBe('/home/user/my-project/.roo/commands'); + const commandsPath = profile.getCommandsPath(projectRoot); + + // Assert + expect(commandsPath).toBe( + path.join(projectRoot, '.roo/commands') + ); @@ it('should handle project root with trailing slash', () => { @@ - const commandsPath = profile.getCommandsPath(projectRoot); - - // Assert - // path.join normalizes the path - expect(commandsPath).toBe('/home/user/my-project/.roo/commands'); + const commandsPath = profile.getCommandsPath(projectRoot); + + // Assert + // path.join normalizes the path + expect(commandsPath).toBe( + path.join(projectRoot, '.roo/commands') + );This preserves current behavior on POSIX systems while avoiding false negatives on other platforms.
packages/tm-profiles/src/slash-commands/commands/expand-task.ts (1)
25-29: Consider documenting optional flags for the expand command.Per project conventions,
expandsupports flags like--force(to replace existing subtasks),--research(for enhanced AI analysis),--num, and--prompt. These could be helpful to document for users invoking this command.## Execution \`\`\`bash task-master expand --id=$ARGUMENTS \`\`\` + +## Options + +- Add \`--force\` to replace existing subtasks +- Add \`--research\` for enhanced AI analysis +- Add \`--num=<count>\` to specify subtask count +- Add \`--prompt="<text>"\` for custom expansion guidancepackages/tm-profiles/src/slash-commands/commands/install-taskmaster.ts (2)
115-125: Hardcoded version numbers will become stale.Line 119 references "Task Master v0.16.2" which will become outdated. Consider using a placeholder like "vX.Y.Z (or higher)" or removing the specific version to avoid maintenance burden.
108-113: Update the hardcoded nvm install script to reference the current version instead of v0.39.0.The nvm version referenced (v0.39.0) is outdated—the current latest version as of November 2025 is v0.40.3. Consider either updating the URL to use the latest version, or removing the specific version pin so users always get the current version:
# Instead of pinning v0.39.0 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # Use latest or current version curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/$(curl -s https://api.github.com/repos/nvm-sh/nvm/releases/latest | grep tag_name | cut -d '"' -f 4)/install.sh | bashAlternatively, update to v0.40.3 directly.
tests/integration/profiles/cursor-init-functionality.test.js (1)
68-81: Conditional assertion may mask failures.The test on lines 73-76 uses a conditional check
if (cursorProfile.slashCommands)which effectively makes the slashCommands assertions optional. If the slash commands integration fails to load, this test will pass silently without verifying the expected behavior.Consider either:
- Making the slashCommands check unconditional if it's a required feature
- Adding an explicit assertion about the expected state (e.g.,
expect(cursorProfile.slashCommands).toBeDefined()orexpect(cursorProfile.slashCommands).toBeUndefined())The assertions on lines 79-80 for the absence of lifecycle hooks are valuable and correctly unconditional.
packages/tm-profiles/src/slash-commands/profiles/roo-profile.ts (1)
55-66: Frontmatter spacing is off vs. comment; consider tightening
buildFrontmattercurrently pushes'---', '', '', which produces two blank lines after the closing---, while the comment says it should add “a blank line before content.” If you want a single blank line, you can drop one empty string and align the comment and behavior.- // Add closing --- and two empty strings to produce "---\n\n" (blank line before content) - lines.push('---', '', ''); + // Add closing --- and a single blank line before content + lines.push('---', '');If descriptions/argument hints ever include more complex characters, you may also want to quote/escape those values in a follow-up, but that can be deferred.
packages/tm-profiles/src/slash-commands/profiles/cursor-profile.spec.ts (1)
312-335: Usepath.joinfor expected commands path to avoid OS-specific assumptionsThe
getCommandsPathtests currently compare against hard-coded POSIX-style paths, which will break on Windows or any environment with different separators. You can keep the behavior checks while making the expectations portable:-import { describe, expect, it } from 'vitest'; -import { CursorProfile } from './cursor-profile.js'; -import { staticCommand, dynamicCommand } from '../factories.js'; +import { describe, expect, it } from 'vitest'; +import { CursorProfile } from './cursor-profile.js'; +import { staticCommand, dynamicCommand } from '../factories.js'; +import * as path from 'node:path'; @@ - it('should return correct absolute path for commands directory with tm subdirectory', () => { + it('should return correct absolute path for commands directory with tm subdirectory', () => { @@ - // Assert - Cursor supports nested commands, so path includes tm/ subdirectory - expect(commandsPath).toBe('/home/user/my-project/.cursor/commands/tm'); + // Assert - Cursor supports nested commands, so path includes tm/ subdirectory + expect(commandsPath).toBe( + path.join(projectRoot, '.cursor/commands/tm') + ); @@ - it('should handle project root with trailing slash', () => { + it('should handle project root with trailing slash', () => { @@ - // Assert - path.join normalizes the path, includes tm/ subdirectory - expect(commandsPath).toBe('/home/user/my-project/.cursor/commands/tm'); + // Assert - path.join normalizes the path, includes tm/ subdirectory + expect(commandsPath).toBe( + path.join(projectRoot, '.cursor/commands/tm') + );This keeps the intent while following the cross-platform path-handling guidance. As per coding guidelines, use
path.join()for path construction.packages/tm-profiles/src/slash-commands/profiles/codex-profile.ts (1)
86-96: Missing YAML value escaping for special characters.If
command.metadata.descriptionorcommand.metadata.argumentHintcontains double quotes, newlines, or other YAML special characters, the generated frontmatter will be malformed. Consider escaping these values or using a YAML library.private buildFrontmatter(command: SlashCommand): string { - const lines = ['---', `description: "${command.metadata.description}"`]; + const escapedDescription = command.metadata.description.replace(/"/g, '\\"'); + const lines = ['---', `description: "${escapedDescription}"`]; // Include argument-hint if present if (command.metadata.argumentHint) { - lines.push(`argument-hint: "${command.metadata.argumentHint}"`); + const escapedHint = command.metadata.argumentHint.replace(/"/g, '\\"'); + lines.push(`argument-hint: "${escapedHint}"`); } lines.push('---', ''); return lines.join('\n'); }packages/tm-profiles/tests/integration/claude-profile.integration.test.ts (1)
29-44: Remove unnecessaryasynckeyword from synchronous test.This test function is marked
asyncbut contains noawaitexpressions. TheaddSlashCommandsmethod is synchronous.-it('should create the .claude/commands/tm directory (nested structure)', async () => { +it('should create the .claude/commands/tm directory (nested structure)', () => {The same applies to several other tests in this file (lines 46, 166, 208, 246, 268, 292, 308, 366, 391, 416).
tests/unit/profiles/cursor-integration.test.js (1)
33-40: Mock profile missing required properties from BaseSlashCommandProfile.The mock profile is missing
extension,supportsNestedCommands,format, andformatAllmethods that are part ofBaseSlashCommandProfile. While this may work for current tests, it could cause issues if tests are extended.const mockProfile = { name: 'cursor', displayName: 'Cursor', commandsDir: '.cursor/commands', + extension: '.md', supportsCommands: true, + supportsNestedCommands: true, addSlashCommands: mockAddSlashCommands, - removeSlashCommands: mockRemoveSlashCommands + removeSlashCommands: mockRemoveSlashCommands, + format: jest.fn(), + formatAll: jest.fn() };packages/tm-profiles/src/slash-commands/profiles/base-profile.ts (1)
168-214: Consider adding file encoding parameter.The
writeFileSynccall (line 195) doesn't specify encoding, which defaults to'utf8'in Node.js when writing strings. This is correct behavior, but being explicit improves clarity.for (const output of formatted) { const filePath = path.join(commandsPath, output.filename); - fs.writeFileSync(filePath, output.content); + fs.writeFileSync(filePath, output.content, 'utf8'); files.push(output.filename); }
|
|
||
| Quick test: Run \`/project:help\` to see all available commands.` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the slash command prefix pattern used across command files
rg -n '/(project|taskmaster):' packages/tm-profiles/src/slash-commands/commands/ -A 2 -B 2Repository: eyaltoledano/claude-task-master
Length of output: 36869
Change /project:help to /taskmaster:help on line 37.
The slash command prefix across the codebase is /taskmaster:, not /project:. This is confirmed by the help.ts file which documents all commands using the /taskmaster: prefix (e.g., /taskmaster:init-project, /taskmaster:list-tasks, etc.). Update the reference to match the established pattern.
Quick test: Run \`/taskmaster:help\` to see all available commands.`
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/quick-install-taskmaster.ts
around lines 36 to 37, the help example uses the wrong slash command prefix
`/project:help`; update that literal to `/taskmaster:help` so it matches the
codebase convention (replace the string segment "Quick test: Run `/project:help`
to see all available commands." with "Quick test: Run `/taskmaster:help` to see
all available commands.").
| export const removeSubtasks = dynamicCommand( | ||
| 'remove-subtasks', | ||
| 'Remove Subtasks', | ||
| '<task-id>', | ||
| `Clear all subtasks from a specific task. | ||
|
|
||
| Arguments: $ARGUMENTS (task ID) | ||
|
|
||
| Remove all subtasks from a parent task at once. | ||
|
|
||
| ## Clearing Subtasks | ||
|
|
||
| Bulk removal of all subtasks from a parent task. | ||
|
|
||
| ## Execution | ||
|
|
||
| \`\`\`bash | ||
| task-master clear-subtasks --id=<task-id> | ||
| \`\`\` | ||
|
|
||
| ## Pre-Clear Analysis | ||
|
|
||
| 1. **Subtask Summary** | ||
| - Number of subtasks | ||
| - Completion status of each | ||
| - Work already done | ||
| - Dependencies affected | ||
|
|
||
| 2. **Impact Assessment** | ||
| - Data that will be lost | ||
| - Dependencies to be removed | ||
| - Effect on project timeline | ||
| - Parent task implications | ||
|
|
||
| ## Confirmation Required | ||
|
|
||
| \`\`\` | ||
| Clear Subtasks Confirmation | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| Parent Task: #5 "Implement user authentication" | ||
| Subtasks to remove: 4 | ||
| - #5.1 "Setup auth framework" (done) | ||
| - #5.2 "Create login form" (in-progress) | ||
| - #5.3 "Add validation" (pending) | ||
| - #5.4 "Write tests" (pending) | ||
|
|
||
| ⚠️ This will permanently delete all subtask data | ||
| Continue? (y/n) | ||
| \`\`\` | ||
|
|
||
| ## Smart Features | ||
|
|
||
| - Option to convert to standalone tasks | ||
| - Backup task data before clearing | ||
| - Preserve completed work history | ||
| - Update parent task appropriately | ||
|
|
||
| ## Process | ||
|
|
||
| 1. List all subtasks for confirmation | ||
| 2. Check for in-progress work | ||
| 3. Remove all subtasks | ||
| 4. Update parent task | ||
| 5. Clean up dependencies | ||
|
|
||
| ## Alternative Options | ||
|
|
||
| Suggest alternatives: | ||
| - Convert important subtasks to tasks | ||
| - Keep completed subtasks | ||
| - Archive instead of delete | ||
| - Export subtask data first | ||
|
|
||
| ## Post-Clear | ||
|
|
||
| - Show updated parent task | ||
| - Recalculate time estimates | ||
| - Update task complexity | ||
| - Suggest next steps | ||
|
|
||
| ## Example | ||
|
|
||
| \`\`\` | ||
| /taskmaster:clear-subtasks 5 | ||
| → Found 4 subtasks to remove | ||
| → Warning: Subtask #5.2 is in-progress | ||
| → Cleared all subtasks from task #5 | ||
| → Updated parent task estimates | ||
| → Suggestion: Consider re-expanding with better breakdown | ||
| \`\`\`` | ||
| ); |
There was a problem hiding this comment.
Fix command name inconsistency.
The command is registered as "remove-subtasks" but the help text documents the CLI command as "clear-subtasks" (lines 30, 96), which will fail when users try to execute it.
Apply this diff to align the help text with the actual command name:
`Clear all subtasks from a specific task.
Arguments: $ARGUMENTS (task ID)
Remove all subtasks from a parent task at once.
## Clearing Subtasks
Bulk removal of all subtasks from a parent task.
## Execution
\`\`\`bash
-task-master clear-subtasks --id=<task-id>
+task-master remove-subtasks --id=<task-id>
\`\`\`
## Pre-Clear AnalysisAnd also update the example:
## Example
\`\`\`
-/taskmaster:clear-subtasks 5
+/taskmaster:remove-subtasks 5
→ Found 4 subtasks to remove
→ Warning: Subtask #5.2 is in-progress
→ Cleared all subtasks from task #5🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/remove-subtasks.ts around
lines 13 to 103, the help text and examples refer to the CLI command as
"clear-subtasks" and show examples using that name, but the command is
registered as "remove-subtasks"; update all occurrences of "clear-subtasks"
(help sections, headings, CLI usage examples, confirmation block, and any inline
mentions) to "remove-subtasks" so the documented command name matches the actual
registered command and update the example invocation and confirmation text
accordingly.
packages/tm-profiles/src/slash-commands/profiles/claude-profile.spec.ts
Outdated
Show resolved
Hide resolved
| // Count how many directory levels we need to go up | ||
| const levels = relativePath.split('/').filter(Boolean).length; | ||
| let projectRoot = targetDir; | ||
| for (let i = 0; i < levels; i++) { | ||
| projectRoot = path.dirname(projectRoot); | ||
| } |
There was a problem hiding this comment.
Use cross-platform path separator.
Hardcoding "/" as the path separator will fail on Windows systems where paths use backslashes.
Apply this diff for cross-platform compatibility:
// Count how many directory levels we need to go up
- const levels = relativePath.split('/').filter(Boolean).length;
+ const levels = relativePath.split(path.sep).filter(Boolean).length;
let projectRoot = targetDir;
for (let i = 0; i < levels; i++) {
projectRoot = path.dirname(projectRoot);
}Based on coding guidelines requiring path.join() for cross-platform path construction.
📝 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.
| // Count how many directory levels we need to go up | |
| const levels = relativePath.split('/').filter(Boolean).length; | |
| let projectRoot = targetDir; | |
| for (let i = 0; i < levels; i++) { | |
| projectRoot = path.dirname(projectRoot); | |
| } | |
| // Count how many directory levels we need to go up | |
| const levels = relativePath.split(path.sep).filter(Boolean).length; | |
| let projectRoot = targetDir; | |
| for (let i = 0; i < levels; i++) { | |
| projectRoot = path.dirname(projectRoot); | |
| } |
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/utils.ts around lines 39 to 44, the
code splits relativePath using a hardcoded "/" which breaks on Windows;
normalize the path and split using Node's platform separator (e.g. const parts =
path.normalize(relativePath).split(path.sep).filter(Boolean)) and ensure any
path constructions use path.join()/path.resolve() instead of string
concatenation so projectRoot traversal using path.dirname remains
cross-platform.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.changeset/warm-things-shake.md (1)
1-13: Consider enhancing with feature details and usage examples.The changeset captures the basics but could be more comprehensive. Given this adds slash commands across five providers with ~40 new commands, consider enriching the description with:
- A brief explanation of what slash commands enable (e.g., IDE integration, AI assistant workflows)
- Feature benefits (e.g., faster task management from the editor)
- More detailed usage examples beyond just the installation command
Based on learnings, major feature additions like this tend to benefit from detailed changesets with comprehensive descriptions and examples rather than minimal summaries.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.changeset/warm-things-shake.md(1 hunks)
🧰 Additional context used
🧠 Learnings (19)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-11-24T18:05:23.901Z
Learning: Applies to assets/.claude/commands/*.md : Create custom slash commands in `.claude/commands/` as markdown files with clear step-by-step workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to new_features.mdc for guidelines on integrating new features into the Task Master CLI with tagged system considerations
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Create appropriate changesets for new features using semantic versioning (minor for new features); include tagged system information in release notes; document breaking changes
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Use `task-master init --rules cursor,windsurf` during initialization to specify which AI coding assistant rule sets to include
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-09-22T19:45:13.323Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1232
File: packages/build-config/package.json:14-15
Timestamp: 2025-09-22T19:45:13.323Z
Learning: In the eyaltoledano/claude-task-master repository, Crunchyman-ralph intentionally omits version fields from internal packages (like tm/build-config) to prevent changesets from releasing new versions for these packages. This is the desired behavior for internal tooling packages that should not be published or versioned independently.
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T17:58:19.853Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-11-24T17:58:19.853Z
Learning: Provide a concise, single-line changeset summary in imperative mood (e.g., 'Add feature X', 'Fix bug Y') that describes what changed from a user/consumer perspective, not implementation details
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:05:23.901Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-11-24T18:05:23.901Z
Learning: Applies to assets/.taskmaster/tasks/*.md : Run `task-master generate` to regenerate task markdown files from tasks.json after any manual changes
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T17:58:19.853Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-11-24T17:58:19.853Z
Learning: Do not create changesets for internal documentation updates in `.cursor/rules/`, trivial chores, non-impactful test updates, or local configuration changes that have no relevance to external consumers or public-facing documentation
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-08-02T14:54:52.216Z
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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.
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:05:23.901Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-11-24T18:05:23.901Z
Learning: Applies to assets/.taskmaster/config.json : Use `.taskmaster/config.json` for AI model configuration and only modify it using `task-master models` command, never manually edit
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T17:56:52.249Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/GEMINI.md:0-0
Timestamp: 2025-11-24T17:56:52.249Z
Learning: Applies to assets/.gemini/settings.json : Configure Task Master MCP server in ~/.gemini/settings.json with the command 'npx' and args ['-y', 'task-master-ai']
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to taskmaster.mdc for comprehensive reference of Taskmaster MCP tools and CLI commands with tagged task lists information
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Configure rule sets during initialization with `--rules` flag or manage them later with `task-master rules add/remove` commands
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: The Task Master CLI uses a modular architecture with distinct modules responsible for different aspects: commands.js (CLI command handling), task-manager.js (task data & core logic), dependency-manager.js (dependency management), ui.js (output formatting), ai-services-unified.js (unified AI service layer), config-manager.js (configuration management), utils.js (core utility functions), and mcp-server/ (MCP interface)
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Use `task-master rules add <profiles>` or `task-master rules remove <profiles>` to manage AI coding assistant rule sets after initialization
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:05:02.114Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/.windsurfrules:0-0
Timestamp: 2025-11-24T18:05:02.114Z
Learning: Use the global CLI command `task-master` instead of `node scripts/dev.js` for all task management operations
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:23.032Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/git_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:23.032Z
Learning: Use Task Master commands integrated with Git workflow: `task-master show`, `task-master next`, `task-master set-status`, `task-master update-subtask` to manage task context automatically based on current branch.
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Begin coding sessions with `task-master list` to see current tasks, status, and IDs
Applied to files:
.changeset/warm-things-shake.md
📚 Learning: 2025-11-24T18:05:02.114Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/.windsurfrules:0-0
Timestamp: 2025-11-24T18:05:02.114Z
Learning: Begin coding sessions with `task-master list` to review current tasks, status, and IDs
Applied to files:
.changeset/warm-things-shake.md
⏰ 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
Crunchyman-ralph
force-pushed
the
ralph/feat/add.slash.commands
branch
from
0765aa1 to
624df5e
Compare
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Nitpick comments (5)
packages/tm-profiles/src/slash-commands/commands/expand-task.ts (1)
17-66: Consider documenting optional flags for enhanced functionality.The help content is comprehensive and well-structured. However, based on learnings about the expand command, consider documenting additional optional flags that enhance task expansion:
--force: Replace existing subtasks--research: Enable enhanced expansion with research--num <count>: Control the number of subtasks generated--prompt <text>: Provide custom instructions for expansionThese flags would help users discover advanced capabilities. You could add an "Advanced Options" section after line 29:
task-master expand --id=$ARGUMENTS \`\`\` +## Advanced Options + +\`\`\`bash +# Force replace existing subtasks +task-master expand --id=$ARGUMENTS --force + +# Enhanced expansion with research +task-master expand --id=$ARGUMENTS --research + +# Control subtask count +task-master expand --id=$ARGUMENTS --num=5 + +# Custom expansion instructions +task-master expand --id=$ARGUMENTS --prompt="Focus on testing strategy" +\`\`\` + ## Expansion ProcessBased on learnings, these flags are actively used in the Task Master workflow.
packages/tm-profiles/src/slash-commands/commands/expand-all-tasks.ts (1)
24-26: Consider adding flag usage examples.The command syntax example shows the basic form, but users might benefit from seeing how to use the flags mentioned later in the documentation.
Consider adding examples like:
## Execution \`\`\`bash task-master expand --all + +# With flags: +task-master expand --all --force --research \`\`\`packages/tm-profiles/src/slash-commands/commands/help.ts (1)
23-114: Consider generating command list dynamically.The hardcoded command list requires manual updates when commands are added or removed, creating maintenance overhead and risk of stale documentation.
Consider refactoring to generate the command list dynamically from registered commands at runtime or build time. This could:
- Query the commands index for all available commands
- Group by category metadata
- Auto-generate the markdown list
This would eliminate synchronization issues between actual commands and help documentation.
packages/tm-profiles/src/slash-commands/commands/next-task.ts (1)
13-83: Consider adding test coverage for the command definition.According to the project's coding guidelines, TypeScript files must achieve minimum code coverage thresholds (80% lines/functions, 70% branches). While this is a static command definition, consider adding tests to verify:
- The command is properly registered and exported
- The $ARGUMENTS placeholder is correctly included
- The command metadata is accessible
Based on learnings, the project maintains comprehensive test coverage for all TypeScript modules.
packages/tm-profiles/src/slash-commands/commands/learn.ts (1)
115-116: Consider making the AI instruction more explicit.The bracket notation
[Specific command suggestion based on $ARGUMENTS]might be unclear for AI interpretation. Consider rephrasing to be more explicit, such as:-Based on what you asked about, try: -[Specific command suggestion based on $ARGUMENTS] +Based on what you asked about ($ARGUMENTS), suggest the most relevant command to try next.This makes it clearer to the AI assistant that it should generate a specific suggestion rather than potentially outputting the literal bracketed text.
packages/tm-profiles/src/slash-commands/commands/common/help.ts
Outdated
Show resolved
Hide resolved
| ## Task Master AI Command Help | ||
|
|
||
| ### Quick Navigation | ||
|
|
||
| Type \`/taskmaster:\` and use tab completion to explore all commands. | ||
|
|
||
| ### Command Categories | ||
|
|
||
| #### 🚀 Setup & Installation | ||
| - \`/taskmaster:install-taskmaster\` - Comprehensive installation guide | ||
| - \`/taskmaster:quick-install-taskmaster\` - One-line global install | ||
|
|
||
| #### 📋 Project Setup | ||
| - \`/taskmaster:init-project\` - Initialize new project | ||
| - \`/taskmaster:init-project-quick\` - Quick setup with auto-confirm | ||
| - \`/taskmaster:view-models\` - View AI configuration | ||
| - \`/taskmaster:setup-models\` - Configure AI providers | ||
|
|
||
| #### 🎯 Task Generation | ||
| - \`/taskmaster:parse-prd\` - Generate tasks from PRD | ||
| - \`/taskmaster:parse-prd-with-research\` - Enhanced parsing | ||
| - \`/taskmaster:generate-tasks\` - Create task files | ||
|
|
||
| #### 📝 Task Management | ||
| - \`/taskmaster:list-tasks\` - List all tasks | ||
| - \`/taskmaster:list-tasks-by-status\` - List tasks filtered by status | ||
| - \`/taskmaster:list-tasks-with-subtasks\` - List tasks with subtasks | ||
| - \`/taskmaster:show-task\` - Display task details | ||
| - \`/taskmaster:add-task\` - Create new task | ||
| - \`/taskmaster:update-task\` - Update single task | ||
| - \`/taskmaster:update-tasks-from-id\` - Update multiple tasks | ||
| - \`/taskmaster:next-task\` - Get next task recommendation | ||
|
|
||
| #### 🔄 Status Management | ||
| - \`/taskmaster:to-pending\` - Set task to pending | ||
| - \`/taskmaster:to-in-progress\` - Set task to in-progress | ||
| - \`/taskmaster:to-done\` - Set task to done | ||
| - \`/taskmaster:to-review\` - Set task to review | ||
| - \`/taskmaster:to-deferred\` - Set task to deferred | ||
| - \`/taskmaster:to-cancelled\` - Set task to cancelled | ||
|
|
||
| #### 🔍 Analysis & Breakdown | ||
| - \`/taskmaster:analyze-complexity\` - Analyze task complexity | ||
| - \`/taskmaster:complexity-report\` - View complexity report | ||
| - \`/taskmaster:expand-task\` - Break down complex task | ||
| - \`/taskmaster:expand-all-tasks\` - Expand all eligible tasks | ||
|
|
||
| #### 🔗 Dependencies | ||
| - \`/taskmaster:add-dependency\` - Add task dependency | ||
| - \`/taskmaster:remove-dependency\` - Remove dependency | ||
| - \`/taskmaster:validate-dependencies\` - Check for issues | ||
| - \`/taskmaster:fix-dependencies\` - Auto-fix dependency issues | ||
|
|
||
| #### 📦 Subtasks | ||
| - \`/taskmaster:add-subtask\` - Add subtask to task | ||
| - \`/taskmaster:convert-task-to-subtask\` - Convert task to subtask | ||
| - \`/taskmaster:remove-subtask\` - Remove subtask | ||
| - \`/taskmaster:remove-subtasks\` - Clear specific task subtasks | ||
| - \`/taskmaster:remove-all-subtasks\` - Clear all subtasks | ||
|
|
||
| #### 🗑️ Task Removal | ||
| - \`/taskmaster:remove-task\` - Remove task permanently | ||
|
|
||
| #### 🤖 Workflows | ||
| - \`/taskmaster:smart-workflow\` - Intelligent workflows | ||
| - \`/taskmaster:command-pipeline\` - Command chaining | ||
| - \`/taskmaster:auto-implement-tasks\` - Auto-implementation | ||
|
|
||
| #### 📊 Utilities | ||
| - \`/taskmaster:analyze-project\` - Project analysis | ||
| - \`/taskmaster:project-status\` - Project dashboard | ||
| - \`/taskmaster:sync-readme\` - Sync README with tasks | ||
| - \`/taskmaster:learn\` - Interactive learning | ||
| - \`/taskmaster:tm-main\` - Main Task Master interface | ||
|
|
||
| ### Quick Start Examples | ||
|
|
||
| \`\`\` | ||
| /taskmaster:list-tasks | ||
| /taskmaster:show-task 1.2 | ||
| /taskmaster:add-task | ||
| /taskmaster:next-task | ||
| \`\`\` | ||
|
|
||
| ### Getting Started | ||
|
|
||
| 1. Install: \`/taskmaster:quick-install-taskmaster\` | ||
| 2. Initialize: \`/taskmaster:init-project-quick\` | ||
| 3. Learn: \`/taskmaster:learn\` | ||
| 4. Work: \`/taskmaster:smart-workflow\` | ||
|
|
||
| For detailed command info, run the specific command with \`--help\` or check command documentation.` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Get the actual list of command files in the commands directory
echo "=== Actual command files in directory ==="
cd packages/tm-profiles/src/slash-commands/commands/ 2>/dev/null && ls -1 *.ts | sed 's/\.ts$//' | sort
cd - > /dev/null
# Extract commands from help text file
echo -e "\n=== Commands referenced in help.ts ==="
grep -oP '(?<=/taskmaster:)[a-z\-]+' packages/tm-profiles/src/slash-commands/commands/help.ts | sort -uRepository: eyaltoledano/claude-task-master
Length of output: 1547
Remove or implement /taskmaster:generate-tasks command.
The help text references /taskmaster:generate-tasks, but no corresponding implementation file exists in the commands directory. Either implement this command or remove it from the help documentation.
packages/tm-profiles/src/slash-commands/commands/solo/install-taskmaster.ts
Outdated
Show resolved
Hide resolved
| Try: /project:task-master:init your-prd.md | ||
| \`\`\` | ||
|
|
||
| ## Next Steps | ||
|
|
||
| After installation: | ||
| 1. Run \`/project:utils:check-health\` to verify setup | ||
| 2. Configure AI providers with \`/project:task-master:models\` | ||
| 3. Start using Task Master commands!` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify slash command references exist with correct naming format
echo "Searching for referenced slash commands..."
# Search for project:task-master:init pattern
echo -e "\n=== Searching for 'project:task-master:init' ==="
rg -n "project:task-master:init" --type=ts --type=js -C2
# Search for project:utils:check-health pattern
echo -e "\n=== Searching for 'project:utils:check-health' ==="
rg -n "project:utils:check-health" --type=ts --type=js -C2
# Search for project:task-master:models pattern
echo -e "\n=== Searching for 'project:task-master:models' ==="
rg -n "project:task-master:models" --type=ts --type=js -C2
# List all command files and their names
echo -e "\n=== Command files in tm-profiles ==="
fd -e ts "packages/tm-profiles/src/slash-commands/commands/" | sort
# Check command name definitions - look for 'name:' field
echo -e "\n=== Command names defined in files ==="
rg -n "name:\s*['\"]" packages/tm-profiles/src/slash-commands/commands/ --type=ts | head -30Repository: eyaltoledano/claude-task-master
Length of output: 4329
🏁 Script executed:
#!/bin/bash
# Description: Verify slash command routing and syntax conventions
echo "=== Searching for slash command router/parser ==="
rg -n "project:" packages/tm-profiles/ --type=ts -B2 -A2 | head -40
echo -e "\n=== Checking for slash command documentation ==="
find packages/tm-profiles -name "*.md" -o -name "README*" | head -10
echo -e "\n=== Searching for how /project commands are parsed ==="
rg -n "/project" packages/tm-profiles/src/ --type=ts -B1 -A1 | grep -E "(handler|parse|route)" | head -20
echo -e "\n=== Check command metadata/aliases ==="
rg -n "aliases|namespace" packages/tm-profiles/src/slash-commands/commands/ --type=ts | head -20
echo -e "\n=== Search for task-master:init, utils:check-health, task-master:models definitions ==="
rg -n "task-master:init|utils:check-health|task-master:models" packages/ --type=ts --type=jsRepository: eyaltoledano/claude-task-master
Length of output: 4478
🏁 Script executed:
#!/bin/bash
# Description: Check for slash command dispatcher and implementation
echo "=== Search for command dispatcher/handler ==="
rg -n "dispatch|handle.*command|invoke" packages/tm-profiles/src/ --type=ts -B2 -A2 | head -50
echo -e "\n=== Check index.ts for command routing ==="
cat -n packages/tm-profiles/src/slash-commands/commands/index.ts | head -60
echo -e "\n=== Check if commands directory has subdirectories for namespacing ==="
ls -la packages/tm-profiles/src/slash-commands/commands/
echo -e "\n=== Look for 'task-master' or 'utils' or 'workflows' subdirectories ==="
find packages/tm-profiles -type d -name "*task-master*" -o -type d -name "*utils*" -o -type d -name "*workflows*" 2>/dev/null | grep -v node_modules
echo -e "\n=== Check for .cursor/commands or similar for slash commands ==="
find packages/tm-profiles -type d -name "*commands*" | head -10Repository: eyaltoledano/claude-task-master
Length of output: 11201
Update command references to match actual implementation or document as planned features.
The slash commands referenced in lines 124-132 do not exist in their documented form. The documentation references /project:task-master:init, /project:utils:check-health, and /project:task-master:models, but the actual implemented commands use different names (e.g., init-project, setup-models). Either update the references to match the actual command names available in the current implementation, or clearly mark these as planned features not yet available.
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/install-taskmaster.ts around
lines 124 to 132, the README/help text references slash commands that don't
match the implemented names; update the command references to the actual
implemented commands (for example replace `/project:task-master:init` ->
`/project:init-project` and `/project:task-master:models` ->
`/project:setup-models`, and change `/project:utils:check-health` to the real
health-check command), or if those commands are not yet implemented, explicitly
annotate them as "planned" in the text; ensure the final copy uses the exact
command strings used by the codebase or labels them as future features so users
aren't misled.
| ## Enhanced Display | ||
|
|
||
| For the filtered results: | ||
| - Group by priority within the status | ||
| - Show time in current status | ||
| - Highlight tasks approaching deadlines | ||
| - Display blockers and dependencies | ||
| - Suggest next actions for each status group | ||
|
|
||
| ## Intelligent Insights | ||
|
|
||
| Based on the status filter: | ||
| - **Pending**: Show recommended start order | ||
| - **In-Progress**: Display idle time warnings | ||
| - **Done**: Show newly unblocked tasks | ||
| - **Review**: Indicate review duration | ||
| - **Deferred**: Show reactivation criteria | ||
| - **Cancelled**: Display impact analysis` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the CLI implementation directory structure
find . -type f -name "*.ts" -o -name "*.js" | grep -E "(cli|command)" | head -20Repository: eyaltoledano/claude-task-master
Length of output: 206
🏁 Script executed:
# Search for list command implementation
rg -n "list\s*(" --type=ts --type=js -A 10 | grep -E "(list|status|priority|deadline)" | head -30Repository: eyaltoledano/claude-task-master
Length of output: 141
🏁 Script executed:
# Look for the actual list command handler
ast-grep --pattern $'export $$$ list' --type tsRepository: eyaltoledano/claude-task-master
Length of output: 254
🏁 Script executed:
# Search for enhanced display features
rg -n "(groupBy|priority|deadline|blocker|idle.*time)" --type=ts --type=js | head -20Repository: eyaltoledano/claude-task-master
Length of output: 2183
🏁 Script executed:
# Find the list-tasks command implementation in the CLI
find . -type f -name "*.ts" -o -name "*.js" | xargs grep -l "list.*command\|export.*list" 2>/dev/null | head -10Repository: eyaltoledano/claude-task-master
Length of output: 533
🏁 Script executed:
# Look for the specific command file structure
find . -type d -name "*cli*" -o -name "*command*" 2>/dev/nullRepository: eyaltoledano/claude-task-master
Length of output: 2700
🏁 Script executed:
# Search for where status filtering is actually implemented
rg "status" --type ts -A 5 -B 5 2>/dev/null | grep -E "(status|filter|display)" | head -20Repository: eyaltoledano/claude-task-master
Length of output: 2419
🏁 Script executed:
# Check if there's documentation about what list command actually does
find . -name "*.md" -o -name "*.mdc" 2>/dev/null | xargs grep -l "list.*status\|status.*list" 2>/dev/nullRepository: eyaltoledano/claude-task-master
Length of output: 857
🏁 Script executed:
cat -n ./apps/cli/src/commands/list.command.tsRepository: eyaltoledano/claude-task-master
Length of output: 16676
🏁 Script executed:
cat -n ./packages/tm-profiles/src/slash-commands/commands/list-tasks-by-status.tsRepository: eyaltoledano/claude-task-master
Length of output: 1847
🏁 Script executed:
cat -n ./packages/claude-code-plugin/commands/list-tasks-by-status.mdRepository: eyaltoledano/claude-task-master
Length of output: 1316
Remove unimplemented features from the Enhanced Display and Intelligent Insights sections.
The documented features in lines 38-55 (priority grouping, time in current status, deadline highlights, idle time warnings, review duration, reactivation criteria, impact analysis) are not implemented in the underlying task-master list command. The actual CLI provides task statistics, priority breakdown, dependency information, and next task recommendations—but not the advanced time-tracking, deadline-alert, or status-specific insight features described. Either implement these features in the CLI or remove the aspirational documentation to avoid misleading users.
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/list-tasks-by-status.ts
around lines 38 to 55, the "Enhanced Display" and "Intelligent Insights"
sections list features not implemented by the underlying `task-master list`
command; remove any aspirational items (priority grouping by status,
time-in-status, deadline highlights, idle time warnings, review duration,
reactivation criteria, impact analysis, and any other unimplemented
status-specific insights) or replace them with only the actual supported outputs
(task statistics, priority breakdown, dependency information, next task
recommendations); update the doc text so it only describes features the CLI
currently provides to avoid misleading users.
| - \`/project:task-master:start [selected]\` | ||
| - \`/project:workflows:auto-implement\` | ||
| - \`/project:task-master:expand\` (if complex) | ||
| - \`/project:utils:complexity-report\` (if unsure) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for command definition files in the slash-commands directory
echo "Listing command files in packages/tm-profiles/src/slash-commands/commands/..."
fd -e ts packages/tm-profiles/src/slash-commands/commands/ --type f | sort
echo -e "\n\nSearching for command registrations or definitions containing the referenced command names..."
# Search for the command names in the codebase
rg -n "task-master:start|workflows:auto-implement|task-master:expand|utils:complexity-report" packages/tm-profiles/src/slash-commands/ -A 2 -B 2Repository: eyaltoledano/claude-task-master
Length of output: 2761
🏁 Script executed:
#!/bin/bash
# List command files using correct fd syntax
echo "Listing command files in commands directory..."
fd . 'packages/tm-profiles/src/slash-commands/commands/' --type f -e ts
echo -e "\n\nSearching for command definitions by name..."
rg -n "name:\s*['\"]start['\"]|name:\s*['\"]auto-implement['\"]|name:\s*['\"]expand['\"]|name:\s*['\"]complexity-report['\"]" packages/tm-profiles/src/slash-commands/ -B 5Repository: eyaltoledano/claude-task-master
Length of output: 3370
🏁 Script executed:
#!/bin/bash
# Check the index.ts to see command registrations
echo "Checking command registrations in index.ts..."
cat -n packages/tm-profiles/src/slash-commands/commands/index.ts | head -100
echo -e "\n\nSearching for 'start' command or 'begin' command..."
rg -n "start|begin" packages/tm-profiles/src/slash-commands/commands/ --type ts -i | grep -E "(name:|description:|export)" | head -20
echo -e "\n\nChecking dynamicCommand calls to see registered names..."
rg -n "dynamicCommand\(" packages/tm-profiles/src/slash-commands/commands/auto-implement-tasks.ts -A 3 | head -20
echo -e "\n\nChecking expand-task.ts..."
rg -n "dynamicCommand\(" packages/tm-profiles/src/slash-commands/commands/expand-task.ts -A 3 | head -20
echo -e "\n\nChecking complexity-report.ts..."
rg -n "dynamicCommand\(" packages/tm-profiles/src/slash-commands/commands/complexity-report.ts -A 3 | head -20Repository: eyaltoledano/claude-task-master
Length of output: 4826
🏁 Script executed:
#!/bin/bash
# Search for /project: prefix usage
echo "Searching for /project: prefix in codebase..."
rg -n "/project:" packages/tm-profiles/src/slash-commands/ -A 2 -B 2
echo -e "\n\nSearching for task execution or start functionality..."
rg -n "execute|start.*task|begin.*task" packages/tm-profiles/src/slash-commands/commands/ --type ts -i | head -30
echo -e "\n\nChecking next-task.ts to understand what command it recommends..."
cat -n packages/tm-profiles/src/slash-commands/commands/next-task.ts | sed -n '70,85p'Repository: eyaltoledano/claude-task-master
Length of output: 9551
🏁 Script executed:
#!/bin/bash
# Check to-in-progress command
echo "Checking to-in-progress command definition..."
cat -n packages/tm-profiles/src/slash-commands/commands/to-in-progress.ts | head -30
echo -e "\n\nSearching for command alias or mapping system..."
rg -n "alias|mapping|route" packages/tm-profiles/src/slash-commands/ --type ts -i | head -20
echo -e "\n\nChecking if there's a profile or CLI mapping for /project: prefix..."
fd . 'packages/tm-profiles' --type f -e ts -e json | xargs grep -l "project:" | head -10Repository: eyaltoledano/claude-task-master
Length of output: 1509
Remove reference to non-existent /project:task-master:start command.
The command /project:task-master:start does not exist in the codebase. The actual command for starting work on a task is to-in-progress. Either replace the reference with the correct command name or remove this line if the intended workflow does not require explicitly starting a task.
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/next-task.ts around lines 77
to 80, the list references a non-existent command `/project:task-master:start`;
replace that entry with the correct existing command
`/project:task-master:to-in-progress` (or remove the line if the workflow
shouldn't explicitly start tasks) so the documentation matches actual commands;
update the line text accordingly and run a quick grep to ensure no other docs
reference the removed name.
| export const projectStatus = dynamicCommand( | ||
| 'project-status', | ||
| 'Project Status', | ||
| '[focus-area]', | ||
| `Enhanced status command with comprehensive project insights. | ||
|
|
||
| Arguments: $ARGUMENTS | ||
|
|
||
| ## Intelligent Status Overview | ||
|
|
||
| ### 1. **Executive Summary** | ||
| Quick dashboard view: | ||
| - 🏃 Active work (in-progress tasks) | ||
| - 📊 Progress metrics (% complete, velocity) | ||
| - 🚧 Blockers and risks | ||
| - ⏱️ Time analysis (estimated vs actual) | ||
| - 🎯 Sprint/milestone progress | ||
|
|
||
| ### 2. **Contextual Analysis** | ||
|
|
||
| Based on $ARGUMENTS, focus on: | ||
| - "sprint" → Current sprint progress and burndown | ||
| - "blocked" → Dependency chains and resolution paths | ||
| - "team" → Task distribution and workload | ||
| - "timeline" → Schedule adherence and projections | ||
| - "risk" → High complexity or overdue items | ||
|
|
||
| ### 3. **Smart Insights** | ||
|
|
||
| **Workflow Health:** | ||
| - Idle tasks (in-progress > 24h without updates) | ||
| - Bottlenecks (multiple tasks waiting on same dependency) | ||
| - Quick wins (low complexity, high impact) | ||
|
|
||
| **Predictive Analytics:** | ||
| - Completion projections based on velocity | ||
| - Risk of missing deadlines | ||
| - Recommended task order for optimal flow | ||
|
|
||
| ### 4. **Visual Intelligence** | ||
|
|
||
| Dynamic visualization based on data: | ||
| \`\`\` | ||
| Sprint Progress: ████████░░ 80% (16/20 tasks) | ||
| Velocity Trend: ↗️ +15% this week | ||
| Blocked Tasks: 🔴 3 critical path items | ||
|
|
||
| Priority Distribution: | ||
| High: ████████ 8 tasks (2 blocked) | ||
| Medium: ████░░░░ 4 tasks | ||
| Low: ██░░░░░░ 2 tasks | ||
| \`\`\` | ||
|
|
||
| ### 5. **Actionable Recommendations** | ||
|
|
||
| Based on analysis: | ||
| 1. **Immediate actions** (unblock critical path) | ||
| 2. **Today's focus** (optimal task sequence) | ||
| 3. **Process improvements** (recurring patterns) | ||
| 4. **Resource needs** (skills, time, dependencies) | ||
|
|
||
| ### 6. **Historical Context** | ||
|
|
||
| Compare to previous periods: | ||
| - Velocity changes | ||
| - Pattern recognition | ||
| - Improvement areas | ||
| - Success patterns to repeat` | ||
| ); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify Task Master supports velocity tracking, metrics, and analytics features
echo "=== Checking for velocity/metrics/burndown implementation ==="
rg -i 'velocity|burndown|sprint.*progress|predictive.*analytic' --type ts packages/tm-core/src/ 2>/dev/null | head -20
echo ""
echo "=== Checking for complexity/bottleneck detection ==="
rg -i 'complexity.*metric|bottleneck|idle.*task' --type ts packages/tm-core/src/ 2>/dev/null | head -20
echo ""
echo "=== Checking Task Master CLI commands ==="
find apps/cli/src -name '*.ts' -type f | head -10
echo ""
echo "=== Checking for ContextGatherer usage in commands ==="
rg -n 'ContextGatherer' --type ts packages/ apps/ 2>/dev/null | head -20
echo ""
echo "=== Checking other slash command implementations ==="
find packages/tm-profiles/src/slash-commands/commands -name '*.ts' | head -10Repository: eyaltoledano/claude-task-master
Length of output: 1486
🏁 Script executed:
#!/bin/bash
# Examine existing slash command implementations
echo "=== analyze-complexity command ==="
cat packages/tm-profiles/src/slash-commands/commands/analyze-complexity.ts | head -100
echo ""
echo "=== analyze-project command ==="
cat packages/tm-profiles/src/slash-commands/commands/analyze-project.ts | head -100
echo ""
echo "=== Check for ContextGatherer imports across tm-profiles ==="
rg 'ContextGatherer|import.*context' --type ts packages/tm-profiles/src/ 2>/dev/null
echo ""
echo "=== Check dynamicCommand definition ==="
rg -A 20 'export.*function dynamicCommand' packages/tm-profiles/src/ --type ts 2>/dev/null | head -40Repository: eyaltoledano/claude-task-master
Length of output: 6265
🏁 Script executed:
#!/bin/bash
# Check for actual implementations of these features and understand the design intent
echo "=== Search for velocity/burndown/metrics in entire codebase ==="
rg -i 'velocity|burndown|sprint' --type ts packages/tm-core/src/ apps/cli/src/ 2>/dev/null || echo "No results found"
echo ""
echo "=== Search for complexity scoring implementation ==="
rg -i 'complexity.*score|score.*complexity' --type ts packages/ 2>/dev/null | head -15
echo ""
echo "=== Search for bottleneck/dependency analysis ==="
rg -i 'bottleneck|dependency.*graph|critical.*path' --type ts packages/ 2>/dev/null | head -15
echo ""
echo "=== Check how dynamicCommand is executed/processed ==="
rg -n 'dynamicCommand\|DynamicSlashCommand' --type ts packages/tm-profiles/src/ apps/cli/src/ 2>/dev/null | head -20
echo ""
echo "=== Check if there's any documentation about slash commands ==="
find . -name '*.md' -type f | xargs grep -l 'slash.*command\|dynamic.*command' 2>/dev/null | head -10Repository: eyaltoledano/claude-task-master
Length of output: 3642
🏁 Script executed:
#!/bin/bash
# Check documentation about slash commands and their intended use
echo "=== TM_COMMANDS_GUIDE content ==="
head -150 ./assets/claude/TM_COMMANDS_GUIDE.md
echo ""
echo "=== CLAUDE.md content ==="
cat ./.taskmaster/CLAUDE.md 2>/dev/null | head -80
echo ""
echo "=== Check for velocity implementation more thoroughly ==="
rg -i 'velocity\s|velocity:' --type ts packages/tm-core/src/ apps/cli/src/ 2>/dev/null || echo "No velocity metrics found"
echo ""
echo "=== Check validate-dependencies command ==="
grep -A 5 'Critical Path\|bottleneck' packages/tm-profiles/src/slash-commands/commands/validate-dependencies.ts | head -30Repository: eyaltoledano/claude-task-master
Length of output: 8313
Remove references to unimplemented features (velocity tracking, burndown, predictive analytics).
The command references several features that don't exist in Task Master's codebase: velocity metrics, burndown charts, sprint progress tracking, and predictive analytics. While the template correctly identifies supported features (complexity analysis, bottleneck detection, critical path analysis), it should not promise capabilities that cannot be delivered.
Issues:
-
Unsupported features referenced: Velocity trends, burndown projections, completion probability, and resource projection are not implemented.
-
Partial feature overlap: The template correctly references:
- Complexity analysis ✓ (implemented in complexity-report-manager)
- Bottleneck detection ✓ (validate-dependencies command)
- Critical path analysis ✓ (dependency module)
But incorrectly references:
- Velocity tracking ✗
- Sprint burndown ✗
- Predictive analytics ✗
- Time analysis (estimated vs actual) ✗
Recommendation:
Focus the template on demonstrable capabilities. Remove sections 1, 4, and 5 (Executive Summary with velocity/time metrics, Visual Intelligence with burndown charts, and Predictive Analytics). Expand sections 2 and 3 to showcase actual features: complexity scoring, dependency analysis, critical path identification, and risk assessment from the task graph.
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/project-status.ts around
lines 13 to 81, the command text advertises unimplemented features (velocity
tracking, burndown charts, predictive analytics, estimated vs actual time) and
visualizations; remove those sections and references (Executive Summary
velocity/time metrics, Visual Intelligence burndown visuals, Predictive
Analytics) and replace/expand the content to only describe implemented
capabilities: complexity scoring (complexity-report-manager), bottleneck
detection (validate-dependencies), critical path/dependency analysis, and
risk/overdue detection from the task graph; keep the command signature and
examples but rework sections 2 and 3 to highlight these supported features and
provide actionable recommendations based solely on them.
Organize slash commands into solo/team/common categories: - Solo: Local file storage commands (parse-prd, add-task, expand, etc.) - Team: Hamster cloud commands (goham) - Common: Shared commands (show-task, list-tasks, help, etc.) Both modes include common commands. When switching modes via `--mode=solo|team` flag, existing commands/rules are cleaned up before adding new ones to prevent orphaned files. Mode detection priority: 1. CLI flag (--mode=solo|team) 2. Config file (storage.operatingMode) 3. Auth status (authenticated = team, else solo) Changes: - Reorganize commands into solo/, team/, common/ directories - Add OperatingMode type and mode property to command metadata - Add filterCommandsByMode() for mode-based filtering - Add --mode flag to `tm rules` command - Add getOperatingMode() helper for auto-detection - Clean up old mode files when switching modes - Update base-profile to remove before add when mode specified
There was a problem hiding this comment.
Actionable comments posted: 13
♻️ Duplicate comments (7)
packages/tm-profiles/src/slash-commands/commands/common/project-status.ts (1)
13-81: Duplicate: Command references unimplemented features.As noted in the previous review, this command template promises features not present in the Task Master codebase (velocity tracking, burndown charts, sprint progress, predictive analytics, estimated vs. actual time analysis). The command should focus on implemented capabilities: complexity analysis, bottleneck detection, critical path analysis, and risk assessment.
packages/tm-profiles/src/slash-commands/commands/common/list-tasks-by-status.ts (1)
38-55: Remove unimplemented features from documentation.As noted in a previous review, the "Enhanced Display" and "Intelligent Insights" sections describe features not currently implemented by the underlying
task-master listcommand (priority grouping by status, time-in-status tracking, deadline highlights, idle time warnings, review duration, reactivation criteria, and impact analysis). Update the documentation to reflect only the features actually provided by the CLI.packages/tm-profiles/src/slash-commands/commands/common/help.ts (2)
13-22: Help text promises command-specific help filtering that doesn’t exist (per prior review).
This matches earlier feedback; either implement filtering or adjust the copy.
41-45: Help references/taskmaster:generate-taskswithout an implementation (per prior review).
Either add the command or remove it from the help list.packages/tm-profiles/src/slash-commands/commands/solo/install-taskmaster.ts (1)
119-119: Remove or dynamically reference the hardcoded version number.The hardcoded version "v0.16.2" at line 119 will become stale. Since the text already indicates "(or higher)", consider removing the specific version or using a dynamic reference from package.json.
packages/tm-profiles/src/slash-commands/commands/common/next-task.ts (1)
77-80: Remove or correct the non-existent command reference.The command
/project:task-master:startdoes not exist. Based on the past review, the correct command isto-in-progress. Update line 77 to reference the correct command or remove this line if not needed.packages/tm-profiles/src/slash-commands/profiles/codex-profile.spec.ts (1)
251-268: Don’t lock in invalid YAML output for quoted descriptions; assert escaping instead.
Right now the expectation matchesdescription: "Command with "quoted" text"which is not valid YAML and will mask the real formatter bug inCodexProfile.buildFrontmatter()(double-quoted values must escape internal"or switch to single quotes).- expect(result.content).toContain( - 'description: "Command with "quoted" text"' - ); + // Expect valid YAML (double quotes escaped) + expect(result.content).toContain( + 'description: "Command with \\"quoted\\" text"' + );
🧹 Nitpick comments (12)
packages/tm-profiles/src/slash-commands/profiles/base-profile.ts (1)
7-8: Consider using bare imports for Node.js core modules.Based on your stated preference, consider changing these imports from the
node:scheme to bare imports:-import * as fs from 'node:fs'; -import * as path from 'node:path'; +import * as fs from 'fs'; +import * as path from 'path';Based on learnings, you prefer not to use the
node:scheme for Node.js core modules.packages/tm-profiles/src/slash-commands/profiles/index.spec.ts (2)
26-91: Add explicit test for OpenCodeProfile.For consistency with the other profiles, add a dedicated test case for OpenCodeProfile in the "returns correct profile for valid names" section. Currently, OpenCodeProfile is only tested as part of the case insensitivity tests (line 136).
Apply this diff to add the missing test:
it('returns CodexProfile for "codex"', () => { // Arrange const name = 'codex'; // Act const profile = getProfile(name); // Assert expect(profile).toBeInstanceOf(CodexProfile); expect(profile?.name).toBe('codex'); expect(profile?.displayName).toBe('Codex'); }); + + it('returns OpenCodeProfile for "opencode"', () => { + // Arrange + const name = 'opencode'; + + // Act + const profile = getProfile(name); + + // Assert + expect(profile).toBeInstanceOf(OpenCodeProfile); + expect(profile?.name).toBe('opencode'); + expect(profile?.displayName).toBe('OpenCode'); + }); });
370-439: Add explicit instantiation test for OpenCodeProfile.For consistency with the other profiles, add a dedicated test case for OpenCodeProfile instantiation. Currently, OpenCodeProfile is only included in the array test (line 449) but doesn't have its own individual test like the other five profiles.
Apply this diff to add the missing test:
it('can instantiate GeminiProfile', () => { // Act const profile = new GeminiProfile(); // Assert expect(profile).toBeInstanceOf(GeminiProfile); expect(profile).toBeInstanceOf(BaseSlashCommandProfile); expect(profile.name).toBe('gemini'); expect(profile.displayName).toBe('Gemini'); expect(profile.commandsDir).toBe('.gemini/commands'); expect(profile.extension).toBe('.toml'); expect(profile.supportsCommands).toBe(true); }); + + it('can instantiate OpenCodeProfile', () => { + // Act + const profile = new OpenCodeProfile(); + + // Assert + expect(profile).toBeInstanceOf(OpenCodeProfile); + expect(profile).toBeInstanceOf(BaseSlashCommandProfile); + expect(profile.name).toBe('opencode'); + expect(profile.displayName).toBe('OpenCode'); + expect(profile.commandsDir).toBe('.opencode/command'); + expect(profile.extension).toBe('.md'); + expect(profile.supportsCommands).toBe(true); + }); it('all instantiated profiles extend BaseSlashCommandProfile', () => {packages/tm-profiles/src/slash-commands/commands/common/help.ts (1)
13-115: Consider making help mode-aware (or clearly labeling team-only commands).
Right now the help list reads like everything is always available; with mode filtering, users insolomay see commands they can’t use.packages/tm-profiles/src/slash-commands/commands/solo/view-models.ts (1)
1-68: LGTM: clean static command wiring and correctly scoped tomode: 'solo'.If you want to reduce staleness, consider marking the “Visual Status” block as an example explicitly (so it’s not mistaken for actual detected config).
scripts/modules/config-manager.js (1)
1210-1220: Global warning-suppression flag is racy under async interleaving.
Two overlapping calls can flip suppression off while the other still expects it on. Consider a refcount/token approach (increment/decrement), or confine suppression to a local code path instead ofglobal.*.packages/tm-profiles/src/slash-commands/commands/common/smart-workflow.ts (1)
13-72: Consider explicitly specifying the mode parameter.The command is located in the
common/folder but doesn't specify amodeparameter in thedynamicCommandcall. While this may default correctly, explicitly settingmodewould improve clarity and ensure the command is correctly categorized for filtering operations.export const smartWorkflow = dynamicCommand( 'smart-workflow', 'Smart Workflow', '[context]', `Execute an intelligent workflow based on current project state and recent commands. This command analyzes: 1. Recent commands you've run 2. Current project state 3. Time of day / day of week 4. Your working patterns Arguments: $ARGUMENTS ## Intelligent Workflow Selection Based on context, I'll determine the best workflow: ### Context Analysis - Previous command executed - Current task states - Unfinished work from last session - Your typical patterns ### Smart Execution If last command was: - \`status\` → Likely starting work → Run daily standup - \`complete\` → Task finished → Find next task - \`list pending\` → Planning → Suggest sprint planning - \`expand\` → Breaking down work → Show complexity analysis - \`init\` → New project → Show onboarding workflow If no recent commands: - Morning? → Daily standup workflow - Many pending tasks? → Sprint planning - Tasks blocked? → Dependency resolution - Friday? → Weekly review ### Workflow Composition I'll chain appropriate commands: 1. Analyze current state 2. Execute primary workflow 3. Suggest follow-up actions 4. Prepare environment for coding ### Learning Mode This command learns from your patterns: - Track command sequences - Note time preferences - Remember common workflows - Adapt to your style Example flows detected: - Morning: standup → next → start - After lunch: status → continue task -- End of day: complete → commit → status` +- End of day: complete → commit → status`, + 'common' );packages/tm-profiles/src/slash-commands/profiles/codex-profile.spec.ts (1)
120-127: Consider reducing brittleness of “exact full-document” string asserts.
A small internal formatting tweak (e.g., trailing newline) will cascade failures; you can keep the “exact” checks for 1–2 golden cases and usetoContain/toMatchfor the rest.Also applies to: 144-152, 206-213, 282-287, 303-312
packages/tm-profiles/src/slash-commands/commands/index.ts (2)
8-122:allCommandsas a hand-maintained list is easy to drift from reality.
If./solo/index.js,./team/index.js,./common/index.jscan export arrays (e.g.,soloCommands, …), prefer composingallCommands = [...soloCommands, ...teamCommands, ...commonCommands]to prevent “imported but not included” or “included twice” mistakes.
135-155: Mode filtering logic is correct; consider DRY + re-export surface check.
- The solo/team filter branches are identical aside from
'solo'|'team'—can be simplified.- Re-exporting everything from
solo/team/commonmay be broader than needed (repo tends to prefer minimal index exports).Also applies to: 157-166, 168-171
scripts/modules/commands.js (1)
4456-4464: Avoid recomputingmodeinside the profiles loops.
IfgetOperatingMode()reads config / does I/O / can prompt, calling it once per command invocation is safer and faster.- for (let i = 0; i < selectedRuleProfiles.length; i++) { + const mode = await getOperatingMode(options.mode); + for (let i = 0; i < selectedRuleProfiles.length; i++) { ... - const mode = await getOperatingMode(options.mode); const addResult = convertAllRulesToProfileRules( projectRoot, profileConfig, { mode } );- for (const profile of expandedProfiles) { + const mode = await getOperatingMode(options.mode); + for (const profile of expandedProfiles) { ... - const mode = await getOperatingMode(options.mode); const addResult = convertAllRulesToProfileRules( projectRoot, profileConfig, { mode } );Also applies to: 4533-4541
packages/tm-profiles/src/slash-commands/commands/common/to-in-progress.ts (1)
13-53: Looks good; consider aligning the example with the canonical CLI invocation.
If the preferred form istm set-status -i <id> -s in-progress(or similar), mirror that here to reduce user friction.
| export const learn = dynamicCommand( | ||
| 'learn', | ||
| 'Learn', | ||
| '[topic]', | ||
| `Learn about Task Master capabilities through interactive exploration. | ||
|
|
||
| Arguments: $ARGUMENTS | ||
|
|
||
| ## Interactive Task Master Learning | ||
|
|
||
| Based on your input, I'll help you discover capabilities: | ||
|
|
||
| ### 1. **What are you trying to do?** | ||
|
|
||
| If $ARGUMENTS contains: | ||
| - "start" / "begin" → Show project initialization workflows | ||
| - "manage" / "organize" → Show task management commands | ||
| - "automate" / "auto" → Show automation workflows | ||
| - "analyze" / "report" → Show analysis tools | ||
| - "fix" / "problem" → Show troubleshooting commands | ||
| - "fast" / "quick" → Show efficiency shortcuts | ||
|
|
||
| ### 2. **Intelligent Suggestions** | ||
|
|
||
| Based on your project state: | ||
|
|
||
| **No tasks yet?** | ||
| \`\`\` | ||
| You'll want to start with: | ||
| 1. /project:task-master:init <prd-file> | ||
| → Creates tasks from requirements | ||
|
|
||
| 2. /project:task-master:parse-prd <file> | ||
| → Alternative task generation | ||
|
|
||
| Try: /project:task-master:init demo-prd.md | ||
| \`\`\` | ||
|
|
||
| **Have tasks?** | ||
| Let me analyze what you might need... | ||
| - Many pending tasks? → Learn sprint planning | ||
| - Complex tasks? → Learn task expansion | ||
| - Daily work? → Learn workflow automation | ||
|
|
||
| ### 3. **Command Discovery** | ||
|
|
||
| **By Category:** | ||
| - 📋 Task Management: list, show, add, update, complete | ||
| - 🔄 Workflows: auto-implement, sprint-plan, daily-standup | ||
| - 🛠️ Utilities: check-health, complexity-report, sync-memory | ||
| - 🔍 Analysis: validate-deps, show dependencies | ||
|
|
||
| **By Scenario:** | ||
| - "I want to see what to work on" → \`/project:task-master:next\` | ||
| - "I need to break this down" → \`/project:task-master:expand <id>\` | ||
| - "Show me everything" → \`/project:task-master:status\` | ||
| - "Just do it for me" → \`/project:workflows:auto-implement\` | ||
|
|
||
| ### 4. **Power User Patterns** | ||
|
|
||
| **Command Chaining:** | ||
| \`\`\` | ||
| /project:task-master:next | ||
| /project:task-master:start <id> | ||
| /project:workflows:auto-implement | ||
| \`\`\` | ||
|
|
||
| **Smart Filters:** | ||
| \`\`\` | ||
| /project:task-master:list pending high | ||
| /project:task-master:list blocked | ||
| /project:task-master:list 1-5 tree | ||
| \`\`\` | ||
|
|
||
| **Automation:** | ||
| \`\`\` | ||
| /project:workflows:pipeline init → expand-all → sprint-plan | ||
| \`\`\` | ||
|
|
||
| ### 5. **Learning Path** | ||
|
|
||
| Based on your experience level: | ||
|
|
||
| **Beginner Path:** | ||
| 1. init → Create project | ||
| 2. status → Understand state | ||
| 3. next → Find work | ||
| 4. complete → Finish task | ||
|
|
||
| **Intermediate Path:** | ||
| 1. expand → Break down complex tasks | ||
| 2. sprint-plan → Organize work | ||
| 3. complexity-report → Understand difficulty | ||
| 4. validate-deps → Ensure consistency | ||
|
|
||
| **Advanced Path:** | ||
| 1. pipeline → Chain operations | ||
| 2. smart-flow → Context-aware automation | ||
| 3. Custom commands → Extend the system | ||
|
|
||
| ### 6. **Try This Now** | ||
|
|
||
| Based on what you asked about, try: | ||
| [Specific command suggestion based on $ARGUMENTS] | ||
|
|
||
| Want to learn more about a specific command? | ||
| Type: /project:help <command-name>` | ||
| ); |
There was a problem hiding this comment.
Consider normalizing the example slash-command namespaces for consistency.
The help text mixes /project:task-master:* + /project:workflows:* + /project:help while other commands in this package reference /taskmaster:*. If these are meant to be profile-specific aliases, it may be worth calling that out explicitly in the text; otherwise, align examples to the canonical namespace.
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/commands/common/learn.ts around lines
13 to 120, the help text mixes slash-command namespaces (/project:task-master:*,
/project:workflows:*, /project:help) while the rest of the package uses
/taskmaster:*, so either (A) normalize all example commands to the canonical
namespace (/taskmaster:...) for consistency across the package, or (B)
explicitly document at the top of the help text that /project:* prefixes are
profile-specific aliases and show both canonical and alias forms; update all
examples accordingly so namespaces are consistent and unambiguous.
| export const updateTask = dynamicCommand( | ||
| 'update-task', | ||
| 'Update Task', | ||
| '<update-spec>', | ||
| `Update tasks with intelligent field detection and bulk operations. | ||
|
|
||
| Arguments: $ARGUMENTS | ||
|
|
||
| ## Intelligent Task Updates | ||
|
|
||
| Parse arguments to determine update intent and execute smartly. | ||
|
|
||
| ### 1. **Natural Language Processing** | ||
|
|
||
| Understand update requests like: | ||
| - "mark 23 as done" → Update status to done | ||
| - "increase priority of 45" → Set priority to high | ||
| - "add dependency on 12 to task 34" → Add dependency | ||
| - "tasks 20-25 need review" → Bulk status update | ||
| - "all API tasks high priority" → Pattern-based update | ||
|
|
||
| ### 2. **Smart Field Detection** | ||
|
|
||
| Automatically detect what to update: | ||
| - Status keywords: done, complete, start, pause, review | ||
| - Priority changes: urgent, high, low, deprioritize | ||
| - Dependency updates: depends on, blocks, after | ||
| - Assignment: assign to, owner, responsible | ||
| - Time: estimate, spent, deadline | ||
|
|
||
| ### 3. **Bulk Operations** | ||
|
|
||
| Support for multiple task updates: | ||
| \`\`\` | ||
| Examples: | ||
| - "complete tasks 12, 15, 18" | ||
| - "all pending auth tasks to in-progress" | ||
| - "increase priority for tasks blocking 45" | ||
| - "defer all documentation tasks" | ||
| \`\`\` | ||
|
|
||
| ### 4. **Contextual Validation** | ||
|
|
||
| Before updating, check: | ||
| - Status transitions are valid | ||
| - Dependencies don't create cycles | ||
| - Priority changes make sense | ||
| - Bulk updates won't break project flow | ||
|
|
||
| Show preview: | ||
| \`\`\` | ||
| Update Preview: | ||
| ───────────────── | ||
| Tasks to update: #23, #24, #25 | ||
| Change: status → in-progress | ||
| Impact: Will unblock tasks #30, #31 | ||
| Warning: Task #24 has unmet dependencies | ||
| \`\`\` | ||
|
|
||
| ### 5. **Smart Suggestions** | ||
|
|
||
| Based on update: | ||
| - Completing task? → Show newly unblocked tasks | ||
| - Changing priority? → Show impact on sprint | ||
| - Adding dependency? → Check for conflicts | ||
| - Bulk update? → Show summary of changes | ||
|
|
||
| ### 6. **Workflow Integration** | ||
|
|
||
| After updates: | ||
| - Auto-update dependent task states | ||
| - Trigger status recalculation | ||
| - Update sprint/milestone progress | ||
| - Log changes with context | ||
|
|
||
| Result: Flexible, intelligent task updates with safety checks.` | ||
| ); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify implementation completeness, integration, and tag awareness
# 1. Check the full update-task.ts file to see actual implementation
echo "=== Full update-task.ts file ==="
cat -n packages/tm-profiles/src/slash-commands/commands/common/update-task.ts
# 2. Find dynamicCommand factory definition
echo -e "\n=== Searching for dynamicCommand factory ==="
rg -n --type=ts -B 3 -A 10 'export.*dynamicCommand|function dynamicCommand' --glob '**/*.ts' | head -100Repository: eyaltoledano/claude-task-master
Length of output: 11890
🏁 Script executed:
#!/bin/bash
# Verify task-manager.js integration and update functions
# 3. Check task-manager.js for update task implementations
echo "=== task-manager.js structure and functions ==="
fd --type f -name 'task-manager*' | head -20
# 4. List files in scripts/modules to understand architecture
echo -e "\n=== Files in scripts/modules ==="
find scripts/modules -type f -name '*.{js,ts}' 2>/dev/null | head -20Repository: eyaltoledano/claude-task-master
Length of output: 404
🏁 Script executed:
#!/bin/bash
# Check for tag awareness patterns and test coverage
# 5. Search for tag awareness implementation in update-task or related files
echo "=== Tag awareness in update-task vicinity ==="
rg -n --type=ts 'tag|Tag|currentTag|activeTag' packages/tm-profiles/src/slash-commands/commands/common/update-task.ts
# 6. Look for test files for update-task command
echo -e "\n=== Test files for update-task ==="
fd --type f '.*update.*task.*test\.' packages/tm-profiles/
# 7. Check how other commands handle integration
echo -e "\n=== Other commands in common directory ==="
ls -la packages/tm-profiles/src/slash-commands/commands/common/ | grep -E '\.ts$'Repository: eyaltoledano/claude-task-master
Length of output: 1576
🏁 Script executed:
#!/bin/bash
# Get the full dynamicCommand implementation and DynamicSlashCommand type definition
# Show full factories.ts file to see dynamicCommand implementation
echo "=== Full factories.ts file (first 150 lines) ==="
head -150 packages/tm-profiles/src/slash-commands/factories.ts
echo -e "\n=== Full factories.ts file (lines 75-120) ==="
sed -n '75,120p' packages/tm-profiles/src/slash-commands/factories.ts
# Check for DynamicSlashCommand type definition
echo -e "\n=== Searching for DynamicSlashCommand type ==="
rg -n --type=ts 'type DynamicSlashCommand|interface DynamicSlashCommand' packages/tm-profiles/Repository: eyaltoledano/claude-task-master
Length of output: 3019
🏁 Script executed:
#!/bin/bash
# Check where actual command implementations are - in profiles or elsewhere
# Look at BaseSlashCommandProfile to understand how commands are executed
echo "=== BaseSlashCommandProfile structure ==="
rg -n --type=ts -A 3 'class BaseSlashCommandProfile' packages/tm-profiles/src/slash-commands/
# Look for where command.content is actually used/executed
echo -e "\n=== Where command content is processed ==="
rg -n --type=ts 'command\.content|\.content' packages/tm-profiles/src/slash-commands/ | head -30Repository: eyaltoledano/claude-task-master
Length of output: 4091
🏁 Script executed:
#!/bin/bash
# Verify task-manager location and architecture
echo "=== Finding task-manager files ==="
find . -type f -name '*task-manager*' 2>/dev/null | head -20
echo -e "\n=== Finding where task CRUD operations are ==="
rg -n --type=ts --type=js 'readJSON.*task|writeJSON.*task|readTasks|writeTasks' --glob '**/*.{js,ts}' | head -20
echo -e "\n=== Check if this repo uses scripts/modules pattern ==="
ls -la scripts/ 2>/dev/null || echo "No scripts/ directory"Repository: eyaltoledano/claude-task-master
Length of output: 3596
🏁 Script executed:
#!/bin/bash
# Understand the prompt-based architecture
# Check one of the profiles to see how command content is used
echo "=== How profiles send commands to AI (roo-profile.ts excerpt) ==="
sed -n '30,60p' packages/tm-profiles/src/slash-commands/profiles/roo-profile.ts
# Look at a simpler command to understand the pattern
echo -e "\n=== Simpler command: to-done.ts ==="
cat packages/tm-profiles/src/slash-commands/commands/common/to-done.ts
# Check if there's a base system prompt or context
echo -e "\n=== Check for system prompts or base context ==="
rg -n --type=ts --type=js 'system.*prompt|base.*prompt|system.*context' packages/tm-profiles/src/ | head -20Repository: eyaltoledano/claude-task-master
Length of output: 2679
🏁 Script executed:
#!/bin/bash
# Verify tag awareness in similar commands and task-manager integration
echo "=== Check to-in-progress.ts for comparison ==="
cat packages/tm-profiles/src/slash-commands/commands/common/to-in-progress.ts
echo -e "\n=== Check if task-manager.js is called from profile or AI context ==="
rg -n 'task-manager' packages/tm-profiles/src/ --type=ts
echo -e "\n=== Look at task-manager.js structure for tag support ==="
head -50 scripts/modules/task-manager.jsRepository: eyaltoledano/claude-task-master
Length of output: 3454
🏁 Script executed:
#!/bin/bash
# Check test coverage for update-task related functionality
echo "=== Search for update-task test files ==="
find . -type f -name '*update-task*test*' 2>/dev/null
echo -e "\n=== Check test coverage requirements in coding guidelines ==="
rg -n 'coverage|80%|90%' .cursor/ 2>/dev/null || echo "No .cursor rules found"
echo -e "\n=== Check if there are integration tests for this command pattern ==="
fd -t f 'slash.*command.*test' packages/tm-profiles/ 2>/dev/null | head -10Repository: eyaltoledano/claude-task-master
Length of output: 3777
🏁 Script executed:
#!/bin/bash
# Final verification: Check if there are tests for the command files themselves
echo "=== Check if command files have corresponding tests ==="
find packages/tm-profiles -type f -name '*.spec.ts' -o -name '*.test.ts' | grep -i command
echo -e "\n=== Check how profiles are tested (as reference) ==="
ls -la packages/tm-profiles/src/slash-commands/profiles/*.spec.ts 2>/dev/null | head -5
echo -e "\n=== Check if update-task.ts or similar are tested in profiles tests ==="
rg -n 'update-task|updateTask' packages/tm-profiles/ --type=ts | grep -i test
echo -e "\n=== Verify the pattern: check if commands are tested as data objects or via profiles ==="
head -50 packages/tm-profiles/src/slash-commands/profiles/roo-profile.spec.tsRepository: eyaltoledano/claude-task-master
Length of output: 2737
🏁 Script executed:
#!/bin/bash
# Check if the command content adequately documents tag handling
echo "=== Check to-done.ts for any mention of tag/context handling ==="
grep -i 'tag\|context' packages/tm-profiles/src/slash-commands/commands/common/to-done.ts
echo -e "\n=== Check if other commands reference task-manager or tag ==="
rg -l 'task-manager|readJSON|writeJSON|tag.*context' packages/tm-profiles/src/slash-commands/commands/ | head -10
echo -e "\n=== Examine if update-task.ts should explicitly mention task-master CLI ==="
grep -n 'task-master' packages/tm-profiles/src/slash-commands/commands/common/to-done.tsRepository: eyaltoledano/claude-task-master
Length of output: 335
🏁 Script executed:
#!/bin/bash
# Compare command prompts to see the pattern difference
echo "=== to-done.ts FULL content for comparison ==="
cat packages/tm-profiles/src/slash-commands/commands/common/to-done.ts
echo -e "\n=== update-single-task.ts for additional comparison ==="
cat packages/tm-profiles/src/slash-commands/commands/common/update-single-task.ts
echo -e "\n=== Check what update-tasks-from-id.ts shows ==="
cat packages/tm-profiles/src/slash-commands/commands/common/update-tasks-from-id.tsRepository: eyaltoledano/claude-task-master
Length of output: 7215
Add execution guidance and concrete examples matching the pattern of peer update commands.
This command lacks the implementation clarity present in comparable update commands. update-single-task.ts shows task-master update-task --id=<id> --prompt="<context>" with concrete examples, while update-tasks-from-id.ts shows task-master update --from=<id> --prompt="<context>". By contrast, update-task.ts describes six feature categories (NLP, smart field detection, bulk operations, etc.) but provides no execution examples, argument format guidance, or actual task-master commands.
Add to the prompt:
- Explicit task-master CLI command(s) for update operations
- Argument parsing examples showing natural language to command mapping
- Concrete update examples with expected outputs
- Field-specific update syntax (priority, status, estimates, etc.)
- How bulk operations are scoped and executed
The current prompt is aspirational but leaves developers without clear implementation guidance on how updates are actually invoked.
🤖 Prompt for AI Agents
packages/tm-profiles/src/slash-commands/commands/common/update-task.ts lines
13-89: the prompt is too high-level and lacks concrete CLI usage, parsing
examples and expected outputs; update the prompt to include (1) explicit
task-master CLI command examples for single and bulk updates (e.g., --id,
--from, --prompt style) and a one-line synopsis for each, (2) argument parsing
examples showing natural-language inputs mapped to CLI flags and resulting
parsed intents, (3) concrete example requests and their expected
outputs/previews (showing tasks affected and resulting fields), (4)
field-specific syntax examples for status, priority, estimates, dependencies,
and assignment, and (5) a short explanation of how bulk scoping works (ranges,
filters, pattern matches) and how preview/confirm flow operates; keep the prompt
concise and formatted similarly to peer commands so implementers can copy
examples directly.
| describe('getCommandsPath() method', () => { | ||
| it('should return correct absolute path for commands directory with tm subdirectory', () => { | ||
| // Arrange | ||
| const profile = new GeminiProfile(); | ||
| const projectRoot = '/home/user/my-project'; | ||
|
|
||
| // Act | ||
| const commandsPath = profile.getCommandsPath(projectRoot); | ||
|
|
||
| // Assert | ||
| expect(commandsPath).toBe('/home/user/my-project/.gemini/commands/tm'); | ||
| }); | ||
|
|
||
| it('should handle project root with trailing slash', () => { | ||
| // Arrange | ||
| const profile = new GeminiProfile(); | ||
| const projectRoot = '/home/user/my-project/'; | ||
|
|
||
| // Act | ||
| const commandsPath = profile.getCommandsPath(projectRoot); | ||
|
|
||
| // Assert | ||
| // path.join normalizes the path | ||
| expect(commandsPath).toBe('/home/user/my-project/.gemini/commands/tm'); | ||
| }); | ||
|
|
||
| it('should handle Windows-style paths', () => { | ||
| // Arrange | ||
| const profile = new GeminiProfile(); | ||
| const projectRoot = 'C:\\Users\\user\\my-project'; | ||
|
|
||
| // Act | ||
| const commandsPath = profile.getCommandsPath(projectRoot); | ||
|
|
||
| // Assert | ||
| expect(commandsPath).toContain('.gemini'); | ||
| expect(commandsPath).toContain('commands'); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Make getCommandsPath() assertions platform-agnostic (avoid hardcoded POSIX paths).
Hardcoding '/home/user/my-project/.gemini/commands/tm' will break on Windows path separators (and potentially other path normalization differences). Prefer building expectations with path.join(...).
@@
-import { describe, expect, it } from 'vitest';
+import path from 'path';
+import { describe, expect, it } from 'vitest';
@@
it('should return correct absolute path for commands directory with tm subdirectory', () => {
@@
- expect(commandsPath).toBe('/home/user/my-project/.gemini/commands/tm');
+ expect(commandsPath).toBe(
+ path.join(projectRoot, '.gemini', 'commands', 'tm')
+ );
});
@@
it('should handle project root with trailing slash', () => {
@@
- expect(commandsPath).toBe('/home/user/my-project/.gemini/commands/tm');
+ expect(commandsPath).toBe(
+ path.join(projectRoot, '.gemini', 'commands', 'tm')
+ );
});🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/profiles/gemini-profile.spec.ts
around lines 529 to 567, the tests assert hardcoded POSIX paths which will fail
on Windows; change assertions to build expected paths with Node's path utilities
(e.g., path.join(projectRoot, '.gemini', 'commands', 'tm')) and use that for
equality checks (including the trailing-slash case) and for the Windows-style
test assert against a path.join-based expected value or use
path.normalize/contains checks; also ensure the test file imports/requires the
path module at the top.
| describe('unknown profile handling', () => { | ||
| it('returns undefined for unknown profile name', () => { | ||
| // Arrange | ||
| const unknownName = 'unknown-profile'; | ||
|
|
||
| // Act | ||
| const profile = getProfile(unknownName); | ||
|
|
||
| // Assert | ||
| expect(profile).toBeUndefined(); | ||
| }); | ||
|
|
||
| it('returns undefined for empty string', () => { | ||
| // Arrange | ||
| const emptyName = ''; | ||
|
|
||
| // Act | ||
| const profile = getProfile(emptyName); | ||
|
|
||
| // Assert | ||
| expect(profile).toBeUndefined(); | ||
| }); | ||
|
|
||
| it('returns undefined for profile with typo', () => { | ||
| // Arrange | ||
| const typoName = 'cusor'; // missing 'r' | ||
|
|
||
| // Act | ||
| const profile = getProfile(typoName); | ||
|
|
||
| // Assert | ||
| expect(profile).toBeUndefined(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Add edge case tests for null and undefined inputs.
The getProfile() function calls name.toLowerCase() without null/undefined checks, which would throw a TypeError if passed null or undefined. Add tests to verify this behavior or update the implementation to handle these edge cases gracefully.
Apply this diff to add edge case tests:
it('returns undefined for profile with typo', () => {
// Arrange
const typoName = 'cusor'; // missing 'r'
// Act
const profile = getProfile(typoName);
// Assert
expect(profile).toBeUndefined();
});
+
+ it('throws TypeError for null input', () => {
+ // Assert
+ expect(() => getProfile(null as any)).toThrow(TypeError);
+ });
+
+ it('throws TypeError for undefined input', () => {
+ // Assert
+ expect(() => getProfile(undefined as any)).toThrow(TypeError);
+ });
});Alternatively, if the function should handle null/undefined gracefully, update the implementation to check the input before calling toLowerCase().
🤖 Prompt for AI Agents
In packages/tm-profiles/src/slash-commands/profiles/index.spec.ts around lines
140 to 173, the test suite misses edge cases for null and undefined inputs which
will cause getProfile(name) to throw because the implementation calls
name.toLowerCase(); either add two tests asserting getProfile(null) and
getProfile(undefined) return undefined, or (preferable) update the
implementation in the profiles module to first guard against non-string inputs
(e.g., if (!name || typeof name !== 'string') return undefined) before calling
toLowerCase(), and then add corresponding tests verifying null and undefined
return undefined instead of throwing.
| /** | ||
| * Get the operating mode for rules/commands filtering. | ||
| * Priority order: | ||
| * 1. Explicit CLI flag (--mode=solo|team) | ||
| * 2. Config file (storage.operatingMode) | ||
| * 3. Auth status fallback (authenticated = team, else solo) | ||
| * | ||
| * @param {string|undefined} explicitMode - Mode passed via CLI flag | ||
| * @returns {Promise<'solo'|'team'>} The operating mode | ||
| */ | ||
| async function getOperatingMode(explicitMode) { | ||
| // 1. CLI flag takes precedence | ||
| if (explicitMode === 'solo' || explicitMode === 'team') { | ||
| return explicitMode; | ||
| } | ||
|
|
||
| // 2. Check config file for operatingMode | ||
| try { | ||
| setSuppressConfigWarnings(true); | ||
| const config = getConfig(null, false, { storageType: 'api' }); | ||
| if (config?.storage?.operatingMode) { | ||
| return config.storage.operatingMode; | ||
| } | ||
| } catch { | ||
| // Config check failed, continue to fallback | ||
| } finally { | ||
| setSuppressConfigWarnings(false); | ||
| } | ||
|
|
||
| // 3. Fallback: Check auth status | ||
| // If authenticated with Hamster, assume team mode | ||
| try { | ||
| const authManager = AuthManager.getInstance(); | ||
| const credentials = await authManager.getAuthCredentials(); | ||
| if (credentials) { | ||
| return 'team'; | ||
| } | ||
| } catch { | ||
| // Auth check failed, default to solo | ||
| } | ||
|
|
||
| // Default to solo mode | ||
| return 'solo'; | ||
| } |
There was a problem hiding this comment.
Validate config.storage.operatingMode and avoid leaking invalid values.
Suggested tightening:
const config = getConfig(null, false, { storageType: 'api' });
- if (config?.storage?.operatingMode) {
- return config.storage.operatingMode;
- }
+ const m = config?.storage?.operatingMode;
+ if (m === 'solo' || m === 'team') return m;🤖 Prompt for AI Agents
In scripts/modules/config-manager.js around lines 1193 to 1236, the function
returns config.storage.operatingMode without validating its value which can leak
invalid modes; ensure you only accept the string 'solo' or 'team' from the
config: after reading config, check that config.storage and
config.storage.operatingMode exist and that the value is exactly 'solo' or
'team' (and is a string); if it is valid return it, otherwise ignore it
(optionally log a suppressed warning) and continue to the auth/fallback logic so
only permitted modes propagate.
| // Import rule filtering | ||
| import { filterRulesByMode } from '../profiles/base-profile.js'; | ||
|
|
There was a problem hiding this comment.
Validate options.mode before filtering to avoid accidental mis-filtering.
Right now any non-null mode will trigger cleanup and filtering; if a caller passes an unexpected string, the behavior becomes surprising (and filterRulesByMode defaults to “solo” semantics). Consider a strict guard:
export function convertAllRulesToProfileRules(projectRoot, profile, options) {
const targetDir = path.join(projectRoot, profile.rulesDir);
- const mode = options?.mode;
+ const mode =
+ options?.mode === 'solo' || options?.mode === 'team' ? options.mode : undefined;Also applies to: 282-286
🤖 Prompt for AI Agents
In src/utils/rule-transformer.js around lines 27-29 (and similarly at lines
282-286), the code calls filterRulesByMode whenever options.mode is non-null
which risks mis-filtering on unexpected strings; add a strict guard that
validates options.mode against the allowed set of modes (e.g., 'solo', 'group',
or whatever the app defines) before performing cleanup/filtering, and only call
filterRulesByMode when options.mode is a recognized value; if options.mode is
present but invalid, skip filtering (or throw a clear error) to avoid silently
falling back to default semantics.
| /** | ||
| * Options for converting rules to profile rules | ||
| * @typedef {Object} ConvertRulesOptions | ||
| * @property {'solo' | 'team'} [mode] - Operating mode to filter rules | ||
| */ | ||
|
|
||
| /** | ||
| * Remove all TaskMaster rule files from a profile (used when switching modes) | ||
| * This removes files from ALL modes to ensure a clean slate. | ||
| * @param {string} projectRoot - The project root directory | ||
| * @param {Object} profile - The profile configuration | ||
| */ | ||
| function removeTaskMasterRuleFiles(projectRoot, profile) { | ||
| const targetDir = path.join(projectRoot, profile.rulesDir); | ||
|
|
||
| if (!fs.existsSync(targetDir)) { | ||
| return; // Nothing to remove | ||
| } | ||
|
|
||
| // Get all TaskMaster rule files (from all modes) | ||
| const allRuleFiles = Object.values(profile.fileMap); | ||
|
|
||
| for (const ruleFile of allRuleFiles) { | ||
| const filePath = path.join(targetDir, ruleFile); | ||
| if (fs.existsSync(filePath)) { | ||
| try { | ||
| fs.rmSync(filePath, { force: true }); | ||
| log('debug', `[Rule Transformer] Removed rule file: ${ruleFile}`); | ||
| } catch (error) { | ||
| log( | ||
| 'warn', | ||
| `[Rule Transformer] Failed to remove rule file ${ruleFile}: ${error.message}` | ||
| ); | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's read the rule-transformer.js file to understand the context
wc -l src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 108
🏁 Script executed:
# Read the full removeTaskMasterRuleFiles function and surrounding context
head -n 240 src/utils/rule-transformer.js | tail -n 100Repository: eyaltoledano/claude-task-master
Length of output: 3179
🏁 Script executed:
# Read lines 254-262 to see the rule file removal context
sed -n '254,262p' src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 395
🏁 Script executed:
# Read lines 380-407 to see the addSlashCommands context
sed -n '380,407p' src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 906
🏁 Script executed:
# Search for addSlashCommands implementation
rg -n "addSlashCommands" --type js -A 10 -B 2Repository: eyaltoledano/claude-task-master
Length of output: 15067
🏁 Script executed:
# Search for removeSlashCommands to see if it exists
rg -n "removeSlashCommands" --type jsRepository: eyaltoledano/claude-task-master
Length of output: 1753
🏁 Script executed:
# Search for slash commands related code to understand the structure
rg -n "slashCommands" src/utils/rule-transformer.js | head -20Repository: eyaltoledano/claude-task-master
Length of output: 372
🏁 Script executed:
# Read lines around 587 to see the context of removeSlashCommands
sed -n '575,600p' src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 832
🏁 Script executed:
# Get more context - read around line 587 with more surrounding lines
sed -n '550,610p' src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 1859
🏁 Script executed:
# Find the function name containing line 587
sed -n '500,587p' src/utils/rule-transformer.js | grep -E "^(export |)function|^(export |)async function" | tail -1Repository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Better approach - read from line 450 to find the function definition
sed -n '450,600p' src/utils/rule-transformer.js | head -80Repository: eyaltoledano/claude-task-master
Length of output: 2718
🏁 Script executed:
# Let me get the complete convertRules function - find where it starts
rg -n "function convertRules" src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Read the convertRules function completely
sed -n '240,450p' src/utils/rule-transformer.jsRepository: eyaltoledano/claude-task-master
Length of output: 6270
🏁 Script executed:
# Find where addSlashCommands is implemented
find . -name "*.js" -type f | xargs grep -l "function.*addSlashCommands\|addSlashCommands.*function" | grep -v test | grep -v node_modulesRepository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Look for addSlashCommands implementation in profiles
rg -n "addSlashCommands\s*:" src/profiles --type js -A 15Repository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Search more broadly for addSlashCommands implementations
rg -n "addSlashCommands" src --type js | grep -v "profile.slashCommands" | head -20Repository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Search for tests related to mode switching and slash commands
rg -n "mode.*slash\|slash.*mode" tests --type js -B 2 -A 5Repository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Look for profile implementations
find src -name "*.js" -path "*/profiles/*" -type f | grep -v testRepository: eyaltoledano/claude-task-master
Length of output: 434
🏁 Script executed:
# Check the cursor profile implementation
find . -name "*cursor*" -path "*/profiles*" -type js | head -5Repository: eyaltoledano/claude-task-master
Length of output: 109
🏁 Script executed:
# Read the cursor profile to understand slashCommands
cat -n src/profiles/cursor.js | head -150Repository: eyaltoledano/claude-task-master
Length of output: 549
🏁 Script executed:
# Search for slashCommands in the profiles
rg -n "slashCommands" src/profiles/*.js -B 2 -A 5 | head -100Repository: eyaltoledano/claude-task-master
Length of output: 1346
🏁 Script executed:
# Let's verify the exact structure and check if there are any tests showing the concern
rg -n "removeSlashCommands\|removeTaskMasterRuleFiles" src/utils/rule-transformer.js -B 2 -A 2Repository: eyaltoledano/claude-task-master
Length of output: 57
Remove orphaned slash commands when switching modes before adding new ones.
When you switch operating modes (e.g., team to solo), rule files are cleaned via removeTaskMasterRuleFiles() at line 255, but slash commands lack equivalent cleanup before addSlashCommands() is called at line 385. This allows stale mode-specific commands from the previous mode to remain. Since removeSlashCommands() is already available (used in removeProfileRules at line 587), add the same cleanup pattern before adding new commands:
// 5. Add slash commands (if profile supports them)
if (profile.slashCommands) {
try {
// Pass mode option for filtering commands by operating mode
const slashCommandOptions = mode ? { mode } : undefined;
+
+ // When switching modes, remove stale commands first to avoid orphans
+ if (mode) {
+ profile.slashCommands.profile.removeSlashCommands(
+ projectRoot,
+ profile.slashCommands.commands
+ );
+ }
+
const result = profile.slashCommands.profile.addSlashCommands(
projectRoot,
profile.slashCommands.commands,
slashCommandOptions
);Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In src/utils/rule-transformer.js around lines 203 to 239,
removeTaskMasterRuleFiles cleans up rule files when switching modes but slash
commands are not removed, allowing stale mode-specific commands to persist;
before calling addSlashCommands (where new commands are added, around line 385),
invoke the existing removeSlashCommands(projectRoot, profile) (or the
appropriate function signature) to delete orphaned slash commands first, ensure
removeSlashCommands is imported/available in this module, and wrap the call in a
try/catch with warnings logged on failure to match the existing cleanup error
handling.
c019841 to
82c4481
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.changeset/mode-filtering-slash-commands.md (1)
5-17: Consider adding a usage example for the --mode flag.The changeset provides good detail about the feature's behavior, but could be enhanced with a concrete usage example showing how users interact with the
--mode=solo|teamflag.For example, you could add:
The operating mode is auto-detected from config or auth status, and can be overridden with `--mode=solo|team` flag on the `rules` command. + +Example usage: +```bash +# Override to solo mode +task-master rules add cursor --mode=solo + +# Override to team mode +task-master rules add cursor --mode=team +```Based on learnings, eyaltoledano prefers detailed changesets with usage examples for major features.
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts (1)
211-281: Hardcoded command lists serve as validation but require maintenance.The explicit lists of solo commands (lines 213-240) and common commands (lines 251-272) provide valuable validation that specific commands are correctly categorized. However, these lists will need updating whenever commands are added or removed.
This is an acceptable trade-off as the tests serve double duty: runtime validation and documentation of expected categorization.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.changeset/mode-filtering-slash-commands.md(1 hunks)packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts(1 hunks)scripts/init.js(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- scripts/init.js
🧰 Additional context used
📓 Path-based instructions (5)
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds
Files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
**/*.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts}: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic
Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call
Do not add direct console.log calls outside the logging utility - use the central log function instead
Ensure silent mode is disabled in a finally block to prevent it from staying enabled
Do not access the global silentMode variable directly - use the exported silent mode control functions instead
Do not duplicate task ID formatting logic across modules - centralize formatting utilities
Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context
Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters
Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency
Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections
Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync
Include error handling for JSON file operations and validate JSON structure after reading
Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations
Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values
Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements
Files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
**/*.spec.ts
📄 CodeRabbit inference engine (CLAUDE.md)
Place package and app test files in
packages/<package-name>/src/<module>/<file>.spec.tsorapps/<app-name>/src/<module>/<file>.spec.tsalongside source files
Files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
**/*.{spec,test}.ts
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{spec,test}.ts: Always use.tsfor TypeScript tests, never.js
NEVER use async/await in test functions unless testing actual asynchronous operations; use synchronous top-level imports instead of dynamicawait import()
Files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Import modules with
.jsextension even in TypeScript source files for ESM compatibility
Files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
🧠 Learnings (24)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/git_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:23.032Z
Learning: Pull Request descriptions must include: Task Overview, Subtasks Completed (checklist), Implementation Details, Testing approach, Breaking Changes (if any), and Related Tasks.
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/**/*.{spec,test}.ts : In unit tests for apps/cli, mock tm-core responses but use real Commander/chalk/inquirer/other npm packages to test display logic
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to packages/tm-core/**/*.{spec,test}.ts : In unit tests for tm/core, mock only external I/O (Supabase, APIs, filesystem) and use real internal services
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing UI functions: mock console output and verify correct formatting; test conditional output logic; use `toContain()` or `toMatch()` rather than exact `toBe()` for strings with emojis or formatting; create separate tests for different behavior modes; test structure of formatted output rather than exact string matching.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to **/*.test.{js,ts} : Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/mcp/**/*.{spec,test}.ts : In unit tests for apps/mcp, mock tm-core responses but use real MCP framework to test response formatting
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.{spec,test}.ts : In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.test.ts : Unit tests must follow the describe/it pattern, use beforeEach for mock setup with jest.clearAllMocks(), include specific assertions with expect(), and test both success and error scenarios including edge cases
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/unit/**/*.test.js : Locate unit tests in `tests/unit/` directory. Test individual functions and utilities in isolation, mock all external dependencies, keep tests small and focused.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to package.json : package.json scripts must include: 'test', 'test:watch', 'test:coverage', 'test:unit', 'test:integration', 'test:e2e', and 'test:ci' commands for testing framework integration
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing console assertions: ensure assertion matches actual arguments passed; if code logs a single formatted string, assert against that single string using `expect.stringContaining` or exact match, not multiple arguments; verify exact behavior of the code being tested.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing exact error messages, don't assert on exact error message text that might change. Instead test for error presence and general properties using patterns like `toContain` or `toMatch`.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.ts : TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Avoid these common testing pitfalls: Don't test implementation details; Don't write brittle tests dependent on specific output formatting; Don't skip error handling and validation testing; Don't duplicate test fixtures across files; Don't write tests dependent on execution order; Don't define mock variables before jest.mock() calls.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/e2e/**/*.test.js : Locate end-to-end tests in `tests/e2e/` directory. Test complete workflows from a user perspective, focus on CLI commands as users would use them.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts
📚 Learning: 2025-08-02T14:54:52.216Z
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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.
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-07-17T21:33:57.585Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 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/mode-filtering-slash-commands.md
📚 Learning: 2025-09-22T19:45:04.337Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1232
File: packages/tm-core/package.json:50-51
Timestamp: 2025-09-22T19:45:04.337Z
Learning: In the eyaltoledano/claude-task-master project, Crunchyman-ralph intentionally omits version fields from internal/private packages in package.json files to prevent changesets from releasing new versions of these packages while still allowing them to be processed for dependency updates. The changesets warnings about missing versions are acceptable as they don't break the process and achieve the desired behavior of only releasing public packages.
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-09-22T19:45:13.323Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1232
File: packages/build-config/package.json:14-15
Timestamp: 2025-09-22T19:45:13.323Z
Learning: In the eyaltoledano/claude-task-master repository, Crunchyman-ralph intentionally omits version fields from internal packages (like tm/build-config) to prevent changesets from releasing new versions for these packages. This is the desired behavior for internal tooling packages that should not be published or versioned independently.
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-07-23T16:03:42.784Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1035
File: .changeset/quiet-rabbits-bathe.md:5-10
Timestamp: 2025-07-23T16:03:42.784Z
Learning: For changeset files (.changeset/*.md), avoid suggesting punctuation for bullet points as the project intentionally omits punctuation to make the generated changelog feel more natural.
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Configure rule sets during initialization with `--rules` flag or manage them later with `task-master rules add/remove` commands
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to new_features.mdc for guidelines on integrating new features into the Task Master CLI with tagged system considerations
Applied to files:
.changeset/mode-filtering-slash-commands.md
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Use `task-master rules add <profiles>` or `task-master rules remove <profiles>` to manage AI coding assistant rule sets after initialization
Applied to files:
.changeset/mode-filtering-slash-commands.md
🔇 Additional comments (1)
packages/tm-profiles/src/slash-commands/commands/mode-filtering.spec.ts (1)
1-312: LGTM! Comprehensive test coverage for mode-based filtering.The test suite is well-structured and thorough, covering:
- Solo and team mode filtering behavior
- Pre-filtered export validation
- Command mode categorization with explicit checks
- Edge cases (empty arrays, totals)
The tests follow project guidelines: synchronous execution, describe/it pattern, clear assertions, and comprehensive coverage of both success paths and edge cases.
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (1)
packages/tm-profiles/vitest.config.ts (1)
19-24: Nice: thresholds now match project minimumsThis addresses the prior “thresholds set to 0” concern and aligns with the repo’s stated minimums.
🧹 Nitpick comments (2)
.github/workflows/ci.yml (1)
23-45: (Optional) Consider caching npm’s download cache instead of node_modules
node_modulescaches tend to be large and more brittle; npm cache +npm ciper job is often more stable.packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts (1)
13-39: PATH guidance likely brittle (npm bin -g) — consider a more compatible snippet.Some npm versions/environments don’t support
npm bin -greliably; a more compatible approach is deriving the global prefix and appending its/bin. If you want to keep this bash-focused, a small tweak makes it more resilient.-2. Or add npm global bin to PATH: `export PATH=$(npm bin -g):$PATH` +2. Or add npm global bin to PATH (bash/zsh): + `export PATH="$(npm config get prefix)/bin:$PATH"`
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
.github/workflows/ci.yml(4 hunks)packages/tm-profiles/src/slash-commands/commands/common/help.ts(1 hunks)packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts(1 hunks)packages/tm-profiles/src/slash-commands/commands/solo/index.ts(1 hunks)packages/tm-profiles/src/slash-commands/commands/solo/install-taskmaster.ts(1 hunks)packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts(1 hunks)packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts(1 hunks)packages/tm-profiles/src/slash-commands/profiles/claude-profile.spec.ts(1 hunks)packages/tm-profiles/src/slash-commands/profiles/codex-profile.spec.ts(1 hunks)packages/tm-profiles/src/slash-commands/profiles/codex-profile.ts(1 hunks)packages/tm-profiles/src/slash-commands/utils.ts(1 hunks)packages/tm-profiles/tests/integration/codex-profile.integration.test.ts(1 hunks)packages/tm-profiles/vitest.config.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (7)
- packages/tm-profiles/src/slash-commands/utils.ts
- packages/tm-profiles/src/slash-commands/commands/common/help.ts
- packages/tm-profiles/src/slash-commands/profiles/codex-profile.ts
- packages/tm-profiles/src/slash-commands/commands/solo/install-taskmaster.ts
- packages/tm-profiles/src/slash-commands/profiles/codex-profile.spec.ts
- packages/tm-profiles/src/slash-commands/profiles/claude-profile.spec.ts
- packages/tm-profiles/tests/integration/codex-profile.integration.test.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds
Files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.tspackages/tm-profiles/vitest.config.ts
**/*.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts}: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic
Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call
Do not add direct console.log calls outside the logging utility - use the central log function instead
Ensure silent mode is disabled in a finally block to prevent it from staying enabled
Do not access the global silentMode variable directly - use the exported silent mode control functions instead
Do not duplicate task ID formatting logic across modules - centralize formatting utilities
Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context
Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters
Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency
Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections
Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync
Include error handling for JSON file operations and validate JSON structure after reading
Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations
Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values
Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements
Files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.tspackages/tm-profiles/vitest.config.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Import modules with
.jsextension even in TypeScript source files for ESM compatibility
Files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.tspackages/tm-profiles/vitest.config.ts
🧠 Learnings (74)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T17:58:47.030Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Follow the remove-subtask command structure with options: --id (required, format parentId.subtaskId, can be comma-separated), --convert (for converting to standalone task), --file, and --generate
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided structure for removing subtasks, including required options, conversion option, and detailed error handling.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided structure for adding subtasks, including required options and detailed error handling.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-11-24T17:58:47.030Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Follow the add-subtask command structure with proper options: --parent (required), --task-id, --title, --description, --details, --dependencies, --status, and --generate, with comprehensive parameter validation
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T18:02:36.388Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent properties for subtasks (id, title, description, status, dependencies, details) without duplicating parent task properties, maintaining simple numeric IDs unique within the parent task
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: The Task Master CLI uses a modular architecture with distinct modules responsible for different aspects: commands.js (CLI command handling), task-manager.js (task data & core logic), dependency-manager.js (dependency management), ui.js (output formatting), ai-services-unified.js (unified AI service layer), config-manager.js (configuration management), utils.js (core utility functions), and mcp-server/ (MCP interface)
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : For destructive commands (like remove-task or remove-subtask), include a confirmation prompt by default, provide a --yes/-y flag to skip confirmation, and show what will be deleted in the confirmation message.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T17:59:18.662Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-11-24T17:59:18.662Z
Learning: Applies to scripts/modules/dependency-manager.js : Check for and remove references to non-existent tasks and self-references during cleanup, tracking and reporting changes made during cleanup
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/task-manager.js : Data manipulation features (create, read, update, delete tasks) should be placed in `task-manager.js` and follow guidelines in `tasks.mdc`
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T18:02:36.388Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI within the current tag context (defaulting to "master"), providing clear prompts to guide AI task generation and validating/cleaning up AI-generated tasks
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Use snake_case for MCP tool names exposed to clients (e.g., list_tasks, set_task_status)
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/*.js : Use consistent file naming conventions: `task_${id.toString().padStart(3, '0')}.txt` for task files; use `path.join()` for composing paths; use appropriate extensions (.txt for tasks, .json for data)
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T17:58:47.030Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Use kebab-case for command names (e.g., 'analyze-complexity', 'remove-task') and action-oriented descriptions
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Use `/clear` command between different Task Master tasks in Claude Code to maintain focused context and conversation history
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-09-03T12:15:03.208Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: apps/cli/src/commands/auth.command.ts:222-224
Timestamp: 2025-09-03T12:15:03.208Z
Learning: The CLI can be invoked using both "task-master" and "tm" as aliases - both forms are valid and acceptable in help text, documentation, and examples.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-11-24T18:05:02.114Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/.windsurfrules:0-0
Timestamp: 2025-11-24T18:05:02.114Z
Learning: Use the global CLI command `task-master` instead of `node scripts/dev.js` for all task management operations
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: For subtask implementation, use `task-master show <subtaskId>` to understand goals, explore the codebase, determine code changes, then log the plan with `task-master update-subtask`
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-07-18T17:09:40.548Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:40.548Z
Learning: Applies to scripts/modules/dependency-manager.js : Allow numeric subtask IDs to reference other subtasks within the same parent
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
📚 Learning: 2025-09-09T19:13:55.652Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1194
File: .github/workflows/ci.yml:31-35
Timestamp: 2025-09-09T19:13:55.652Z
Learning: The claude-task-master project has only one package-lock.json file in the entire workspace (at the root level), so cache-dependency-path configuration is unnecessary for the npm cache in GitHub Actions.
Applied to files:
.github/workflows/ci.yml
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Run `npm run turbo:typecheck` before pushing to ensure TypeScript type checks pass
Applied to files:
.github/workflows/ci.yml
📚 Learning: 2025-11-24T18:02:22.305Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-11-24T18:02:22.305Z
Learning: The generate command must be manually run after making changes to tasks.json to keep individual task markdown files up to date; this no longer runs automatically
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Run `task-master generate` after manual changes to tasks.json to regenerate task markdown files
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-11-24T17:58:47.030Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Regenerate task files after destructive operations by explicitly passing all required parameters to generation functions; provide a --skip-generate option if needed
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-09-26T19:05:47.555Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/tasks/*.{txt,md} : Never manually edit task markdown files in `.taskmaster/tasks/*.txt` or `.taskmaster/tasks/*.md` - these are auto-generated from tasks.json and regenerated using `task-master generate`
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : Implement `async function yourCommandDirect(args, log)` with camelCase naming and Direct suffix; obtain tasksPath using `findTasksJsonPath(args, log)`; wrap core function calls with enableSilentMode/disableSilentMode; return formatted response with success/error and fromCache fields
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-11-24T18:02:36.388Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Format task files with consistent structure including task metadata (ID, title, status), dependencies with status indicators, and tag context information in the file header
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.tspackages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Regenerate task files after destructive operations, passing all required parameters to generation functions, and provide an option to skip regeneration if needed.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to scripts/modules/**/*.{js,ts} : Implement silent migration for tasks.json files that transforms old format to tagged format, marking global flag and performing complete migration
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/tasks/tasks.json : Store main task data in `.taskmaster/tasks/tasks.json` and never manually edit this file - use Task Master commands instead
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 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.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts
📚 Learning: 2025-10-08T19:57:00.982Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1282
File: packages/tm-core/src/utils/index.ts:16-34
Timestamp: 2025-10-08T19:57:00.982Z
Learning: For the tm-core package in the eyaltoledano/claude-task-master repository, the team prefers a minimal, need-based export strategy in index files rather than exposing all internal utilities. Exports should only be added when functions are actually consumed by other packages in the monorepo.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to mcp-server/src/core/task-master-core.js : Update `task-master-core.js` by importing and re-exporting direct functions and adding them to the directFunctions map
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to new_features.mdc for guidelines on integrating new features into the Task Master CLI with tagged system considerations
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-09-26T19:10:32.906Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: tsconfig.json:22-28
Timestamp: 2025-09-26T19:10:32.906Z
Learning: In the eyaltoledano/claude-task-master repository, all internal tm/ package path mappings in tsconfig.json consistently point to TypeScript source files (e.g., "./packages/*/src/index.ts") rather than built JavaScript. This is intentional architecture because tsdown bundles internal packages directly from source during build time, eliminating the need for separate compilation of internal packages.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.tspackages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T17:56:52.249Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/GEMINI.md:0-0
Timestamp: 2025-11-24T17:56:52.249Z
Learning: Applies to assets/.gemini/settings.json : Configure Task Master MCP server in ~/.gemini/settings.json with the command 'npx' and args ['-y', 'task-master-ai']
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to taskmaster.mdc for comprehensive reference of Taskmaster MCP tools and CLI commands with tagged task lists information
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-12-11T14:45:14.973Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Initialize Task Master in current project using `task-master init`
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-07-18T17:08:48.695Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided command template structure for all CLI commands using Commander.js, including use of .command(), .description(), .option(), and .action() methods.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Reference documentation at https://docs.task-master.dev, not local file paths
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-11-24T17:58:47.030Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Export the registerCommands function along with setupCLI, runCLI, checkForUpdate, compareVersions, and displayUpgradeNotification functions
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-07-18T21:57:56.681Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1011
File: scripts/modules/task-manager/models.js:29-30
Timestamp: 2025-07-18T21:57:56.681Z
Learning: The `task-master init` command creates the config.json file inside the .taskmaster directory, while `task-master models --setup` does not create this file. When the configuration file is missing, users should be directed to run `task-master init`.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts
📚 Learning: 2025-09-26T19:03:33.225Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: package.json:130-132
Timestamp: 2025-09-26T19:03:33.225Z
Learning: In the eyaltoledano/claude-task-master repository, packages are bundled using tsdown during the build process, which means dependencies imported by the source code (including tm internal packages like tm/ai-sdk-provider-grok-cli) are included in the final bundle and don't need to be available as separate runtime dependencies, so they should remain as devDependencies rather than being moved to dependencies.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to **/{utils,utilities}/**/*.{js,ts} : Export all utility functions explicitly in logical groups and include configuration constants from utility modules
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.tspackages/tm-profiles/vitest.config.ts
📚 Learning: 2025-09-17T19:28:51.486Z
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T17:59:00.056Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-11-24T17:59:00.056Z
Learning: Applies to scripts/modules/utils/{contextGatherer,fuzzyTaskSearch}.js : Export utility modules using named exports: `ContextGatherer`, `createContextGatherer` from contextGatherer.js and `FuzzyTaskSearch`, `PURPOSE_CATEGORIES`, `RELEVANCE_THRESHOLDS` from fuzzyTaskSearch.js
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:05:02.114Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/.windsurfrules:0-0
Timestamp: 2025-11-24T18:05:02.114Z
Learning: Start new projects with `task-master init` or `task-master parse-prd --input=<prd-file.txt>` to generate initial tasks.json
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Place utilities used primarily by the core task-master CLI logic and command modules into scripts/modules/utils.js
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to **/{utils,utilities}/**/*.{js,ts} : Implement reusable task finding utilities that support both task and subtask lookups and add context to subtask results
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:00:06.827Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Initialize projects using `task-master init` or `task-master parse-prd` to generate initial tasks.json with tagged structure
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: Applies to scripts/modules/utils.js : utils.js should provide core utility functions including logging (log function), file I/O (readJSON, writeJSON), string utilities (truncate), task utilities (findTaskById), dependency utilities (findCycles), API key resolution (resolveEnvVariable), silent mode control (enableSilentMode, disableSilentMode), and tagged task list support (migration system, tag resolution, current tag management)
Applied to files:
packages/tm-profiles/src/slash-commands/commands/solo/index.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to jest.config.js : Jest configuration must use ts-jest preset for TypeScript support, configure test environment as 'node', set roots to ['<rootDir>/src', '<rootDir>/tests'], and include testMatch patterns for both *.test.ts and *.spec.ts files with separate projects for unit, integration, and e2e tests
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to tests/setup.ts : Create global test setup file that configures jest.setTimeout(10000), clears all mocks after each test with jest.clearAllMocks(), and initializes global test configuration
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.ts : TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to packages/tm-core/**/*.{spec,test}.ts : In unit tests for tm/core, mock only external I/O (Supabase, APIs, filesystem) and use real internal services
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to tests/fixtures/**/*.ts : Test fixture files must export reusable test data creators and constants (createTestUser, adminUser, invalidUser, etc.) for use across unit, integration, and e2e tests to ensure consistency
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to **/*.test.{js,ts} : Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.{spec,test}.ts : In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.test.ts : Place package and app integration tests in `packages/<package-name>/tests/integration/<module>/<file>.test.ts` or `apps/<app-name>/tests/integration/<module>/<file>.test.ts`
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Test files must be organized with unit tests separate from integration and e2e tests using project configuration in jest.config.js to maintain clear test separation and different timeout/environment settings
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to src/utils/**/*.ts : Utility functions must achieve 90% statement coverage, 85% branch coverage, and 90% function coverage with tests covering all code paths, edge cases, null/undefined values, and error scenarios
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Test quality guidelines: Write tests before implementing features (TDD). Test edge cases and error conditions, not just happy paths. Keep tests independent and isolated. Use descriptive test names. Maintain test fixtures separately. Aim for 80%+ code coverage with critical paths at 100%.
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to src/middleware/**/*.ts : Middleware implementations must achieve 85% coverage for branches, functions, and lines with tests covering both success paths and error handling scenarios
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.{js,jsx} : JavaScript test files using Jest must follow the same testing patterns as TypeScript files, include proper mocking of external dependencies, and achieve the same coverage thresholds
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to package.json : package.json scripts must include: 'test', 'test:watch', 'test:coverage', 'test:unit', 'test:integration', 'test:e2e', and 'test:ci' commands for testing framework integration
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:01:52.739Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/self_improve.mdc:0-0
Timestamp: 2025-11-24T18:01:52.739Z
Learning: Monitor test patterns and coverage when analyzing code for rule improvement triggers
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to pytest.ini : Python projects must configure pytest with testpaths = tests, addopts = --cov=src --cov-report=html --cov-report=term for coverage reporting with thresholds matching Jest standards (80% lines, 70% branches)
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/unit/packages/**/*.test.ts : Use isolated unit tests in `tests/unit/packages/<package-name>/` only when parallel placement isn't possible
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/unit/**/*.test.js : Locate unit tests in `tests/unit/` directory. Test individual functions and utilities in isolation, mock all external dependencies, keep tests small and focused.
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/integration/**/*.test.js : Locate integration tests in `tests/integration/` directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Applied to files:
packages/tm-profiles/vitest.config.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/fixtures/**/* : Provide reusable test data in fixtures located in `tests/fixtures/`. Keep fixtures small and representative, export fixtures as named exports for reuse.
Applied to files:
packages/tm-profiles/vitest.config.ts
🧬 Code graph analysis (3)
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts (2)
packages/tm-profiles/src/slash-commands/commands/solo/index.ts (1)
removeSubtasks(23-23)packages/tm-profiles/src/slash-commands/factories.ts (1)
dynamicCommand(79-102)
packages/tm-profiles/src/slash-commands/commands/solo/generate-tasks.ts (1)
packages/tm-profiles/src/slash-commands/commands/solo/index.ts (1)
generateTasks(49-49)
packages/tm-profiles/src/slash-commands/commands/solo/quick-install-taskmaster.ts (2)
packages/tm-profiles/src/slash-commands/commands/solo/index.ts (1)
quickInstallTaskmaster(37-37)packages/tm-profiles/src/slash-commands/factories.ts (1)
staticCommand(46-60)
⏰ 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). (3)
- GitHub Check: Format Check
- GitHub Check: Typecheck
- GitHub Check: Build
🔇 Additional comments (2)
.github/workflows/ci.yml (1)
70-100: changeset-validation job looks fine as-is
Keeping it independent from node_modules caching makes sense since it’s conditional and light.packages/tm-profiles/src/slash-commands/commands/solo/index.ts (1)
6-49: LGTM — clean, topic-grouped barrel with ESM-friendly.jsspecifiers.Only thing to double-check is that exporting the full solo command surface here is intentional for the package’s public API (vs keeping some commands internal).
| export const generateTasks = staticCommand({ | ||
| name: 'generate-tasks', | ||
| description: 'Generate Task Files', | ||
| content: `Generate individual task files from tasks.json. | ||
|
|
||
| ## Task File Generation | ||
|
|
||
| Creates separate markdown files for each task, perfect for AI agents or documentation. | ||
|
|
||
| ## Execution | ||
|
|
||
| \`\`\`bash | ||
| task-master generate | ||
| \`\`\` | ||
|
|
||
| ## What It Creates | ||
|
|
||
| For each task, generates a file like \`task_001.md\`: | ||
|
|
||
| \`\`\` | ||
| Task ID: 1 | ||
| Title: Implement user authentication | ||
| Status: pending | ||
| Priority: high | ||
| Dependencies: [] | ||
| Created: 2024-01-15 | ||
| Complexity: 7 | ||
|
|
||
| ## Description | ||
| Create a secure user authentication system with login, logout, and session management. | ||
|
|
||
| ## Details | ||
| - Use JWT tokens for session management | ||
| - Implement secure password hashing | ||
| - Add remember me functionality | ||
| - Include password reset flow | ||
|
|
||
| ## Test Strategy | ||
| - Unit tests for auth functions | ||
| - Integration tests for login flow | ||
| - Security testing for vulnerabilities | ||
| - Performance tests for concurrent logins | ||
|
|
||
| ## Subtasks | ||
| 1.1 Setup authentication framework (pending) | ||
| 1.2 Create login endpoints (pending) | ||
| 1.3 Implement session management (pending) | ||
| 1.4 Add password reset (pending) | ||
| \`\`\` | ||
|
|
||
| ## File Organization | ||
|
|
||
| Creates structure: | ||
| \`\`\` | ||
| .taskmaster/ | ||
| └── tasks/ | ||
| ├── task_001.md | ||
| ├── task_002.md | ||
| ├── task_003.md | ||
| └── ... | ||
| \`\`\` | ||
|
|
||
| ## Smart Features | ||
|
|
||
| 1. **Consistent Formatting** | ||
| - Standardized structure | ||
| - Clear sections | ||
| - AI-readable format | ||
| - Markdown compatible | ||
|
|
||
| 2. **Contextual Information** | ||
| - Full task details | ||
| - Related task references | ||
| - Progress indicators | ||
| - Implementation notes | ||
|
|
||
| 3. **Incremental Updates** | ||
| - Only regenerate changed tasks | ||
| - Preserve custom additions | ||
| - Track generation timestamp | ||
| - Version control friendly | ||
|
|
||
| ## Use Cases | ||
|
|
||
| - **AI Context**: Provide task context to AI assistants | ||
| - **Documentation**: Standalone task documentation | ||
| - **Archival**: Task history preservation | ||
| - **Sharing**: Send specific tasks to team members | ||
| - **Review**: Easier task review process | ||
|
|
||
| ## Post-Generation | ||
|
|
||
| \`\`\` | ||
| Task File Generation Complete | ||
| ━━━━━━━━━━━━━━━━━━━━━━━━━━ | ||
| Generated: 45 task files | ||
| Location: .taskmaster/tasks/ | ||
| Total size: 156 KB | ||
|
|
||
| New files: 5 | ||
| Updated files: 12 | ||
| Unchanged: 28 | ||
|
|
||
| Ready for: | ||
| - AI agent consumption | ||
| - Version control | ||
| - Team distribution | ||
| \`\`\` | ||
|
|
||
| ## Integration Benefits | ||
|
|
||
| - Git-trackable task history | ||
| - Easy task sharing | ||
| - AI tool compatibility | ||
| - Offline task access | ||
| - Backup redundancy`, | ||
| mode: 'solo' | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the generate command implementation
fd -t f "generate" scripts/modules/ | head -20Repository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Check if there are any existing task files to see actual extension
find . -path "./.taskmaster/tasks/*" -type f 2>/dev/null | head -10Repository: eyaltoledano/claude-task-master
Length of output: 315
🏁 Script executed:
# Search for generate function/command in scripts
rg "generate" scripts/ -t js -A 5 -B 2 | head -100Repository: eyaltoledano/claude-task-master
Length of output: 6999
🏁 Script executed:
# Look for the actual tasks.json and generator logic
fd -t f "tasks.json" . | head -5Repository: eyaltoledano/claude-task-master
Length of output: 106
🏁 Script executed:
# Check .cursor/rules for task file generation details
cat .cursor/rules/taskmaster.mdc 2>/dev/null | head -50Repository: eyaltoledano/claude-task-master
Length of output: 4129
🏁 Script executed:
# Find and check the actual generator implementation
fd -t f "generator" scripts/ -o fd -t f "generate\.js" scripts/ 2>/dev/nullRepository: eyaltoledano/claude-task-master
Length of output: 57
🏁 Script executed:
# Look for task generation logic more broadly
rg "const generateTasks|function.*generate.*[Tt]ask" scripts/modules/task-manager/ -A 10 | head -80Repository: eyaltoledano/claude-task-master
Length of output: 3504
🏁 Script executed:
# Search for files related to task file output in scripts/modules/task-manager
ls -la scripts/modules/task-manager/ 2>/dev/nullRepository: eyaltoledano/claude-task-master
Length of output: 1871
🏁 Script executed:
# Check the actual generator code for incremental update and preservation logic
rg "incremental|preserve|regenerate" scripts/modules/task-manager/ -A 3 -B 3 | head -100Repository: eyaltoledano/claude-task-master
Length of output: 7754
File extension and incremental regeneration claims are inaccurate.
The documentation shows task_001.md as an example (line 31), but generated task files use the .txt extension with tag suffixes (e.g., task_001_tm-start.txt). Additionally, the "Incremental Updates" section (lines 88-93) claiming "preserve custom additions" and "only regenerate changed tasks" is misleading. The actual preservation logic in the codebase applies to subtasks within tasks.json—keeping completed subtasks when regenerating task content—not to preserving edits made directly to generated task files. Generated task files are auto-generated artifacts per the project conventions and should not be manually edited. Align the documentation with actual generator behavior: show .txt extension, clarify that regeneration is a manual step after tasks.json changes, and remove claims about preserving custom additions to task files.
There was a problem hiding this comment.
not really, not anymore at least, as per a recent update its .md now when generating
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the current task file extension in the generator code
rg "\.txt|\.md" scripts/modules/task-manager/generator.js -n -C3
Length of output: 81
🏁 Script executed:
#!/bin/bash
# Look for extension configuration or recent changes
rg "extension.*task|task.*extension" scripts/modules/task-manager/ -n -C2
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Check for any recent commits mentioning .md extension change
git log --all --oneline --grep="\.md\|extension" --since="2024-11-01" | head -20
Length of output: 1180
🏁 Script executed:
#!/bin/bash
# Check the actual task files in the example directory to see what extension they use
ls -la .taskmaster/tasks/ 2>/dev/null | head -20
Length of output: 552
🏁 Script executed:
#!/bin/bash
# Find the task generation logic - search for files containing task file generation
fd -e js -e ts "generate" scripts/modules/task-manager/
Length of output: 0
🏁 Script executed:
#!/bin/bash
# Search for task filename generation logic
rg "getTaskFileName|task_.*\.txt|task_.*\.md" scripts/modules/ -n -C2
Length of output: 1697
🏁 Script executed:
#!/bin/bash
# Check for any file extension constants or configs related to task files
rg "TASK.*EXTENSION|task.*extension.*=|\.txt|\.md" scripts/modules/task-manager/ -n -A1 -B1 | head -80
Length of output: 1930
🏁 Script executed:
#!/bin/bash
# Look at the actual task generation or formatter code
fd -e js . scripts/modules/task-manager/ --exec grep -l "format\|generate" {} \; | head -10
Length of output: 467
@Crunchyman-ralph, I appreciate the clarification attempt, but I need to respectfully point out that the evidence shows task files still use the .txt extension. Let me share what I found:
Actual current task files:
.taskmaster/tasks/task_001_tm-start.txt
.taskmaster/tasks/task_002_tm-start.txt
.taskmaster/tasks/task_003_tm-start.txt
Code still generates .txt files:
scripts/modules/task-manager/remove-task.js:178:`task_${taskIdNum.toString().padStart(3, '0')}.txt`scripts/modules/task-manager/parse-prd/parse-prd-helpers.js: Multiple references to.txtextension (lines 309, 314, 316)
The .md change you're thinking of:
The recent commit "Recommend .md extension for PRD files" (#1397) was specifically about PRD (Product Requirements Document) files in .taskmaster/docs/, not the generated task files in .taskmaster/tasks/.
So CodeRabbit's original feedback was correct—the documentation example showing task_001.md on line 31 should actually show task_001.txt (or with tag suffix like task_001_tm-start.txt per the tag-aware naming convention).
Would you like me to help update the documentation to reflect the correct .txt extension?
🧠 Learnings used
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/taskmaster.mdc:0-0
Timestamp: 2025-11-24T18:02:22.305Z
Learning: The generate command must be manually run after making changes to tasks.json to keep individual task markdown files up to date; this no longer runs automatically
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Regenerate task files after destructive operations by explicitly passing all required parameters to generation functions; provide a --skip-generate option if needed
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Regenerate task files after destructive operations, passing all required parameters to generation functions, and provide an option to skip regeneration if needed.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Run `task-master generate` after manual changes to tasks.json to regenerate task markdown files
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI within the current tag context (defaulting to "master"), providing clear prompts to guide AI task generation and validating/cleaning up AI-generated tasks
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided structure for adding subtasks, including required options and detailed error handling.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: The Task Master CLI uses a modular architecture with distinct modules responsible for different aspects: commands.js (CLI command handling), task-manager.js (task data & core logic), dependency-manager.js (dependency management), ui.js (output formatting), ai-services-unified.js (unified AI service layer), config-manager.js (configuration management), utils.js (core utility functions), and mcp-server/ (MCP interface)
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Format task files with consistent structure including task metadata (ID, title, status), dependencies with status indicators, and tag context information in the file header
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/tasks/tasks.json : Store main task data in `.taskmaster/tasks/tasks.json` and never manually edit this file - use Task Master commands instead
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/tasks/*.{txt,md} : Never manually edit task markdown files in `.taskmaster/tasks/*.txt` or `.taskmaster/tasks/*.md` - these are auto-generated from tasks.json and regenerated using `task-master generate`
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tags.mdc:0-0
Timestamp: 2025-11-24T18:02:04.644Z
Learning: Applies to scripts/modules/*/generate* : Generated task files must use tag-aware naming: `task_NNN.txt` for master tag, `task_NNN_TAGNAME.txt` for other tags
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/docs/**/*.md : Use `.md` extension for PRD files instead of `.txt` for better editor support, markdown syntax highlighting, and collaboration
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/*.js : Use consistent file naming conventions: `task_${id.toString().padStart(3, '0')}.txt` for task files; use `path.join()` for composing paths; use appropriate extensions (.txt for tasks, .json for data)
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.taskmaster/docs/prd.md : Always load `.taskmaster/docs/prd.md` with `.md` extension for better editor support when creating Product Requirements Documents
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/package.json:13-64
Timestamp: 2025-09-03T12:16:15.866Z
Learning: For internal packages in the claude-task-master project, Crunchyman-ralph prefers pointing package.json "types" entries to src .ts files rather than dist .d.ts files for better developer experience (DX), as the packages are not being exported as SDKs.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to mcp-server/src/core/direct-functions/*.js : Implement `async function yourCommandDirect(args, log)` with camelCase naming and Direct suffix; obtain tasksPath using `findTasksJsonPath(args, log)`; wrap core function calls with enableSilentMode/disableSilentMode; return formatted response with success/error and fromCache fields
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 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: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/git_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:23.032Z
Learning: Pull Request descriptions must include: Task Overview, Subtasks Completed (checklist), Implementation Details, Testing approach, Breaking Changes (if any), and Related Tasks.
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts (1)
17-104: Consider documenting optional CLI flags.The help text mentions smart features like "convert to standalone tasks" (line 65) and shows a confirmation prompt (lines 47-61), but doesn't document the corresponding CLI flags. Consider adding a brief section listing optional flags like
--convert,--yes(to skip confirmation), and--backupso users know how to access these features.Example addition after line 31:
task-master remove-subtasks --id=$ARGUMENTS+## Options
+
+---convert: Convert subtasks to standalone tasks instead of deleting
+---yes,-y: Skip confirmation prompt
+---backup: Create backup before removal
+Pre-Clear Analysis
</blockquote></details> <details> <summary>.github/workflows/ci.yml (1)</summary><blockquote> `24-46`: **Optional: avoid repeating the cache+install snippet across jobs** Not a blocker, but the restore+install block is duplicated in 4 jobs; consider a small composite action or reusable workflow to reduce future drift. Also applies to: 47-70, 107-130, 136-159, 176-200 </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 61ef16916ea978ec505b60ebe522b846d86eded1 and 3898907df8c63a0aa7bc55381965aef8ee6e0b19. </details> <details> <summary>📒 Files selected for processing (2)</summary> * `.github/workflows/ci.yml` (5 hunks) * `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>📓 Path-based instructions (3)</summary> <details> <summary>**/*.ts</summary> **📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)** > TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds Files: - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>**/*.{js,ts}</summary> **📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)** > `**/*.{js,ts}`: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic > Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call > Do not add direct console.log calls outside the logging utility - use the central log function instead > Ensure silent mode is disabled in a finally block to prevent it from staying enabled > Do not access the global silentMode variable directly - use the exported silent mode control functions instead > Do not duplicate task ID formatting logic across modules - centralize formatting utilities > Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context > Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters > Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency > Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections > Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync > Include error handling for JSON file operations and validate JSON structure after reading > Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations > Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values > Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements Files: - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>**/*.{ts,tsx}</summary> **📄 CodeRabbit inference engine (CLAUDE.md)** > Import modules with `.js` extension even in TypeScript source files for ESM compatibility Files: - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> </details><details> <summary>🧠 Learnings (27)</summary> <details> <summary>📓 Common learnings</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in.claude/commands/directory with.mdextension for repeated Task Master workflowsLearnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : UpdateCLAUDE.mdfile with project-specific context, task summaries, and custom command examples for Claude Code integrationLearnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in.claude/settings.jsonto include 'Edit', 'Bash(task-master )', 'Bash(git commit:)', 'Bash(git add:*)', 'Bash(npm run )', and 'mcp__task_master_ai__'Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern- [#PR](...) Thanks [author]! - Description, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.</details> <details> <summary>📚 Learning: 2025-09-26T19:28:42.612Z</summary>Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:21-35
Timestamp: 2025-09-26T19:28:42.612Z
Learning: Crunchyman-ralph is concerned about preventing production failures when developers add external dependencies to internal packages but forget to add them to the root package.json in their tsdown bundling setup. He wants automated safety mechanisms to catch this during development or CI rather than discovering it in production.**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-09-09T19:13:55.652Z</summary>Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1194
File: .github/workflows/ci.yml:31-35
Timestamp: 2025-09-09T19:13:55.652Z
Learning: The claude-task-master project has only one package-lock.json file in the entire workspace (at the root level), so cache-dependency-path configuration is unnecessary for the npm cache in GitHub Actions.**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-11-24T17:57:31.417Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/ai_services.mdc:0-0
Timestamp: 2025-11-24T17:57:31.417Z
Learning: Applies to scripts/modules/task-manager/*.js, scripts/modules/commands.js : Do not implement fallback or retry logic outsideai-services-unified.js; all fallback sequences and retry logic must be centralized in the unified service**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-11-24T17:59:00.056Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/context_gathering.mdc:0-0
Timestamp: 2025-11-24T17:59:00.056Z
Learning: Applies to scripts/**/*.js : Implement graceful error handling for context gathering: handle missing files with warnings, validate task IDs with helpful messages, continue processing if some context sources fail, and provide fallback behavior**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-11-24T18:00:32.617Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to changeset.mdc for guidelines on using Changesets (npm run changeset) to manage versioning and changelogs**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-11-24T22:09:45.455Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Runnpm run turbo:typecheckbefore pushing to ensure TypeScript type checks pass**Applied to files:** - `.github/workflows/ci.yml` </details> <details> <summary>📚 Learning: 2025-11-24T17:58:47.030Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Follow the remove-subtask command structure with options: --id (required, format parentId.subtaskId, can be comma-separated), --convert (for converting to standalone task), --file, and --generate**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-07-18T17:08:48.695Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided structure for removing subtasks, including required options, conversion option, and detailed error handling.**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-07-18T17:08:48.695Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Follow the provided structure for adding subtasks, including required options and detailed error handling.**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:02:36.388Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Use consistent properties for subtasks (id, title, description, status, dependencies, details) without duplicating parent task properties, maintaining simple numeric IDs unique within the parent task**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T17:58:47.030Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Follow the add-subtask command structure with proper options: --parent (required), --task-id, --title, --description, --details, --dependencies, --status, and --generate, with comprehensive parameter validation**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:00:06.827Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: For subtask implementation, usetask-master show <subtaskId>to understand goals, explore the codebase, determine code changes, then log the plan withtask-master update-subtask**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:02:36.388Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tasks.mdc:0-0
Timestamp: 2025-11-24T18:02:36.388Z
Learning: Applies to scripts/modules/task-manager.js : Extract tasks from PRD documents using AI within the current tag context (defaulting to "master"), providing clear prompts to guide AI task generation and validating/cleaning up AI-generated tasks**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-07-18T17:08:48.695Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : For destructive commands (like remove-task or remove-subtask), include a confirmation prompt by default, provide a --yes/-y flag to skip confirmation, and show what will be deleted in the confirmation message.**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T17:59:18.662Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-11-24T17:59:18.662Z
Learning: Applies to scripts/modules/dependency-manager.js : Check for and remove references to non-existent tasks and self-references during cleanup, tracking and reporting changes made during cleanup**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T17:58:07.992Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: The Task Master CLI uses a modular architecture with distinct modules responsible for different aspects: commands.js (CLI command handling), task-manager.js (task data & core logic), dependency-manager.js (dependency management), ui.js (output formatting), ai-services-unified.js (unified AI service layer), config-manager.js (configuration management), utils.js (core utility functions), and mcp-server/ (MCP interface)**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:01:06.077Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Use snake_case for MCP tool names exposed to clients (e.g., list_tasks, set_task_status)**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-12-11T14:45:14.973Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Use/clearcommand between different Task Master tasks in Claude Code to maintain focused context and conversation history**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:01:44.169Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/*.js : Use consistent file naming conventions:task_${id.toString().padStart(3, '0')}.txtfor task files; usepath.join()for composing paths; use appropriate extensions (.txt for tasks, .json for data)**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T17:58:47.030Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-11-24T17:58:47.030Z
Learning: Applies to scripts/modules/commands.js : Use kebab-case for command names (e.g., 'analyze-complexity', 'remove-task') and action-oriented descriptions**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:05:02.114Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/.windsurfrules:0-0
Timestamp: 2025-11-24T18:05:02.114Z
Learning: Use the global CLI commandtask-masterinstead ofnode scripts/dev.jsfor all task management operations**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-09-03T12:15:03.208Z</summary>Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: apps/cli/src/commands/auth.command.ts:222-224
Timestamp: 2025-09-03T12:15:03.208Z
Learning: The CLI can be invoked using both "task-master" and "tm" as aliases - both forms are valid and acceptable in help text, documentation, and examples.**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:00:06.827Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-24T18:00:06.827Z
Learning: Usetask-master show <id>(with dot notation for subtasks like1.2) to view specific task details before implementation**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-07-18T17:08:48.695Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/commands.mdc:0-0
Timestamp: 2025-07-18T17:08:48.695Z
Learning: Applies to scripts/modules/commands.js : Suggest non-destructive alternatives when appropriate, explain the difference between deletion and status changes, and include examples of alternative commands.**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-11-24T18:04:43.972Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to scripts/modules/task-manager/**/.{js,ts} : 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:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> <details> <summary>📚 Learning: 2025-07-18T17:09:40.548Z</summary>Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/dependencies.mdc:0-0
Timestamp: 2025-07-18T17:09:40.548Z
Learning: Applies to scripts/modules/dependency-manager.js : Allow numeric subtask IDs to reference other subtasks within the same parent**Applied to files:** - `packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts` </details> </details> </details> <details> <summary>🔇 Additional comments (6)</summary><blockquote> <details> <summary>packages/tm-profiles/src/slash-commands/commands/solo/remove-subtasks.ts (1)</summary><blockquote> `1-16`: **LGTM! Command structure follows best practices.** The import uses the `.js` extension for ESM compatibility, the command name follows kebab-case conventions, and the past naming inconsistencies have been successfully resolved. </blockquote></details> <details> <summary>.github/workflows/ci.yml (5)</summary><blockquote> `18-46`: **Centralized `node_modules` cache + per-job `npm ci` fallback looks solid** Keying the cache by OS + Node version + `package-lock.json` hash and using `npm ci` only on cache miss is the right resilience pattern (and avoids the old `fail-on-cache-miss` footgun). --- `176-214`: **Test job gating + artifact flow is coherent** The `needs` + `if: always() && …` pattern plus downloading the build artifacts before tests is consistent and avoids running tests when earlier critical jobs failed. --- `76-106`: **No additional dependencies or environment variables needed for changeset-validation job.** The `validate-changesets.mjs` script uses only Node.js built-in modules (`node:fs`, `node:path`, `node:url`) and contains no references to `TM_PUBLIC_*` variables. The step is correctly configured. Note: The `TM_PUBLIC_*` variables at lines 160-168 belong to the separate `Build` step, which appropriately requires them for the turbo build process. --- `76-106`: **`changeset-validation` does not require dependencies** The script `.github/scripts/validate-changesets.mjs` uses only Node.js built-in modules (`fs`, `path`, `url`) and does not import any npm packages. The explicit comment on line 18 confirms it "doesn't require external dependencies". The job is correctly designed to run without `needs: install` or node_modules cache restoration, as proposed in the diff. --- `160-168`: [rewritten comment] [classification tag] </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
tests/integration/profiles/hamster-rules-distribution.test.js (2)
73-84: Add negative test case for solo mode behavior.The test validates that hamster.mdc is distributed in team mode, but there's no corresponding test verifying it's NOT distributed in solo mode. Since the comments indicate hamster.mdc is "team-mode only," consider adding a test case to verify the mode filtering actually prevents distribution in solo mode.
Example test to add:
test(`${profile} profile does NOT receive hamster rules via 'rules add --mode=solo'`, () => { const tempDir = fs.mkdtempSync( path.join(os.tmpdir(), `tm-hamster-solo-test-${profile}-`) ); try { // Run in solo mode - hamster should NOT be distributed execSync(`node ${CLI_PATH} rules add ${profile} --mode=solo`, { cwd: tempDir, stdio: 'pipe', env: { ...process.env, TASKMASTER_LOG_LEVEL: 'error' } }); const expectedPath = getExpectedHamsterPath(profile, tempDir); // Verify hamster file does NOT exist in solo mode if (expectedPath) { expect(fs.existsSync(expectedPath)).toBe(false); } } finally { fs.rmSync(tempDir, { recursive: true, force: true }); } });
73-109: Consider testing default behavior when --mode is omitted.For completeness, consider adding a test to verify the behavior when the
--modeflag is not specified. This would document whether the default is solo or team mode.Example test:
test(`${profile} profile behavior when --mode flag is omitted`, () => { const tempDir = fs.mkdtempSync( path.join(os.tmpdir(), `tm-hamster-default-test-${profile}-`) ); try { // Run without mode flag to test default behavior execSync(`node ${CLI_PATH} rules add ${profile}`, { cwd: tempDir, stdio: 'pipe', env: { ...process.env, TASKMASTER_LOG_LEVEL: 'error' } }); const expectedPath = getExpectedHamsterPath(profile, tempDir); // Verify expected default behavior // Adjust expectation based on whether default should be solo or team if (expectedPath) { // expect(fs.existsSync(expectedPath)).toBe(false); // if default is solo // or // expect(fs.existsSync(expectedPath)).toBe(true); // if default is team } } finally { fs.rmSync(tempDir, { recursive: true, force: true }); } });
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/integration/profiles/hamster-rules-distribution.test.js(2 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
**/*.js: Always use isSilentMode() function to check current silent mode status instead of directly accessing the global silentMode variable or global.silentMode
Use try/finally block pattern when wrapping core function calls with enableSilentMode/disableSilentMode to ensure silent mode is always restored, even if errors occur
For functions that need to handle both a passed silentMode parameter and check global state, check both the function parameter and global state: const isSilent = options.silentMode || (typeof options.silentMode === 'undefined' && isSilentMode())
Functions should accept their dependencies as parameters rather than using globals to promote testability and explicit dependency injection
Define callbacks as separate functions for easier testing rather than inline functions
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Integration tests should be located in tests/integration/ and test interactions between modules
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
**/*.test.{js,ts}: Follow the mock-first-then-import pattern for Jest mocking; use jest.spyOn() for spy functions; clear mocks between tests; verify mocks with the pattern described intests.mdc
Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.{js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
JavaScript test files using Jest must follow the same testing patterns as TypeScript files, include proper mocking of external dependencies, and achieve the same coverage thresholds
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Always mock tests properly based on the way the tested functions are defined and used.
Follow Jest test file structure: 1) Imports, 2) Mock setup before importing modules under test, 3) Import modules after mocks, 4) Set up spies on mocked modules, 5) Describe suite with descriptive name, 6) Setup/teardown hooks, 7) Grouped tests for related functionality, 8) Individual test cases with clear descriptions using Arrange-Act-Assert pattern.
When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Usejest.mock()before any imports. Jest hoists mock calls to the top of the file. Always declare mocks before importing modules being tested. Use factory pattern for complex mocks that need access to other variables.
When testing ES modules with dynamic imports, usejest.unstable_mockModule()beforeawait import(). Include__esModule: truein mock factories. Reset mock functions before dynamic import. Mock named and default exports as needed.
Mock file system operations usingmock-fslibrary. Mock API calls by providing jest.fn() implementations that return expected structures. Mock environment variables in test setup.
When testing functions with callbacks: get the callback from mock's call arguments usingmock.calls[index][argIndex]; execute it directly with test inputs; verify results match expectations.
For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mockreadJSONandwriteJSONto avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed t...
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Locate integration tests in
tests/integration/directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts}: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic
Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call
Do not add direct console.log calls outside the logging utility - use the central log function instead
Ensure silent mode is disabled in a finally block to prevent it from staying enabled
Do not access the global silentMode variable directly - use the exported silent mode control functions instead
Do not duplicate task ID formatting logic across modules - centralize formatting utilities
Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context
Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters
Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency
Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections
Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync
Include error handling for JSON file operations and validate JSON structure after reading
Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations
Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values
Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
🧠 Learnings (14)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to **/*.test.{js,ts} : Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/integration/**/*.test.js : Locate integration tests in `tests/integration/` directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Create simplified test functions instead of complex setups: create simplified versions of complex functions focusing on core logic; remove file system operations, API calls, and external dependencies; pass all dependencies as parameters.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.{spec,test}.ts : In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/**/*.{spec,test}.ts : In unit tests for apps/cli, mock tm-core responses but use real Commander/chalk/inquirer/other npm packages to test display logic
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/e2e/**/*.test.js : Locate end-to-end tests in `tests/e2e/` directory. Test complete workflows from a user perspective, focus on CLI commands as users would use them.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mock `readJSON` and `writeJSON` to avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed to `writeJSON`.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.test.ts : Unit tests must follow the describe/it pattern, use beforeEach for mock setup with jest.clearAllMocks(), include specific assertions with expect(), and test both success and error scenarios including edge cases
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: Applies to tests/integration/**/*.js : Integration tests should be located in tests/integration/ and test interactions between modules
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/unit/**/*.test.js : Locate unit tests in `tests/unit/` directory. Test individual functions and utilities in isolation, mock all external dependencies, keep tests small and focused.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to tests.mdc for guidelines on implementing and maintaining tests for Task Master CLI
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing UI functions: mock console output and verify correct formatting; test conditional output logic; use `toContain()` or `toMatch()` rather than exact `toBe()` for strings with emojis or formatting; create separate tests for different behavior modes; test structure of formatted output rather than exact string matching.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.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). (3)
- GitHub Check: typecheck
- GitHub Check: build
- GitHub Check: Test
🔇 Additional comments (1)
tests/integration/profiles/hamster-rules-distribution.test.js (1)
12-14: Clear documentation of team mode testing.The updated comments accurately describe the test's purpose and clarify that hamster.mdc is team-mode only. The note about Hamster API integration provides helpful context.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/integration/profiles/hamster-rules-distribution.test.js(3 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
**/*.js: Always use isSilentMode() function to check current silent mode status instead of directly accessing the global silentMode variable or global.silentMode
Use try/finally block pattern when wrapping core function calls with enableSilentMode/disableSilentMode to ensure silent mode is always restored, even if errors occur
For functions that need to handle both a passed silentMode parameter and check global state, check both the function parameter and global state: const isSilent = options.silentMode || (typeof options.silentMode === 'undefined' && isSilentMode())
Functions should accept their dependencies as parameters rather than using globals to promote testability and explicit dependency injection
Define callbacks as separate functions for easier testing rather than inline functions
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Integration tests should be located in tests/integration/ and test interactions between modules
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
**/*.test.{js,ts}: Follow the mock-first-then-import pattern for Jest mocking; use jest.spyOn() for spy functions; clear mocks between tests; verify mocks with the pattern described intests.mdc
Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.{js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
JavaScript test files using Jest must follow the same testing patterns as TypeScript files, include proper mocking of external dependencies, and achieve the same coverage thresholds
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Always mock tests properly based on the way the tested functions are defined and used.
Follow Jest test file structure: 1) Imports, 2) Mock setup before importing modules under test, 3) Import modules after mocks, 4) Set up spies on mocked modules, 5) Describe suite with descriptive name, 6) Setup/teardown hooks, 7) Grouped tests for related functionality, 8) Individual test cases with clear descriptions using Arrange-Act-Assert pattern.
When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Usejest.mock()before any imports. Jest hoists mock calls to the top of the file. Always declare mocks before importing modules being tested. Use factory pattern for complex mocks that need access to other variables.
When testing ES modules with dynamic imports, usejest.unstable_mockModule()beforeawait import(). Include__esModule: truein mock factories. Reset mock functions before dynamic import. Mock named and default exports as needed.
Mock file system operations usingmock-fslibrary. Mock API calls by providing jest.fn() implementations that return expected structures. Mock environment variables in test setup.
When testing functions with callbacks: get the callback from mock's call arguments usingmock.calls[index][argIndex]; execute it directly with test inputs; verify results match expectations.
For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mockreadJSONandwriteJSONto avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed t...
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Locate integration tests in
tests/integration/directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts}: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic
Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call
Do not add direct console.log calls outside the logging utility - use the central log function instead
Ensure silent mode is disabled in a finally block to prevent it from staying enabled
Do not access the global silentMode variable directly - use the exported silent mode control functions instead
Do not duplicate task ID formatting logic across modules - centralize formatting utilities
Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context
Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters
Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency
Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections
Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync
Include error handling for JSON file operations and validate JSON structure after reading
Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations
Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values
Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
🧠 Learnings (13)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/src/**/*.{ts,tsx} : CLI (tm/cli) should be a thin presentation layer that calls tm-core methods and displays results; handle only CLI-specific concerns like argument parsing, output formatting, and user prompts
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to **/*.test.{js,ts} : Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/integration/**/*.test.js : Locate integration tests in `tests/integration/` directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.{spec,test}.ts : In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/**/*.{spec,test}.ts : In unit tests for apps/cli, mock tm-core responses but use real Commander/chalk/inquirer/other npm packages to test display logic
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/e2e/**/*.test.js : Locate end-to-end tests in `tests/e2e/` directory. Test complete workflows from a user perspective, focus on CLI commands as users would use them.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.test.ts : Unit tests must follow the describe/it pattern, use beforeEach for mock setup with jest.clearAllMocks(), include specific assertions with expect(), and test both success and error scenarios including edge cases
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mock `readJSON` and `writeJSON` to avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed to `writeJSON`.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: Applies to tests/integration/**/*.js : Integration tests should be located in tests/integration/ and test interactions between modules
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/unit/**/*.test.js : Locate unit tests in `tests/unit/` directory. Test individual functions and utilities in isolation, mock all external dependencies, keep tests small and focused.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to tests.mdc for guidelines on implementing and maintaining tests for Task Master CLI
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing UI functions: mock console output and verify correct formatting; test conditional output logic; use `toContain()` or `toMatch()` rather than exact `toBe()` for strings with emojis or formatting; create separate tests for different behavior modes; test structure of formatted output rather than exact string matching.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.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). (3)
- GitHub Check: typecheck
- GitHub Check: build
- GitHub Check: Test
🔇 Additional comments (4)
tests/integration/profiles/hamster-rules-distribution.test.js (4)
1-44: LGTM! Well-structured test setup.The imports, constants, and helper function are appropriate for integration testing. The separation of profiles with/without default rules is clear and maintainable.
46-71: LGTM! Appropriate source file verification.These tests provide good baseline verification that the source hamster.mdc file exists and has the expected structure.
73-110: LGTM! Robust team mode testing.The team mode tests properly verify that hamster rules are distributed when
--mode=teamis used. The strict assertion onexpectedPath(line 94) is particularly good as it catches configuration issues early.
171-187: LGTM! Proper verification of profile configuration.The test correctly verifies that profiles without default rules are configured as expected using dynamic imports.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/mcp/tests/integration/tools/generate.tool.test.ts (1)
75-79: Add explanatory comment for TASK_MASTER_TOOLS configuration.The
TASK_MASTER_TOOLS: 'all'environment variable is a recognized configuration option that enables all available tools (44+) for MCP integration tests, defaulting to 'core' mode when unset. While this is a standard feature, adding a brief comment above line 75 would clarify intent for future maintainers:+ // Enable all tools for comprehensive integration testing const output = execSync( `npx @modelcontextprotocol/inspector --cli node "${mcpServerPath}" --method tools/call --tool-name ${toolName} ${toolArgs}`, { encoding: 'utf-8', stdio: 'pipe', env: { ...process.env, TASK_MASTER_TOOLS: 'all' } } );
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/mcp/tests/integration/tools/generate.tool.test.ts(1 hunks)tests/integration/profiles/hamster-rules-distribution.test.js(3 hunks)
🧰 Additional context used
📓 Path-based instructions (14)
**/*.test.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/new_features.mdc)
**/*.test.{js,ts}: Follow the mock-first-then-import pattern for Jest mocking; use jest.spyOn() for spy functions; clear mocks between tests; verify mocks with the pattern described intests.mdc
Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Files:
apps/mcp/tests/integration/tools/generate.tool.test.tstests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
Unit tests must follow the describe/it pattern, use beforeEach for mock setup with jest.clearAllMocks(), include specific assertions with expect(), and test both success and error scenarios including edge cases
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
TypeScript test files must achieve minimum code coverage thresholds: 80% lines/functions and 70% branches globally, 90% for utilities, and 85% for middleware; new features must meet or exceed these thresholds
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/*.{js,ts}
📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)
**/*.{js,ts}: Import and use specific getters from config-manager.js (e.g., getMainProvider(), getLogLevel(), getMainMaxTokens()) to access configuration values needed for application logic
Use isApiKeySet(providerName, session) from config-manager.js to check if a provider's key is available before potentially attempting an AI call
Do not add direct console.log calls outside the logging utility - use the central log function instead
Ensure silent mode is disabled in a finally block to prevent it from staying enabled
Do not access the global silentMode variable directly - use the exported silent mode control functions instead
Do not duplicate task ID formatting logic across modules - centralize formatting utilities
Use ContextGatherer class from utils/contextGatherer.js for AI-powered commands that need project context, supporting tasks, files, custom text, and project tree context
Use FuzzyTaskSearch class from utils/fuzzyTaskSearch.js for automatic task relevance detection with configurable search parameters
Use fuzzy search to supplement user-provided task IDs and display discovered task IDs to users for transparency
Do not replace explicit user task selections with fuzzy results - fuzzy search should supplement, not replace user selections
Use readJSON and writeJSON utilities for all JSON file operations instead of raw fs.readFileSync or fs.writeFileSync
Include error handling for JSON file operations and validate JSON structure after reading
Use path.join() for cross-platform path construction and path.resolve() for absolute paths, validating paths before file operations
Support both .env files and MCP session environment for environment variable resolution with fallbacks for missing values
Prefer updating the core function to accept an outputFormat parameter and check outputFormat === 'json' before displaying UI elements
Files:
apps/mcp/tests/integration/tools/generate.tool.test.tstests/integration/profiles/hamster-rules-distribution.test.js
**/tests/integration/**/*.test.ts
📄 CodeRabbit inference engine (CLAUDE.md)
Place package and app integration tests in
packages/<package-name>/tests/integration/<module>/<file>.test.tsorapps/<app-name>/tests/integration/<module>/<file>.test.ts
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/*.{spec,test}.ts
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{spec,test}.ts: Always use.tsfor TypeScript tests, never.js
NEVER use async/await in test functions unless testing actual asynchronous operations; use synchronous top-level imports instead of dynamicawait import()
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
Import modules with
.jsextension even in TypeScript source files for ESM compatibility
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
apps/mcp/**/*.{spec,test}.ts
📄 CodeRabbit inference engine (CLAUDE.md)
In unit tests for apps/mcp, mock tm-core responses but use real MCP framework to test response formatting
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/tests/integration/**/*.{spec,test}.ts
📄 CodeRabbit inference engine (CLAUDE.md)
In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
**/*.js: Always use isSilentMode() function to check current silent mode status instead of directly accessing the global silentMode variable or global.silentMode
Use try/finally block pattern when wrapping core function calls with enableSilentMode/disableSilentMode to ensure silent mode is always restored, even if errors occur
For functions that need to handle both a passed silentMode parameter and check global state, check both the function parameter and global state: const isSilent = options.silentMode || (typeof options.silentMode === 'undefined' && isSilentMode())
Functions should accept their dependencies as parameters rather than using globals to promote testability and explicit dependency injection
Define callbacks as separate functions for easier testing rather than inline functions
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.js
📄 CodeRabbit inference engine (.cursor/rules/architecture.mdc)
Integration tests should be located in tests/integration/ and test interactions between modules
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.{js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/test_workflow.mdc)
JavaScript test files using Jest must follow the same testing patterns as TypeScript files, include proper mocking of external dependencies, and achieve the same coverage thresholds
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
**/*.test.js: Never use asynchronous operations in tests. Always mock tests properly based on the way the tested functions are defined and used.
Follow Jest test file structure: 1) Imports, 2) Mock setup before importing modules under test, 3) Import modules after mocks, 4) Set up spies on mocked modules, 5) Describe suite with descriptive name, 6) Setup/teardown hooks, 7) Grouped tests for related functionality, 8) Individual test cases with clear descriptions using Arrange-Act-Assert pattern.
When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Usejest.mock()before any imports. Jest hoists mock calls to the top of the file. Always declare mocks before importing modules being tested. Use factory pattern for complex mocks that need access to other variables.
When testing ES modules with dynamic imports, usejest.unstable_mockModule()beforeawait import(). Include__esModule: truein mock factories. Reset mock functions before dynamic import. Mock named and default exports as needed.
Mock file system operations usingmock-fslibrary. Mock API calls by providing jest.fn() implementations that return expected structures. Mock environment variables in test setup.
When testing functions with callbacks: get the callback from mock's call arguments usingmock.calls[index][argIndex]; execute it directly with test inputs; verify results match expectations.
For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mockreadJSONandwriteJSONto avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed t...
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
tests/integration/**/*.test.js
📄 CodeRabbit inference engine (.cursor/rules/tests.mdc)
Locate integration tests in
tests/integration/directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Files:
tests/integration/profiles/hamster-rules-distribution.test.js
🧠 Learnings (36)
📓 Common learnings
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/commands/*.md : Store custom slash commands in `.claude/commands/` directory with `.md` extension for repeated Task Master workflows
Learnt from: eyaltoledano
Repo: eyaltoledano/claude-task-master PR: 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
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/**/CLAUDE.md : Update `CLAUDE.md` file with project-specific context, task summaries, and custom command examples for Claude Code integration
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: assets/AGENTS.md:0-0
Timestamp: 2025-12-11T14:45:14.973Z
Learning: Applies to assets/.claude/settings.json : Add Claude Code tool allowlist configuration in `.claude/settings.json` to include 'Edit', 'Bash(task-master *)', 'Bash(git commit:*)', 'Bash(git add:*)', 'Bash(npm run *)', and 'mcp__task_master_ai__*'
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1444
File: apps/cli/src/utils/auto-update/changelog.ts:103-111
Timestamp: 2025-11-25T18:32:29.828Z
Learning: The claude-task-master project uses a custom changelog format with PR numbers and author acknowledgements in the pattern `- [#PR](...) Thanks [author]! - Description`, which is parsed by the regex in apps/cli/src/utils/auto-update/changelog.ts.
Learnt from: joedanz
Repo: eyaltoledano/claude-task-master PR: 1186
File: src/profiles/cursor.js:37-43
Timestamp: 2025-09-17T19:28:51.486Z
Learning: In the eyaltoledano/claude-task-master repository cursor profile implementation, the onAdd lifecycle hook sources command files from 'assets/claude/commands' and transforms them for Cursor IDE compatibility, rather than using separate cursor-specific command files.
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to scripts/modules/commands.js : All new user-facing commands should be added to `commands.js` following Commander.js patterns for subcommand structure and consistent option naming
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/src/**/*.{ts,tsx} : CLI (tm/cli) should be a thin presentation layer that calls tm-core methods and displays results; handle only CLI-specific concerns like argument parsing, output formatting, and user prompts
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1252
File: packages/ai-sdk-provider-grok-cli/package.json:11-13
Timestamp: 2025-09-26T19:05:47.555Z
Learning: In the eyaltoledano/claude-task-master repository, internal tm/ packages use a specific export pattern where the "exports" field points to TypeScript source files (./src/index.ts) while "main" points to compiled output (./dist/index.js) and "types" points to source files (./src/index.ts). This pattern is used consistently across internal packages like tm/core and tm/ai-sdk-provider-grok-cli because they are consumed directly during build-time bundling with tsdown rather than being published as separate packages.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/auth/config.ts:5-7
Timestamp: 2025-09-02T21:51:27.921Z
Learning: The user Crunchyman-ralph prefers not to use node: scheme imports (e.g., 'node:os', 'node:path') for Node.js core modules and considers suggestions to change bare imports to node: scheme as too nitpicky.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1069
File: .changeset/fix-tag-complexity-detection.md:0-0
Timestamp: 2025-08-02T15:33:22.656Z
Learning: For changeset files (.changeset/*.md), Crunchyman-ralph prefers to ignore formatting nitpicks about blank lines between frontmatter and descriptions, as he doesn't mind having them and wants to avoid such comments in future reviews.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1132
File: .github/workflows/weekly-metrics-discord.yml:81-93
Timestamp: 2025-08-13T22:10:46.958Z
Learning: Crunchyman-ralph ignores YAML formatting nitpicks about trailing spaces when there's no project-specific YAML formatter configured, preferring to focus on functionality over cosmetic formatting issues.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1105
File: scripts/modules/supported-models.json:242-254
Timestamp: 2025-08-08T11:33:15.297Z
Learning: Preference: In scripts/modules/supported-models.json, the "name" field is optional. For OpenAI entries (e.g., "gpt-5"), Crunchyman-ralph prefers omitting "name" when the id is explicit enough; avoid nitpicks requesting a "name" in such cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1200
File: src/ai-providers/custom-sdk/grok-cli/language-model.js:96-100
Timestamp: 2025-09-19T16:06:42.182Z
Learning: The user Crunchyman-ralph prefers to keep environment variable names explicit (like GROK_CLI_API_KEY) rather than supporting multiple aliases, to avoid overlap and ensure clear separation between different CLI implementations.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1178
File: packages/tm-core/src/subpath-exports.test.ts:6-9
Timestamp: 2025-09-03T12:45:30.724Z
Learning: The user Crunchyman-ralph prefers to avoid overly nitpicky or detailed suggestions in code reviews, especially for test coverage of minor import paths. Focus on more substantial issues rather than comprehensive coverage of all possible edge cases.
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1217
File: apps/cli/src/index.ts:16-21
Timestamp: 2025-09-18T16:35:35.147Z
Learning: The user Crunchyman-ralph considers suggestions to export types for better ergonomics (like exporting UpdateInfo type alongside related functions) as nitpicky and prefers not to implement such suggestions.
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to **/*.test.{js,ts} : Test new features with both legacy and tagged task data formats; verify tag resolution behavior; test migration compatibility; ensure pre-migration projects are handled correctly
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.tstests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to **/tests/integration/**/*.{spec,test}.ts : In integration tests, use real tm-core and mock only external boundaries (APIs, DB, filesystem)
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to mcp-server/src/tools/**/*.{js,ts} : Use the withNormalizedProjectRoot Higher-Order Function to wrap tool execute methods, ensuring normalized project root is injected into args
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to mcp-server/src/core/task-master-core.js : Update `task-master-core.js` by importing and re-exporting direct functions and adding them to the directFunctions map
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-26T21:57:48.927Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1451
File: apps/mcp/src/tools/tasks/set-task-status.tool.ts:23-25
Timestamp: 2025-11-26T21:57:48.927Z
Learning: Applies to apps/mcp/src/tools/**/*.ts : In the new apps/mcp MCP tool architecture, projectRoot is a required parameter in Zod schemas (not optional like in the legacy mcp-server structure)
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/mcp/**/*.{spec,test}.ts : In unit tests for apps/mcp, mock tm-core responses but use real MCP framework to test response formatting
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to tests/teardown.ts : Global teardown file must be created to handle cleanup after all tests complete and prevent worker process leaks
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.integration.test.ts : Integration tests must use supertest for API endpoint testing, verify database state changes after operations, clean test data before each test, and include full request/response validation with expected HTTP status codes
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing CLI commands built with Commander.js: test command action handlers directly rather than mocking the entire Commander chain; create simplified test-specific implementations of command handlers; explicitly handle all options including defaults and shorthand flags; include null/undefined checks for optional parameters; use fixtures for consistent sample data.
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.tstests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Include projectRoot as an optional parameter in tool definitions using zod schema
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Call the corresponding *Direct function wrapper from task-master-core.js within the execute method of each MCP tool, passing necessary arguments and the logger
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Applies to mcp-server/src/tools/*.js : Create MCP tool definitions in `mcp-server/src/tools/` using kebab-case naming; use zod for parameter validation; make projectRoot optional as the HOF handles fallback; wrap execute method with `withNormalizedProjectRoot`
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: If an MCP tool fails with unclear errors, run the equivalent task-master CLI command to get more detailed error messages from the core logic
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Wrap the entire execute function of an MCP tool with the withNormalizedProjectRoot Higher-Order Function to ensure consistent handling of project paths across different environments
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:04:43.972Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/utilities.mdc:0-0
Timestamp: 2025-11-24T18:04:43.972Z
Learning: Applies to mcp-server/src/tools/**/*.{js,ts} : Use processMCPResponseData(taskOrData, fieldsToRemove) utility to filter potentially sensitive or large fields (like details, testStrategy) from task objects before sending responses
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-10-14T14:30:14.725Z
Learnt from: Crunchyman-ralph
Repo: eyaltoledano/claude-task-master PR: 1289
File: mcp-server/server.js:10-12
Timestamp: 2025-10-14T14:30:14.725Z
Learning: In MCP server implementations using stdio transport (like mcp-server/server.js), the TASK_MASTER_MCP environment variable must be forced to 'true' unconditionally to silence console output from tm-core, as any console.log/warn/error would corrupt the JSON-RPC protocol stream. This is not a user preference but a technical requirement for stdio-based MCP servers.
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:02:49.782Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/telemetry.mdc:0-0
Timestamp: 2025-11-24T18:02:49.782Z
Learning: Applies to mcp-server/src/tools/**/*.js : MCP tools in mcp-server/src/tools/ must call the corresponding direct function wrapper and pass the result object to handleApiResult(result, log) from mcp-server/src/tools/utils.js
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: Applies to mcp-server/src/tools/*.js : MCP tool execute methods should be wrapped with the withNormalizedProjectRoot HOF to ensure consistent path handling and provide a normalized args.projectRoot to the execute method
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:06.077Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/mcp.mdc:0-0
Timestamp: 2025-11-24T18:01:06.077Z
Learning: Applies to mcp-server/src/tools/*.js : Use snake_case for MCP tool names exposed to clients (e.g., list_tasks, set_task_status)
Applied to files:
apps/mcp/tests/integration/tools/generate.tool.test.ts
📚 Learning: 2025-11-24T18:01:44.169Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/new_features.mdc:0-0
Timestamp: 2025-11-24T18:01:44.169Z
Learning: Every new feature must include comprehensive tests following guidelines in `tests.mdc`, including unit tests, integration tests, edge cases, and at least 80% code coverage
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : For task file operations in tests: use test-specific file paths (e.g., 'test-tasks.json'); mock `readJSON` and `writeJSON` to avoid real file system interactions; verify file operations use correct paths; use different paths for each test; verify modifications on in-memory task objects passed to `writeJSON`.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing console assertions: ensure assertion matches actual arguments passed; if code logs a single formatted string, assert against that single string using `expect.stringContaining` or exact match, not multiple arguments; verify exact behavior of the code being tested.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Create simplified test functions instead of complex setups: create simplified versions of complex functions focusing on core logic; remove file system operations, API calls, and external dependencies; pass all dependencies as parameters.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Do not import or instantiate real AI service clients. Create fully mocked versions that return predictable responses. Mock the entire module with controlled behavior.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Test quality guidelines: Write tests before implementing features (TDD). Test edge cases and error conditions, not just happy paths. Keep tests independent and isolated. Use descriptive test names. Maintain test fixtures separately. Aim for 80%+ code coverage with critical paths at 100%.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing exact error messages, don't assert on exact error message text that might change. Instead test for error presence and general properties using patterns like `toContain` or `toMatch`.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:13.456Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/test_workflow.mdc:0-0
Timestamp: 2025-11-24T18:03:13.456Z
Learning: Applies to **/*.test.ts : Unit tests must follow the describe/it pattern, use beforeEach for mock setup with jest.clearAllMocks(), include specific assertions with expect(), and test both success and error scenarios including edge cases
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : When testing UI functions: mock console output and verify correct formatting; test conditional output logic; use `toContain()` or `toMatch()` rather than exact `toBe()` for strings with emojis or formatting; create separate tests for different behavior modes; test structure of formatted output rather than exact string matching.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to **/*.test.js : Avoid these common testing pitfalls: Don't test implementation details; Don't write brittle tests dependent on specific output formatting; Don't skip error handling and validation testing; Don't duplicate test fixtures across files; Don't write tests dependent on execution order; Don't define mock variables before jest.mock() calls.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/integration/**/*.test.js : Locate integration tests in `tests/integration/` directory. Test interactions between modules, focus on component interfaces rather than implementation details, use more realistic but controlled test environments.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T22:09:45.455Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T22:09:45.455Z
Learning: Applies to apps/cli/**/*.{spec,test}.ts : In unit tests for apps/cli, mock tm-core responses but use real Commander/chalk/inquirer/other npm packages to test display logic
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/e2e/**/*.test.js : Locate end-to-end tests in `tests/e2e/` directory. Test complete workflows from a user perspective, focus on CLI commands as users would use them.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T17:58:07.992Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/architecture.mdc:0-0
Timestamp: 2025-11-24T17:58:07.992Z
Learning: Applies to tests/integration/**/*.js : Integration tests should be located in tests/integration/ and test interactions between modules
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:03:46.713Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/tests.mdc:0-0
Timestamp: 2025-11-24T18:03:46.713Z
Learning: Applies to tests/unit/**/*.test.js : Locate unit tests in `tests/unit/` directory. Test individual functions and utilities in isolation, mock all external dependencies, keep tests small and focused.
Applied to files:
tests/integration/profiles/hamster-rules-distribution.test.js
📚 Learning: 2025-11-24T18:00:32.617Z
Learnt from: CR
Repo: eyaltoledano/claude-task-master PR: 0
File: .cursor/rules/glossary.mdc:0-0
Timestamp: 2025-11-24T18:00:32.617Z
Learning: Refer to tests.mdc for guidelines on implementing and maintaining tests for Task Master CLI
Applied to files:
tests/integration/profiles/hamster-rules-distribution.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). (3)
- GitHub Check: build
- GitHub Check: typecheck
- GitHub Check: Test
🔇 Additional comments (5)
tests/integration/profiles/hamster-rules-distribution.test.js (5)
12-13: Excellent documentation clarity.The updated comments clearly communicate that hamster.mdc is team-mode only and explain the rationale (Hamster API integration). This aligns perfectly with the test scenarios below.
73-109: Well-structured team mode validation.The test suite correctly validates hamster.mdc distribution in team mode with:
- Explicit
--mode=teamflag in the CLI invocation- Strict enforcement that expectedPath is not null (line 94)
- Content verification to ensure proper file distribution
- Proper cleanup with isolated temp directories
The test follows integration testing best practices and clearly validates the expected behavior.
112-140: Excellent solo mode coverage with past feedback addressed.This test suite properly validates that hamster.mdc is NOT distributed in solo mode. The enforcement at line 131 (
expect(expectedPath).not.toBeNull()) addresses the previous review feedback and ensures configuration issues are surfaced rather than silently passing.The negative assertions (file should NOT exist) are clear and correct, and the test structure maintains proper isolation and cleanup.
142-171: Comprehensive default mode testing with past feedback incorporated.This test suite validates the important default behavior (when no
--modeflag is specified). The enforcement at line 162 (expect(expectedPath).not.toBeNull()) addresses the previous review feedback and ensures the test fails fast if profile configuration is missing.The clear comments explaining that default mode equals solo mode help future maintainers understand the expected behavior. The test structure is consistent with the other suites and maintains proper isolation.
1-190: Outstanding integration test coverage.This test file exemplifies integration testing best practices:
- ✅ Tests real CLI command execution rather than mocking
- ✅ Validates actual file system interactions
- ✅ Covers all operating modes (team, solo, default)
- ✅ Tests both positive (file exists) and negative (file doesn't exist) scenarios
- ✅ Enforces configuration expectations before assertions
- ✅ Maintains test isolation with unique temp directories
- ✅ Ensures proper cleanup in finally blocks
- ✅ Uses descriptive test names that clearly communicate intent
The test suite provides comprehensive coverage for the hamster rules distribution feature and successfully addresses all previous review feedback.
Based on learnings, integration tests should be located in tests/integration/ and test interactions between modules, which this file follows correctly.
1 participant
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
New Features
Improvements
Tests
✏️ Tip: You can customize this high-level summary in your review settings.