chore: v0.17 features and improvements (#771)
* chore: task management and small bug fix. * chore: task management * feat: implement research command with enhanced context gathering - Add comprehensive research command with AI-powered queries - Implement ContextGatherer utility for reusable context extraction - Support multiple context types: tasks, files, custom text, project tree - Add fuzzy search integration for automatic task discovery - Implement detailed token breakdown display with syntax highlighting - Add enhanced UI with boxed output and code block formatting - Support different detail levels (low, medium, high) for responses - Include project-specific context for more relevant AI responses - Add token counting with gpt-tokens library integration - Create reusable patterns for future context-aware commands - Task 94.4 completed * docs: add context gathering rule and update existing rules - Create comprehensive context_gathering.mdc rule documenting ContextGatherer utility patterns, FuzzyTaskSearch integration, token breakdown display, code block syntax highlighting, and enhanced result display patterns - Update new_features.mdc to include context gathering step - Update commands.mdc with context-aware command pattern - Update ui.mdc with enhanced display patterns and syntax highlighting - Update utilities.mdc to document new context gathering utilities - Update glossary.mdc to include new context_gathering rule - Establishes standardized patterns for building intelligent, context-aware commands that can leverage project knowledge for better AI assistance * feat(fuzzy): improves fuzzy search to introspect into subtasks as well. might still need improvement. * fix(move): adjusts logic to prevent an issue when moving from parent to subtask if the target parent has no subtasks. * fix(move-task): Fix critical bugs in task move functionality - Fixed parent-to-parent task moves where original task would remain as duplicate - Fixed moving tasks to become subtasks of empty parents (validation errors) - Fixed moving subtasks between different parent tasks - Improved comma-separated batch moves with proper error handling - Updated MCP tool to use core logic instead of custom implementation - Resolves task duplication issues and enables proper task hierarchy reorganization * feat(research): Add subtasks to fuzzy search and follow-up questions - Enhanced fuzzy search to include subtasks in discovery - Added interactive follow-up question functionality using inquirer - Improved context discovery by including both tasks and subtasks - Follow-up option for research with default to 'n' for quick workflow * chore: removes task004 chat that had like 11k lines lol. * chore: formatting * feat(show): add comma-separated ID support for multi-task viewing - Enhanced get-task/show command to support comma-separated task IDs for efficient batch operations. - New features include multiple task retrieval, smart display logic, interactive action menu with batch operations, MCP array response for AI agent efficiency, and support for mixed parent tasks and subtasks. - Implementation includes updated CLI show command, enhanced MCP get_task tool, modified showTaskDirect function, and maintained full backward compatibility. - Documentation updated across all relevant files. Benefits include faster context gathering for AI agents, improved workflow with interactive batch operations, better UX with responsive layout, and enhanced API efficiency. * feat(research): Adds MCP tool for command - New MCP Tool: research tool enables AI-powered research with project context - Context Integration: Supports task IDs, file paths, custom context, and project tree - Fuzzy Task Discovery: Automatically finds relevant tasks using semantic search - Token Management: Detailed token counting and breakdown by context type - Multiple Detail Levels: Support for low, medium, and high detail research responses - Telemetry Integration: Full cost tracking and usage analytics - Direct Function: researchDirect with comprehensive parameter validation - Silent Mode: Prevents console output interference with MCP JSON responses - Error Handling: Robust error handling with proper MCP response formatting This completes subtasks 94.5 (Direct Function) and 94.6 (MCP Tool) for the research command implementation, providing a powerful research interface for integrated development environments like Cursor. Updated documentation across taskmaster.mdc, README.md, command-reference.md, examples.md, tutorial.md, and docs/README.md to highlight research capabilities and usage patterns. * chore: task management * chore: task management and removes mistakenly staged changes * fix(move): Fix move command bug that left duplicate tasks - Fixed logic in moveTaskToNewId function that was incorrectly treating task-to-task moves as subtask creation instead of task replacement - Updated moveTaskToNewId to properly handle replacing existing destination tasks instead of just placeholders - The move command now correctly replaces destination tasks and cleans up properly without leaving duplicates - Task Management: Moved task 93 (Google Vertex AI Provider) to position 88, Moved task 94 (Azure OpenAI Provider) to position 89, Updated task dependencies and regenerated task files, Cleaned up orphaned task files automatically - All important validations remain in place: Prevents moving tasks to themselves, Prevents moving parent tasks to their own subtasks, Prevents circular dependencies - Resolves the issue where moving tasks would leave both source and destination tasks in tasks.json and file system * chore: formatting * feat: Add .taskmaster directory (#619) * chore: apply requested changes from next branch (#629) * chore: rc version bump * chore: cleanup migration-guide * fix: bedrock set model and other fixes (#641) * Fix: MCP log errors (#648) * fix: projectRoot duplicate .taskmaster directory (#655) * Version Packages * chore: add package-lock.json * Version Packages * Version Packages * fix: markdown format (#622) * Version Packages * Version Packages * Fixed the Typo in cursor rules Issue:#675 (#677) Fixed the typo in the Api keys * Add one-click MCP server installation for Cursor (#671) * Update README.md - Remove trailing commas (#673) JSON doesn't allow for trailing commas, so these need to be removed in order for this to work * chore: rc version bump * fix: findTasksPath function * fix: update MCP tool * feat(ui): replace emoji complexity indicators with clean filled circle characters Replace 🟢, 🟡, 🔴 emojis with ● character in getComplexityWithColor function Update corresponding unit tests to expect ● instead of emojis Improves UI continuity * fix(ai-providers): change generateObject mode from 'tool' to 'auto' for better provider compatibility Fixes Perplexity research role failing with 'tool-mode object generation' error The hardcoded 'tool' mode was incompatible with providers like Perplexity that support structured JSON output but not function calling/tool use Using 'auto' mode allows the AI SDK to choose the best approach for each provider * Adds qwen3-235n-a22b:free to supported models. Closes #687) * chore: adds a warning when custom openrouter model is a free model which suffers from lower rate limits, restricted context, and, worst of all, no access to tool_use. * refactor: enhance add-task fuzzy search and fix duplicate banner display - **Remove hardcoded category system** in add-task that always matched 'Task management' - **Eliminate arbitrary limits** in fuzzy search results (5→25 high relevance, 3→10 medium relevance, 8→20 detailed tasks) - **Improve semantic weighting** in Fuse.js search (details=3, description=2, title=1.5) for better relevance - **Fix duplicate banner issue** by removing console.clear() and redundant displayBanner() calls from UI functions - **Enhance context generation** to rely on semantic similarity rather than rigid pattern matching - **Preserve terminal history** to address GitHub issue #553 about eating terminal lines - **Remove displayBanner() calls** from: displayHelp, displayNextTask, displayTaskById, displayComplexityReport, set-task-status, clear-subtasks, dependency-manager functions The add-task system now provides truly relevant task context based on semantic similarity rather than arbitrary categories and limits, while maintaining a cleaner terminal experience. Changes span: add-task.js, ui.js, set-task-status.js, clear-subtasks.js, list-tasks.js, dependency-manager.js Closes #553 * chore: changeset * chore: passes tests and linting * chore: more linting * ninja(sync): add sync-readme command for GitHub README export with UTM tracking and professional markdown formatting. Experimental * chore: changeset adjustment * docs: Auto-update and format models.md * chore: updates readme with npm download badges and mentions AI Jason who is joining the taskmaster core team. * chore: fixes urls in readme npm packages * chore: fixes urls in readme npm packages again * fix: readme typo * readme: fix twitter urls. * readme: removes the taskmaster list output which is too overwhelming given its size with subtasks. may re-add later. fixes likely issues in the json for manual config in cursor and windsurf in the readme. * chore: small readme nitpicks * chore: adjusts changeset from minor to patch to avoid version bump to 0.17 * readme: moves up the documentation links higher up in the readme. same with the cursor one-click install. * Fix Cursor deeplink installation with copy-paste instructions (#723) * solve merge conflics with next. not gonna deal with these much longer. * chore: update task files during rebase * chore: task management * feat: implement research command with enhanced context gathering - Add comprehensive research command with AI-powered queries - Implement ContextGatherer utility for reusable context extraction - Support multiple context types: tasks, files, custom text, project tree - Add fuzzy search integration for automatic task discovery - Implement detailed token breakdown display with syntax highlighting - Add enhanced UI with boxed output and code block formatting - Support different detail levels (low, medium, high) for responses - Include project-specific context for more relevant AI responses - Add token counting with gpt-tokens library integration - Create reusable patterns for future context-aware commands - Task 94.4 completed * fix(move): adjusts logic to prevent an issue when moving from parent to subtask if the target parent has no subtasks. * fix(move-task): Fix critical bugs in task move functionality - Fixed parent-to-parent task moves where original task would remain as duplicate - Fixed moving tasks to become subtasks of empty parents (validation errors) - Fixed moving subtasks between different parent tasks - Improved comma-separated batch moves with proper error handling - Updated MCP tool to use core logic instead of custom implementation - Resolves task duplication issues and enables proper task hierarchy reorganization * chore: removes task004 chat that had like 11k lines lol. * feat(show): add comma-separated ID support for multi-task viewing - Enhanced get-task/show command to support comma-separated task IDs for efficient batch operations. - New features include multiple task retrieval, smart display logic, interactive action menu with batch operations, MCP array response for AI agent efficiency, and support for mixed parent tasks and subtasks. - Implementation includes updated CLI show command, enhanced MCP get_task tool, modified showTaskDirect function, and maintained full backward compatibility. - Documentation updated across all relevant files. Benefits include faster context gathering for AI agents, improved workflow with interactive batch operations, better UX with responsive layout, and enhanced API efficiency. * feat(research): Adds MCP tool for command - New MCP Tool: research tool enables AI-powered research with project context - Context Integration: Supports task IDs, file paths, custom context, and project tree - Fuzzy Task Discovery: Automatically finds relevant tasks using semantic search - Token Management: Detailed token counting and breakdown by context type - Multiple Detail Levels: Support for low, medium, and high detail research responses - Telemetry Integration: Full cost tracking and usage analytics - Direct Function: researchDirect with comprehensive parameter validation - Silent Mode: Prevents console output interference with MCP JSON responses - Error Handling: Robust error handling with proper MCP response formatting This completes subtasks 94.5 (Direct Function) and 94.6 (MCP Tool) for the research command implementation, providing a powerful research interface for integrated development environments like Cursor. Updated documentation across taskmaster.mdc, README.md, command-reference.md, examples.md, tutorial.md, and docs/README.md to highlight research capabilities and usage patterns. * chore: task management * fix(move): Fix move command bug that left duplicate tasks - Fixed logic in moveTaskToNewId function that was incorrectly treating task-to-task moves as subtask creation instead of task replacement - Updated moveTaskToNewId to properly handle replacing existing destination tasks instead of just placeholders - The move command now correctly replaces destination tasks and cleans up properly without leaving duplicates - Task Management: Moved task 93 (Google Vertex AI Provider) to position 88, Moved task 94 (Azure OpenAI Provider) to position 89, Updated task dependencies and regenerated task files, Cleaned up orphaned task files automatically - All important validations remain in place: Prevents moving tasks to themselves, Prevents moving parent tasks to their own subtasks, Prevents circular dependencies - Resolves the issue where moving tasks would leave both source and destination tasks in tasks.json and file system * chore: moves to new task master config setup * feat: add comma-separated status filtering to list-tasks - supports multiple statuses like 'blocked,deferred' with comprehensive test coverage and backward compatibility - also adjusts biome.json to stop bitching about templating. * chore: linting ffs * fix(generate): Fix generate command creating tasks in legacy location - Update generate command default output directory from 'tasks' to '.taskmaster/tasks' - Fix path.dirname() usage to properly derive output directory from tasks file location - Update MCP tool description and documentation to reflect new structure - Disable Biome linting rules for noUnusedTemplateLiteral and useArrowFunction - Fixes issue where generate command was creating task files in the old 'tasks/' directory instead of the new '.taskmaster/tasks/' structure after the refactor * chore: task management * chore: task management some more * fix(get-task): makes the projectRoot argument required to prevent errors when getting tasks. * feat(tags): Implement tagged task lists migration system (Part 1/2) This commit introduces the foundational infrastructure for tagged task lists, enabling multi-context task management without remote storage to prevent merge conflicts. CORE ARCHITECTURE: • Silent migration system transforms tasks.json from old format { "tasks": [...] } to new tagged format { "master": { "tasks": [...] } } • Tag resolution layer provides complete backward compatibility - existing code continues to work • Automatic configuration and state management for seamless user experience SILENT MIGRATION SYSTEM: • Automatic detection and migration of legacy tasks.json format • Complete project migration: tasks.json + config.json + state.json • Transparent tag resolution returns old format to maintain compatibility • Zero breaking changes - all existing functionality preserved CONFIGURATION MANAGEMENT: • Added global.defaultTag setting (defaults to 'master') • New tags section with gitIntegration placeholders for future features • Automatic config.json migration during first run • Proper state.json creation with migration tracking USER EXPERIENCE: • Clean, one-time FYI notice after migration (no emojis, professional styling) • Notice appears after 'Suggested Next Steps' and is tracked in state.json • Silent operation - users unaware migration occurred unless explicitly shown TECHNICAL IMPLEMENTATION: • Enhanced readJSON() with automatic migration detection and processing • New utility functions: getCurrentTag(), resolveTag(), getTasksForTag(), setTasksForTag() • Complete migration orchestration via performCompleteTagMigration() • Robust error handling and fallback mechanisms BACKWARD COMPATIBILITY: • 100% backward compatibility maintained • Existing CLI commands and MCP tools continue to work unchanged • Legacy tasks.json format automatically upgraded on first read • All existing workflows preserved TESTING VERIFIED: • Complete migration from legacy state works correctly • Config.json properly updated with tagged system settings • State.json created with correct initial values • Migration notice system functions as designed • All existing functionality continues to work normally Part 2 will implement tag management commands (add-tag, use-tag, list-tags) and MCP tool updates for full tagged task system functionality. Related: Task 103 - Implement Tagged Task Lists System for Multi-Context Task Management * docs: Update documentation and rules for tagged task lists system - Updated task-structure.md with comprehensive tagged format explanation - Updated all .cursor/rules/*.mdc files to reflect tagged system - Completed subtask 103.16: Update Documentation for Tagged Task Lists System * feat(mcp): Add tagInfo to responses and integrate ContextGatherer Enhances the MCP server to include 'tagInfo' (currentTag, availableTags) in all tool responses, providing better client-side context. - Introduces a new 'ContextGatherer' utility to standardize the collection of file, task, and project context for AI-powered commands. This refactors several task-manager modules ('expand-task', 'research', 'update-task', etc.) to use the new utility. - Fixes an issue in 'get-task' and 'get-tasks' MCP tools where the 'projectRoot' was not being passed correctly, preventing tag information from being included in their responses. - Adds subtask '103.17' to track the implementation of the task template importing feature. - Updates documentation ('.cursor/rules', 'docs/') to align with the new tagged task system and context gatherer logic. * fix: include tagInfo in AI service responses for MCP tools - Update all core functions that call AI services to extract and return tagInfo - Update all direct functions to include tagInfo in MCP response data - Fixes issue where add_task, expand_task, and other AI commands were not including current tag and available tags information - tagInfo includes currentTag from state.json and availableTags list - Ensures tagged task lists system information is properly propagated through the full chain: AI service -> core function -> direct function -> MCP client * fix(move-task): Update move functionality for tagged task system compatibility - incorporate GitHub commit fixes and resolve readJSON data handling * feat(tagged-tasks): Complete core tag management system implementation - Implements comprehensive tagged task lists system for multi-context task management including core tag management functions (Task 103.11), MCP integration updates, and foundational infrastructure for tagged task operations. Features tag CRUD operations, validation, metadata tracking, deep task copying, and full backward compatibility. * fix(core): Fixed move-task.js writing _rawTaggedData directly, updated writeJSON to filter tag fields, fixed CLI move command missing projectRoot, added ensureTagMetadata utility * fix(tasks): ensure list tasks triggers silent migration if necessary. * feat(tags): Complete show and add-task command tag support - show command: Added --tag flag, fixed projectRoot passing to UI functions - add-task command: Already had proper tag support and projectRoot handling - Both commands now work correctly with tagged task lists system - Migration logic works properly when viewing and adding tasks - Updated subtask 103.5 with progress on high-priority command fixes * fix(tags): Clean up rogue created properties and fix taskCount calculation - Enhanced writeJSON to automatically filter rogue created/description properties from tag objects - Fixed tags command error by making taskCount calculation dynamic instead of hardcoded - Cleaned up existing rogue created property in master tag through forced write operation - All created properties now properly located in metadata objects only - Tags command working perfectly with proper task count display - Data integrity maintained with automatic cleanup during write operations * fix(tags): Resolve critical tag deletion and migration notice bugs Major Issues Fixed: 1. Tag Deletion Bug: Fixed critical issue where creating subtasks would delete other tags - Root cause: writeJSON function wasn't accepting projectRoot/tag parameters - Fixed writeJSON signature and logic to handle tagged data structure - Added proper merging of resolved tag data back into full tagged structure 2. Persistent Migration Notice: Fixed FYI notice showing after every command - Root cause: markMigrationForNotice was resetting migrationNoticeShown to false - Fixed migration logic to only trigger on actual legacy->tagged migrations - Added proper _rawTaggedData checks to prevent false migration detection 3. Data Corruption Prevention: Enhanced data integrity safeguards - Fixed writeJSON to filter out internal properties - Added automatic cleanup of rogue properties - Improved hasTaggedStructure detection logic Commands Fixed: add-subtask, remove-subtask, and all commands now preserve tags correctly * fix(tags): Resolve tag deletion bug in remove-task command Refactored the core 'removeTask' function to be fully tag-aware, preventing data corruption. - The function now correctly reads the full tagged data structure by prioritizing '_rawTaggedData' instead of operating on a resolved single-tag view. - All subsequent operations (task removal, dependency cleanup, file writing) now correctly reference the full multi-tag data object, preserving the integrity of 'tasks.json'. - This resolves the critical bug where removing a task would delete all other tags. * fix(tasks): Ensure new task IDs are sequential within the target tag Modified the ID generation logic in 'add-task.js' to calculate the next task ID based on the highest ID within the specified tag, rather than globally across all tags. This fixes a critical bug where creating a task in a new tag would result in a high, non-sequential ID, such as ID 105 for the first task in a tag. * fix(commands): Add missing context parameters to dependency and remove-subtask commands - Add projectRoot and tag context to all dependency commands - Add projectRoot and tag context to remove-subtask command - Add --tag option to remove-subtask command - Fixes critical bug where remove-subtask was deleting other tags due to missing context - All dependency and subtask commands now properly handle tagged task lists * feat(tags): Add --tag flag support to core commands for multi-context task management - parse-prd now supports creating tasks in specific contexts - Fixed tag preservation logic to prevent data loss - analyze-complexity generates tag-specific reports - Non-existent tags created automatically - Enables rapid prototyping and parallel development workflows * feat(tags): Complete tagged task lists system with enhanced use-tag command - Multi-context task management with full CLI support - Enhanced use-tag command shows next available task after switching - Universal --tag flag support across all commands - Seamless migration with zero disruption - Complete tag management suite (add, delete, rename, copy, list) - Smart confirmation logic and data integrity protection - State management and configuration integration - Real-world use cases for teams, features, and releases * feat(tags): Complete tag support for remaining CLI commands - Add --tag flag to update, move, and set-status commands - Ensure all task operation commands now support tag context - Fix missing tag context passing to core functions - Complete comprehensive tag-aware command coverage * feat(ui): add tag indicator to all CLI commands - shows 🏷️ tag: tagname for complete context visibility across 15+ commands * fix(ui): resolve dependency 'Not found' issue when filtering - now correctly displays dependencies that exist but are filtered out of view * feat(research): Add comprehensive AI-powered research command with interactive follow-ups, save functionality, intelligent context gathering, fuzzy task discovery, multi-source context support, enhanced display with syntax highlighting, clean inquirer menus, comprehensive help, and MCP integration with saveTo parameter * feat(tags): Implement full MCP support for Tagged Task Lists and update-task append mode * chore: task management * feat(research): Enhance research command with follow-up menu, save functionality, and fix ContextGatherer token counting * feat(git-workflow): Add automatic git branch-tag integration - Implement automatic tag creation when switching to new git branches - Add branch-tag mapping system for seamless context switching - Enable auto-switch of task contexts based on current git branch - Provide isolated task contexts per branch to prevent merge conflicts - Add configuration support for enabling/disabling git workflow features - Fix ES module compatibility issues in git-utils module - Maintain zero migration impact with automatic 'master' tag creation - Support parallel development with branch-specific task contexts The git workflow system automatically detects branch changes and creates corresponding empty task tags, enabling developers to maintain separate task contexts for different features/branches while preventing task-related merge conflicts during collaborative development. Resolves git workflow integration requirements for multi-context development. * feat(git-workflow): Simplify git integration with --from-branch option - Remove automatic git workflow and branch-tag switching - we are not ready for it yet - Add --from-branch option to add-tag command for manual tag creation from git branch - Remove git workflow configuration from config.json and assets - Disable automatic tag switching functions in git-utils.js - Add createTagFromBranch function for branch-based tag creation - Support both CLI and MCP interfaces for --from-branch functionality - Fix ES module imports in git-utils.js and utils.js - Maintain user control over tag contexts without forced automation The simplified approach allows users to create tags from their current git branch when desired, without the complexity and rigidity of automatic branch-tag synchronization. Users maintain full control over their tag contexts while having convenient tools for git-based workflows when needed. * docs: Update rule files to reflect simplified git integration approach - Remove automatic git workflow features, update to manual --from-branch option, change Part 2 references to completed status * fix(commands): Fix add-tag --from-branch requiring tagName argument - Made tagName optional when using --from-branch - Added validation for either tagName or --from-branch - Fixes 'missing required argument' error with --from-branch option * fix(mcp): Prevent tag deletion on subtask update Adds a safety net to the writeJSON utility to prevent data loss when updating subtasks via the MCP server. The MCP process was inadvertently causing the _rawTaggedData property, which holds the complete multi-tag structure, to be lost. When writeJSON received the data for only a single tag, it would overwrite the entire tasks.json file, deleting all other tags. This fix makes writeJSON more robust. If it receives data that looks like a single, resolved tag without the complete structure, it re-reads the full tasks.json file from disk. It then carefully merges the updated data back into the correct tag within the full structure, preserving all other tags. * fix: resolve all remaining test failures and improve test reliability - Fix clear-subtasks test by implementing deep copy of mock data to prevent mutation issues between tests - Fix add-task test by uncommenting and properly configuring generateTaskFiles call with correct parameters - Fix analyze-task-complexity tests by properly mocking fs.writeFileSync with shared mock function - Update test expectations to match actual function signatures and data structures - Improve mock setup consistency across all test suites - Ensure all tests now pass (329 total: 318 passed, 11 skipped, 0 failed) * chore: task management --------- Co-authored-by: Eyal Toledano <eyal@microangel.so> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Ibrahim H. <bitsnaps@yahoo.fr> Co-authored-by: Saksham Goel <sakshamgoel1107@gmail.com> Co-authored-by: Joe Danziger <joe@ticc.net> Co-authored-by: Aaron Gabriel Neyer <ag@unforced.org>
This commit is contained in:
Ralph Khreish
@@ -20,19 +20,21 @@ alwaysApply: false
|
||||
- **[`task-manager.js`](mdc:scripts/modules/task-manager.js) & `task-manager/` directory: Task Data & Core Logic**
|
||||
- **Purpose**: Contains core functions for task data manipulation (CRUD), AI interactions, and related logic.
|
||||
- **Responsibilities**:
|
||||
- Reading/writing `tasks.json`.
|
||||
- Reading/writing `tasks.json` with tagged task lists support.
|
||||
- Implementing functions for task CRUD, parsing PRDs, expanding tasks, updating status, etc.
|
||||
- **Tagged Task Lists**: Handles task organization across multiple contexts (tags) like "master", branch names, or project phases.
|
||||
- **Tag Resolution**: Provides backward compatibility by resolving tagged format to legacy format transparently.
|
||||
- **Delegating AI interactions** to the `ai-services-unified.js` layer.
|
||||
- Accessing non-AI configuration via `config-manager.js` getters.
|
||||
- **Key Files**: Individual files within `scripts/modules/task-manager/` handle specific actions (e.g., `add-task.js`, `expand-task.js`).
|
||||
|
||||
- **[`dependency-manager.js`](mdc:scripts/modules/dependency-manager.js): Dependency Management**
|
||||
- **Purpose**: Manages task dependencies.
|
||||
- **Responsibilities**: Add/remove/validate/fix dependencies.
|
||||
- **Responsibilities**: Add/remove/validate/fix dependencies across tagged task contexts.
|
||||
|
||||
- **[`ui.js`](mdc:scripts/modules/ui.js): User Interface Components**
|
||||
- **Purpose**: Handles CLI output formatting (tables, colors, boxes, spinners).
|
||||
- **Responsibilities**: Displaying tasks, reports, progress, suggestions.
|
||||
- **Responsibilities**: Displaying tasks, reports, progress, suggestions, and migration notices for tagged systems.
|
||||
|
||||
- **[`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js): Unified AI Service Layer**
|
||||
- **Purpose**: Centralized interface for all LLM interactions using Vercel AI SDK.
|
||||
@@ -53,6 +55,7 @@ alwaysApply: false
|
||||
- **Responsibilities** (See also: [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)):
|
||||
- Reads and merges `.taskmasterconfig` with defaults.
|
||||
- Provides getters (e.g., `getMainProvider`, `getLogLevel`, `getDefaultSubtasks`) for accessing settings.
|
||||
- **Tag Configuration**: Manages `global.defaultTag` and `tags` section for tag system settings.
|
||||
- **Note**: Does **not** store or directly handle API keys (keys are in `.env` or MCP `session.env`).
|
||||
|
||||
- **[`utils.js`](mdc:scripts/modules/utils.js): Core Utility Functions**
|
||||
@@ -62,6 +65,8 @@ alwaysApply: false
|
||||
- Task utils (`findTaskById`), Dependency utils (`findCycles`).
|
||||
- API Key Resolution (`resolveEnvVariable`).
|
||||
- Silent Mode Control (`enableSilentMode`, `disableSilentMode`).
|
||||
- **Tagged Task Lists**: Silent migration system, tag resolution, current tag management.
|
||||
- **Migration System**: `performCompleteTagMigration`, `migrateConfigJson`, `createStateJson`.
|
||||
|
||||
- **[`mcp-server/`](mdc:mcp-server/): MCP Server Integration**
|
||||
- **Purpose**: Provides MCP interface using FastMCP.
|
||||
@@ -71,16 +76,42 @@ alwaysApply: false
|
||||
- Tool `execute` methods call **direct function wrappers** (`mcp-server/src/core/direct-functions/*.js`), passing the normalized `projectRoot` and other args.
|
||||
- Direct functions use path utilities (`mcp-server/src/core/utils/`) to resolve paths based on `projectRoot` from session.
|
||||
- Direct functions implement silent mode, logger wrappers, and call core logic functions from `scripts/modules/`.
|
||||
- **Tagged Task Lists**: MCP tools fully support the tagged format with complete tag management capabilities.
|
||||
- Manages MCP caching and response formatting.
|
||||
|
||||
- **[`init.js`](mdc:scripts/init.js): Project Initialization Logic**
|
||||
- **Purpose**: Sets up new Task Master project structure.
|
||||
- **Responsibilities**: Creates directories, copies templates, manages `package.json`, sets up `.cursor/mcp.json`.
|
||||
- **Responsibilities**: Creates directories, copies templates, manages `package.json`, sets up `.cursor/mcp.json`, initializes state.json for tagged system.
|
||||
|
||||
## Tagged Task Lists System Architecture
|
||||
|
||||
**Data Structure**: Task Master now uses a tagged task lists system where the `tasks.json` file contains multiple named task lists as top-level keys:
|
||||
|
||||
```json
|
||||
{
|
||||
"master": {
|
||||
"tasks": [/* standard task objects */]
|
||||
},
|
||||
"feature-branch": {
|
||||
"tasks": [/* separate task context */]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Key Components:**
|
||||
|
||||
- **Silent Migration**: Automatically transforms legacy `{"tasks": [...]}` format to tagged format `{"master": {"tasks": [...]}}` on first read
|
||||
- **Tag Resolution Layer**: Provides 100% backward compatibility by intercepting tagged format and returning legacy format to existing code
|
||||
- **Configuration Integration**: `global.defaultTag` and `tags` section in config.json manage tag system settings
|
||||
- **State Management**: `.taskmaster/state.json` tracks current tag, migration status, and tag-branch mappings
|
||||
- **Migration Notice**: User-friendly notification system for seamless migration experience
|
||||
|
||||
**Backward Compatibility**: All existing CLI commands and MCP tools continue to work unchanged. The tag resolution layer ensures that existing code receives the expected legacy format while the underlying storage uses the new tagged structure.
|
||||
|
||||
- **Data Flow and Module Dependencies (Updated)**:
|
||||
|
||||
- **CLI**: `bin/task-master.js` -> `scripts/dev.js` (loads `.env`) -> `scripts/modules/commands.js` -> Core Logic (`scripts/modules/*`) -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **MCP**: External Tool -> `mcp-server/server.js` -> Tool (`mcp-server/src/tools/*`) -> Direct Function (`mcp-server/src/core/direct-functions/*`) -> Core Logic (`scripts/modules/*`) -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **CLI**: `bin/task-master.js` -> `scripts/dev.js` (loads `.env`) -> `scripts/modules/commands.js` -> Core Logic (`scripts/modules/*`) -> **Tag Resolution Layer** -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **MCP**: External Tool -> `mcp-server/server.js` -> Tool (`mcp-server/src/tools/*`) -> Direct Function (`mcp-server/src/core/direct-functions/*`) -> Core Logic (`scripts/modules/*`) -> **Tag Resolution Layer** -> Unified AI Service (`ai-services-unified.js`) -> Provider Adapters -> LLM API.
|
||||
- **Configuration**: Core logic needing non-AI settings calls `config-manager.js` getters (passing `session.env` via `explicitRoot` if from MCP). Unified AI Service internally calls `config-manager.js` getters (using `role`) for AI params and `utils.js` (`resolveEnvVariable` with `session.env`) for API keys.
|
||||
|
||||
## Silent Mode Implementation Pattern in MCP Direct Functions
|
||||
@@ -197,6 +228,7 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Integration Tests**: Located in `tests/integration/`, test interactions between modules
|
||||
- **End-to-End Tests**: Located in `tests/e2e/`, test complete workflows from a user perspective
|
||||
- **Test Fixtures**: Located in `tests/fixtures/`, provide reusable test data
|
||||
- **Tagged System Tests**: Test migration, tag resolution, and multi-context functionality
|
||||
|
||||
- **Module Design for Testability**:
|
||||
- **Explicit Dependencies**: Functions accept their dependencies as parameters rather than using globals
|
||||
@@ -205,12 +237,14 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Clear Module Interfaces**: Each module has well-defined exports that can be mocked in tests
|
||||
- **Callback Isolation**: Callbacks are defined as separate functions for easier testing
|
||||
- **Stateless Design**: Modules avoid maintaining internal state where possible
|
||||
- **Tag Resolution Testing**: Test both tagged and legacy format handling
|
||||
|
||||
- **Mock Integration Patterns**:
|
||||
- **External Libraries**: Libraries like `fs`, `commander`, and `@anthropic-ai/sdk` are mocked at module level
|
||||
- **Internal Modules**: Application modules are mocked with appropriate spy functions
|
||||
- **Testing Function Callbacks**: Callbacks are extracted from mock call arguments and tested in isolation
|
||||
- **UI Elements**: Output functions from `ui.js` are mocked to verify display calls
|
||||
- **Tagged Data Mocking**: Test both legacy and tagged task data structures
|
||||
|
||||
- **Testing Flow**:
|
||||
- Module dependencies are mocked (following Jest's hoisting behavior)
|
||||
@@ -218,6 +252,7 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- Spy functions are set up on module methods
|
||||
- Tests call the functions under test and verify behavior
|
||||
- Mocks are reset between test cases to maintain isolation
|
||||
- Tagged system behavior is tested for both migration and normal operation
|
||||
|
||||
- **Benefits of this Architecture**:
|
||||
|
||||
@@ -226,8 +261,11 @@ By following these patterns consistently, direct functions will properly manage
|
||||
- **Mocking Support**: The clear dependency boundaries make mocking straightforward
|
||||
- **Test Isolation**: Each component can be tested without affecting others
|
||||
- **Callback Testing**: Function callbacks can be extracted and tested independently
|
||||
- **Multi-Context Testing**: Tagged system enables testing different task contexts independently
|
||||
- **Reusability**: Utility functions and UI components can be reused across different parts of the application.
|
||||
- **Scalability**: New features can be added as new modules or by extending existing ones without significantly impacting other parts of the application.
|
||||
- **Multi-Context Support**: Tagged task lists enable working across different contexts (branches, environments, phases) without conflicts.
|
||||
- **Backward Compatibility**: Seamless migration and tag resolution ensure existing workflows continue unchanged.
|
||||
- **Clarity**: The modular structure provides a clear separation of concerns, making the codebase easier to navigate and understand for developers.
|
||||
|
||||
This architectural overview should help AI models understand the structure and organization of the Task Master CLI codebase, enabling them to more effectively assist with code generation, modification, and understanding.
|
||||
@@ -249,6 +287,7 @@ Follow these steps to add MCP support for an existing Task Master command (see [
|
||||
- Call core logic.
|
||||
- Return `{ success: true/false, data/error, fromCache: boolean }`.
|
||||
- Export the wrapper function.
|
||||
- **Note**: Tag-aware MCP tools are fully implemented with complete tag management support.
|
||||
|
||||
3. **Update `task-master-core.js` with Import/Export**: Add imports/exports for the new `*Direct` function.
|
||||
|
||||
@@ -275,12 +314,8 @@ The `initialize_project` command provides a way to set up a new Task Master proj
|
||||
- **MCP Tool**: `initialize_project`
|
||||
- **Functionality**:
|
||||
- Creates necessary directories and files for a new project
|
||||
- Sets up `tasks.json` and initial task files
|
||||
- Configures project metadata (name, description, version)
|
||||
- Handles shell alias creation if requested
|
||||
- Works in both interactive and non-interactive modes
|
||||
- Creates necessary directories and files for a new project
|
||||
- Sets up `tasks.json` and initial task files
|
||||
- Sets up `tasks.json` with tagged structure and initial task files
|
||||
- Configures project metadata (name, description, version)
|
||||
- Initializes state.json for tag system
|
||||
- Handles shell alias creation if requested
|
||||
- Works in both interactive and non-interactive modes
|
||||
@@ -329,6 +329,60 @@ When implementing commands that delete or remove data (like `remove-task` or `re
|
||||
};
|
||||
```
|
||||
|
||||
## Context-Aware Command Pattern
|
||||
|
||||
For AI-powered commands that benefit from project context, follow the research command pattern:
|
||||
|
||||
- **Context Integration**:
|
||||
- ✅ DO: Use `ContextGatherer` utility for multi-source context extraction
|
||||
- ✅ DO: Support task IDs, file paths, custom context, and project tree
|
||||
- ✅ DO: Implement fuzzy search for automatic task discovery
|
||||
- ✅ DO: Display detailed token breakdown for transparency
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Follow this pattern for context-aware commands
|
||||
programInstance
|
||||
.command('research')
|
||||
.description('Perform AI-powered research queries with project context')
|
||||
.argument('<prompt>', 'Research prompt to investigate')
|
||||
.option('-i, --id <ids>', 'Comma-separated task/subtask IDs to include as context')
|
||||
.option('-f, --files <paths>', 'Comma-separated file paths to include as context')
|
||||
.option('-c, --context <text>', 'Additional custom context')
|
||||
.option('--tree', 'Include project file tree structure')
|
||||
.option('-d, --detail <level>', 'Output detail level: low, medium, high', 'medium')
|
||||
.action(async (prompt, options) => {
|
||||
// 1. Parameter validation and parsing
|
||||
const taskIds = options.id ? parseTaskIds(options.id) : [];
|
||||
const filePaths = options.files ? parseFilePaths(options.files) : [];
|
||||
|
||||
// 2. Initialize context gatherer
|
||||
const projectRoot = findProjectRoot() || '.';
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// 3. Auto-discover relevant tasks if none specified
|
||||
if (taskIds.length === 0) {
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const discoveredIds = fuzzySearch.getTaskIds(
|
||||
fuzzySearch.findRelevantTasks(prompt)
|
||||
);
|
||||
taskIds.push(...discoveredIds);
|
||||
}
|
||||
|
||||
// 4. Gather context with token breakdown
|
||||
const contextResult = await gatherer.gather({
|
||||
tasks: taskIds,
|
||||
files: filePaths,
|
||||
customContext: options.context,
|
||||
includeProjectTree: options.projectTree,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
|
||||
// 5. Display token breakdown and execute AI call
|
||||
// Implementation continues...
|
||||
});
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- **Exception Management**:
|
||||
|
||||
268
.cursor/rules/context_gathering.mdc
Normal file
268
.cursor/rules/context_gathering.mdc
Normal file
@@ -0,0 +1,268 @@
|
||||
---
|
||||
description: Standardized patterns for gathering and processing context from multiple sources in Task Master commands, particularly for AI-powered features.
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
# Context Gathering Patterns and Utilities
|
||||
|
||||
This document outlines the standardized patterns for gathering and processing context from multiple sources in Task Master commands, particularly for AI-powered features.
|
||||
|
||||
## Core Context Gathering Utility
|
||||
|
||||
The `ContextGatherer` class (`scripts/modules/utils/contextGatherer.js`) provides a centralized, reusable utility for extracting context from multiple sources:
|
||||
|
||||
### **Key Features**
|
||||
- **Multi-source Context**: Tasks, files, custom text, project file tree
|
||||
- **Token Counting**: Detailed breakdown using `gpt-tokens` library
|
||||
- **Format Support**: Different output formats (research, chat, system-prompt)
|
||||
- **Error Handling**: Graceful handling of missing files, invalid task IDs
|
||||
- **Performance**: File size limits, depth limits for tree generation
|
||||
|
||||
### **Usage Pattern**
|
||||
```javascript
|
||||
import { ContextGatherer } from '../utils/contextGatherer.js';
|
||||
|
||||
// Initialize with project paths
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// Gather context with detailed token breakdown
|
||||
const result = await gatherer.gather({
|
||||
tasks: ['15', '16.2'], // Task and subtask IDs
|
||||
files: ['src/api.js', 'README.md'], // File paths
|
||||
customContext: 'Additional context text',
|
||||
includeProjectTree: true, // Include file tree
|
||||
format: 'research', // Output format
|
||||
includeTokenCounts: true // Get detailed token breakdown
|
||||
});
|
||||
|
||||
// Access results
|
||||
const contextString = result.context;
|
||||
const tokenBreakdown = result.tokenBreakdown;
|
||||
```
|
||||
|
||||
### **Token Breakdown Structure**
|
||||
```javascript
|
||||
{
|
||||
customContext: { tokens: 150, characters: 800 },
|
||||
tasks: [
|
||||
{ id: '15', type: 'task', title: 'Task Title', tokens: 245, characters: 1200 },
|
||||
{ id: '16.2', type: 'subtask', title: 'Subtask Title', tokens: 180, characters: 900 }
|
||||
],
|
||||
files: [
|
||||
{ path: 'src/api.js', tokens: 890, characters: 4500, size: '4.5 KB' }
|
||||
],
|
||||
projectTree: { tokens: 320, characters: 1600 },
|
||||
total: { tokens: 1785, characters: 8000 }
|
||||
}
|
||||
```
|
||||
|
||||
## Fuzzy Search Integration
|
||||
|
||||
The `FuzzyTaskSearch` class (`scripts/modules/utils/fuzzyTaskSearch.js`) provides intelligent task discovery:
|
||||
|
||||
### **Key Features**
|
||||
- **Semantic Matching**: Uses Fuse.js for similarity scoring
|
||||
- **Purpose Categories**: Pattern-based task categorization
|
||||
- **Relevance Scoring**: High/medium/low relevance thresholds
|
||||
- **Context-Aware**: Different search configurations for different use cases
|
||||
|
||||
### **Usage Pattern**
|
||||
```javascript
|
||||
import { FuzzyTaskSearch } from '../utils/fuzzyTaskSearch.js';
|
||||
|
||||
// Initialize with tasks data and context
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
|
||||
// Find relevant tasks
|
||||
const searchResults = fuzzySearch.findRelevantTasks(query, {
|
||||
maxResults: 8,
|
||||
includeRecent: true,
|
||||
includeCategoryMatches: true
|
||||
});
|
||||
|
||||
// Get task IDs for context gathering
|
||||
const taskIds = fuzzySearch.getTaskIds(searchResults);
|
||||
```
|
||||
|
||||
## Implementation Patterns for Commands
|
||||
|
||||
### **1. Context-Aware Command Structure**
|
||||
```javascript
|
||||
// In command action handler
|
||||
async function commandAction(prompt, options) {
|
||||
// 1. Parameter validation and parsing
|
||||
const taskIds = options.id ? parseTaskIds(options.id) : [];
|
||||
const filePaths = options.files ? parseFilePaths(options.files) : [];
|
||||
|
||||
// 2. Initialize context gatherer
|
||||
const projectRoot = findProjectRoot() || '.';
|
||||
const tasksPath = path.join(projectRoot, 'tasks', 'tasks.json');
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
|
||||
// 3. Auto-discover relevant tasks if none specified
|
||||
if (taskIds.length === 0) {
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const discoveredIds = fuzzySearch.getTaskIds(
|
||||
fuzzySearch.findRelevantTasks(prompt)
|
||||
);
|
||||
taskIds.push(...discoveredIds);
|
||||
}
|
||||
|
||||
// 4. Gather context with token breakdown
|
||||
const contextResult = await gatherer.gather({
|
||||
tasks: taskIds,
|
||||
files: filePaths,
|
||||
customContext: options.context,
|
||||
includeProjectTree: options.projectTree,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
|
||||
// 5. Display token breakdown (for CLI)
|
||||
if (outputFormat === 'text') {
|
||||
displayDetailedTokenBreakdown(contextResult.tokenBreakdown);
|
||||
}
|
||||
|
||||
// 6. Use context in AI call
|
||||
const aiResult = await generateTextService(role, session, systemPrompt, userPrompt);
|
||||
|
||||
// 7. Display results with enhanced formatting
|
||||
displayResults(aiResult, contextResult.tokenBreakdown);
|
||||
}
|
||||
```
|
||||
|
||||
### **2. Token Display Pattern**
|
||||
```javascript
|
||||
function displayDetailedTokenBreakdown(tokenBreakdown, systemTokens, userTokens) {
|
||||
const sections = [];
|
||||
|
||||
// Build context breakdown
|
||||
if (tokenBreakdown.tasks?.length > 0) {
|
||||
const taskDetails = tokenBreakdown.tasks.map(task =>
|
||||
`${task.type === 'subtask' ? ' ' : ''}${task.id}: ${task.tokens.toLocaleString()}`
|
||||
).join('\n');
|
||||
sections.push(`Tasks (${tokenBreakdown.tasks.reduce((sum, t) => sum + t.tokens, 0).toLocaleString()}):\n${taskDetails}`);
|
||||
}
|
||||
|
||||
if (tokenBreakdown.files?.length > 0) {
|
||||
const fileDetails = tokenBreakdown.files.map(file =>
|
||||
` ${file.path}: ${file.tokens.toLocaleString()} (${file.size})`
|
||||
).join('\n');
|
||||
sections.push(`Files (${tokenBreakdown.files.reduce((sum, f) => sum + f.tokens, 0).toLocaleString()}):\n${fileDetails}`);
|
||||
}
|
||||
|
||||
// Add prompts breakdown
|
||||
sections.push(`Prompts: system ${systemTokens.toLocaleString()}, user ${userTokens.toLocaleString()}`);
|
||||
|
||||
// Display in clean box
|
||||
const content = sections.join('\n\n');
|
||||
console.log(boxen(content, {
|
||||
title: chalk.cyan('Token Usage'),
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'cyan'
|
||||
}));
|
||||
}
|
||||
```
|
||||
|
||||
### **3. Enhanced Result Display Pattern**
|
||||
```javascript
|
||||
function displayResults(result, query, detailLevel, tokenBreakdown) {
|
||||
// Header with query info
|
||||
const header = boxen(
|
||||
chalk.green.bold('Research Results') + '\n\n' +
|
||||
chalk.gray('Query: ') + chalk.white(query) + '\n' +
|
||||
chalk.gray('Detail Level: ') + chalk.cyan(detailLevel),
|
||||
{
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 1, bottom: 0 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'green'
|
||||
}
|
||||
);
|
||||
console.log(header);
|
||||
|
||||
// Process and highlight code blocks
|
||||
const processedResult = processCodeBlocks(result);
|
||||
|
||||
// Main content in clean box
|
||||
const contentBox = boxen(processedResult, {
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'gray'
|
||||
});
|
||||
console.log(contentBox);
|
||||
|
||||
console.log(chalk.green('✓ Research complete'));
|
||||
}
|
||||
```
|
||||
|
||||
## Code Block Enhancement
|
||||
|
||||
### **Syntax Highlighting Pattern**
|
||||
```javascript
|
||||
import { highlight } from 'cli-highlight';
|
||||
|
||||
function processCodeBlocks(text) {
|
||||
return text.replace(/```(\w+)?\n([\s\S]*?)```/g, (match, language, code) => {
|
||||
try {
|
||||
const highlighted = highlight(code.trim(), {
|
||||
language: language || 'javascript',
|
||||
theme: 'default'
|
||||
});
|
||||
return `\n${highlighted}\n`;
|
||||
} catch (error) {
|
||||
return `\n${code.trim()}\n`;
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Integration Guidelines
|
||||
|
||||
### **When to Use Context Gathering**
|
||||
- ✅ **DO**: Use for AI-powered commands that benefit from project context
|
||||
- ✅ **DO**: Use when users might want to reference specific tasks or files
|
||||
- ✅ **DO**: Use for research, analysis, or generation commands
|
||||
- ❌ **DON'T**: Use for simple CRUD operations that don't need AI context
|
||||
|
||||
### **Performance Considerations**
|
||||
- ✅ **DO**: Set reasonable file size limits (50KB default)
|
||||
- ✅ **DO**: Limit project tree depth (3-5 levels)
|
||||
- ✅ **DO**: Provide token counts to help users understand context size
|
||||
- ✅ **DO**: Allow users to control what context is included
|
||||
|
||||
### **Error Handling**
|
||||
- ✅ **DO**: Gracefully handle missing files with warnings
|
||||
- ✅ **DO**: Validate task IDs and provide helpful error messages
|
||||
- ✅ **DO**: Continue processing even if some context sources fail
|
||||
- ✅ **DO**: Provide fallback behavior when context gathering fails
|
||||
|
||||
### **Future Command Integration**
|
||||
Commands that should consider adopting this pattern:
|
||||
- `analyze-complexity` - Could benefit from file context
|
||||
- `expand-task` - Could use related task context
|
||||
- `update-task` - Could reference similar tasks for consistency
|
||||
- `add-task` - Could use project context for better task generation
|
||||
|
||||
## Export Patterns
|
||||
|
||||
### **Context Gatherer Module**
|
||||
```javascript
|
||||
export {
|
||||
ContextGatherer,
|
||||
createContextGatherer // Factory function
|
||||
};
|
||||
```
|
||||
|
||||
### **Fuzzy Search Module**
|
||||
```javascript
|
||||
export {
|
||||
FuzzyTaskSearch,
|
||||
PURPOSE_CATEGORIES,
|
||||
RELEVANCE_THRESHOLDS
|
||||
};
|
||||
```
|
||||
|
||||
This context gathering system provides a foundation for building more intelligent, context-aware commands that can leverage project knowledge to provide better AI-powered assistance.
|
||||
@@ -18,6 +18,7 @@ Task Master offers two primary ways to interact:
|
||||
- Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for details on the MCP architecture and available tools.
|
||||
- A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
- **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
|
||||
- **Note**: MCP tools fully support tagged task lists with complete tag management capabilities.
|
||||
|
||||
2. **`task-master` CLI (For Users & Fallback)**:
|
||||
- The global `task-master` command provides a user-friendly interface for direct terminal interaction.
|
||||
@@ -25,10 +26,43 @@ Task Master offers two primary ways to interact:
|
||||
- Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
|
||||
- The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
|
||||
- Refer to [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc) for a detailed command reference.
|
||||
- **Tagged Task Lists**: CLI fully supports the new tagged system with seamless migration.
|
||||
|
||||
## Tagged Task Lists System
|
||||
|
||||
Task Master now supports **tagged task lists** for multi-context task management:
|
||||
|
||||
- **Data Structure**: Tasks are organized into separate contexts (tags) like "master", "feature-branch", or "v2.0"
|
||||
- **Seamless Migration**: Existing projects automatically migrate to use a "master" tag with zero disruption
|
||||
- **Backward Compatibility**: All existing commands continue to work exactly as before
|
||||
- **Context Isolation**: Tasks in different tags are completely separate and isolated
|
||||
- **Silent Migration**: The first time you run any Task Master command, your existing tasks.json will be automatically migrated to the new tagged format
|
||||
- **Migration Notice**: You'll see a friendly FYI notice after migration explaining the new system
|
||||
|
||||
**Migration Example**:
|
||||
```json
|
||||
// Before (legacy format)
|
||||
{
|
||||
"tasks": [
|
||||
{ "id": 1, "title": "Setup API", ... }
|
||||
]
|
||||
}
|
||||
|
||||
// After (tagged format - automatic)
|
||||
{
|
||||
"master": {
|
||||
"tasks": [
|
||||
{ "id": 1, "title": "Setup API", ... }
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Tag Management**: CLI commands for tag management (`add-tag`, `use-tag`, `list-tags`, `delete-tag`, `rename-tag`, `copy-tag`) are now available with manual git integration via `--from-branch` option.
|
||||
|
||||
## Standard Development Workflow Process
|
||||
|
||||
- Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json
|
||||
- Start new projects by running `initialize_project` tool / `task-master init` or `parse_prd` / `task-master parse-prd --input='<prd-file.txt>'` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to generate initial tasks.json with tagged structure
|
||||
- Begin coding sessions with `get_tasks` / `task-master list` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) to see current tasks, status, and IDs
|
||||
- Determine the next task to work on using `next_task` / `task-master next` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)).
|
||||
- Analyze task complexity with `analyze_project_complexity` / `task-master analyze-complexity --research` (see [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)) before breaking down tasks
|
||||
@@ -107,9 +141,10 @@ Taskmaster configuration is managed through two main mechanisms:
|
||||
1. **`.taskmaster/config.json` File (Primary):**
|
||||
* Located in the project root directory.
|
||||
* Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
|
||||
* **Tagged System Settings**: Includes `global.defaultTag` (defaults to "master") and `tags` section for tag management configuration.
|
||||
* **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
|
||||
* **View/Set specific models via `task-master models` command or `models` MCP tool.**
|
||||
* Created automatically when you run `task-master models --setup` for the first time.
|
||||
* Created automatically when you run `task-master models --setup` for the first time or during tagged system migration.
|
||||
|
||||
2. **Environment Variables (`.env` / `mcp.json`):**
|
||||
* Used **only** for sensitive API keys and specific endpoint URLs.
|
||||
@@ -117,6 +152,11 @@ Taskmaster configuration is managed through two main mechanisms:
|
||||
* For MCP/Cursor integration, configure these keys in the `env` section of `.cursor/mcp.json`.
|
||||
* Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.mdc`).
|
||||
|
||||
3. **`.taskmaster/state.json` File (Tagged System State):**
|
||||
* Tracks current tag context and migration status.
|
||||
* Automatically created during tagged system migration.
|
||||
* Contains: `currentTag`, `lastSwitched`, `migrationNoticeShown`.
|
||||
|
||||
**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
|
||||
**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.cursor/mcp.json`.
|
||||
**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
|
||||
|
||||
404
.cursor/rules/git_workflow.mdc
Normal file
404
.cursor/rules/git_workflow.mdc
Normal file
@@ -0,0 +1,404 @@
|
||||
---
|
||||
description: Git workflow integrated with Task Master for feature development and collaboration
|
||||
globs: "**/*"
|
||||
alwaysApply: true
|
||||
---
|
||||
# Git Workflow with Task Master Integration
|
||||
|
||||
## **Branch Strategy**
|
||||
|
||||
### **Main Branch Protection**
|
||||
- **main** branch contains production-ready code
|
||||
- All feature development happens on task-specific branches
|
||||
- Direct commits to main are prohibited
|
||||
- All changes merge via Pull Requests
|
||||
|
||||
### **Task Branch Naming**
|
||||
```bash
|
||||
# ✅ DO: Use consistent task branch naming
|
||||
task-001 # For Task 1
|
||||
task-004 # For Task 4
|
||||
task-015 # For Task 15
|
||||
|
||||
# ❌ DON'T: Use inconsistent naming
|
||||
feature/user-auth
|
||||
fix-database-issue
|
||||
random-branch-name
|
||||
```
|
||||
|
||||
## **Tagged Task Lists Integration**
|
||||
|
||||
Task Master's **tagged task lists system** provides significant benefits for Git workflows:
|
||||
|
||||
### **Multi-Context Development**
|
||||
- **Branch-Specific Tasks**: Each branch can have its own task context using tags
|
||||
- **Merge Conflict Prevention**: Tasks in different tags are completely isolated
|
||||
- **Context Switching**: Seamlessly switch between different development contexts
|
||||
- **Parallel Development**: Multiple team members can work on separate task contexts
|
||||
|
||||
### **Migration and Compatibility**
|
||||
- **Seamless Migration**: Existing projects automatically migrate to use a "master" tag
|
||||
- **Zero Disruption**: All existing Git workflows continue unchanged
|
||||
- **Backward Compatibility**: Legacy projects work exactly as before
|
||||
|
||||
### **Manual Git Integration**
|
||||
- **Manual Tag Creation**: Use `--from-branch` option to create tags from current git branch
|
||||
- **Manual Context Switching**: Explicitly switch tag contexts as needed for different branches
|
||||
- **Simplified Integration**: Focused on manual control rather than automatic workflows
|
||||
|
||||
## **Workflow Overview**
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Start: On main branch] --> B[Pull latest changes]
|
||||
B --> C[Create task branch<br/>git checkout -b task-XXX]
|
||||
C --> D[Set task status: in-progress]
|
||||
D --> E[Get task context & expand if needed<br/>Tasks automatically use current tag]
|
||||
E --> F[Identify next subtask]
|
||||
|
||||
F --> G[Set subtask: in-progress]
|
||||
G --> H[Research & collect context<br/>update_subtask with findings]
|
||||
H --> I[Implement subtask]
|
||||
I --> J[Update subtask with completion]
|
||||
J --> K[Set subtask: done]
|
||||
K --> L[Git commit subtask]
|
||||
|
||||
L --> M{More subtasks?}
|
||||
M -->|Yes| F
|
||||
M -->|No| N[Run final tests]
|
||||
|
||||
N --> O[Commit tests if added]
|
||||
O --> P[Push task branch]
|
||||
P --> Q[Create Pull Request]
|
||||
Q --> R[Human review & merge]
|
||||
R --> S[Switch to main & pull]
|
||||
S --> T[Delete task branch]
|
||||
T --> U[Ready for next task]
|
||||
|
||||
style A fill:#e1f5fe
|
||||
style C fill:#f3e5f5
|
||||
style G fill:#fff3e0
|
||||
style L fill:#e8f5e8
|
||||
style Q fill:#fce4ec
|
||||
style R fill:#f1f8e9
|
||||
style U fill:#e1f5fe
|
||||
```
|
||||
|
||||
## **Complete Task Development Workflow**
|
||||
|
||||
### **Phase 1: Task Preparation**
|
||||
```bash
|
||||
# 1. Ensure you're on main branch and pull latest
|
||||
git checkout main
|
||||
git pull origin main
|
||||
|
||||
# 2. Check current branch status
|
||||
git branch # Verify you're on main
|
||||
|
||||
# 3. Create task-specific branch
|
||||
git checkout -b task-004 # For Task 4
|
||||
|
||||
# 4. Set task status in Task Master (tasks automatically use current tag context)
|
||||
# Use: set_task_status tool or `task-master set-status --id=4 --status=in-progress`
|
||||
```
|
||||
|
||||
### **Phase 2: Task Analysis & Planning**
|
||||
```bash
|
||||
# 5. Get task context and expand if needed (uses current tag automatically)
|
||||
# Use: get_task tool or `task-master show 4`
|
||||
# Use: expand_task tool or `task-master expand --id=4 --research --force` (if complex)
|
||||
|
||||
# 6. Identify next subtask to work on
|
||||
# Use: next_task tool or `task-master next`
|
||||
```
|
||||
|
||||
### **Phase 3: Subtask Implementation Loop**
|
||||
For each subtask, follow this pattern:
|
||||
|
||||
```bash
|
||||
# 7. Mark subtask as in-progress
|
||||
# Use: set_task_status tool or `task-master set-status --id=4.1 --status=in-progress`
|
||||
|
||||
# 8. Gather context and research (if needed)
|
||||
# Use: update_subtask tool with research flag or:
|
||||
# `task-master update-subtask --id=4.1 --prompt="Research findings..." --research`
|
||||
|
||||
# 9. Collect code context through AI exploration
|
||||
# Document findings in subtask using update_subtask
|
||||
|
||||
# 10. Implement the subtask
|
||||
# Write code, tests, documentation
|
||||
|
||||
# 11. Update subtask with completion details
|
||||
# Use: update_subtask tool or:
|
||||
# `task-master update-subtask --id=4.1 --prompt="Implementation complete..."`
|
||||
|
||||
# 12. Mark subtask as done
|
||||
# Use: set_task_status tool or `task-master set-status --id=4.1 --status=done`
|
||||
|
||||
# 13. Commit the subtask implementation
|
||||
git add .
|
||||
git commit -m "feat(task-4): Complete subtask 4.1 - [Subtask Title]
|
||||
|
||||
- Implementation details
|
||||
- Key changes made
|
||||
- Any important notes
|
||||
|
||||
Subtask 4.1: [Brief description of what was accomplished]
|
||||
Relates to Task 4: [Main task title]"
|
||||
```
|
||||
|
||||
### **Phase 4: Task Completion**
|
||||
```bash
|
||||
# 14. When all subtasks are complete, run final testing
|
||||
# Create test file if needed, ensure all tests pass
|
||||
npm test # or jest, or manual testing
|
||||
|
||||
# 15. If tests were added/modified, commit them
|
||||
git add .
|
||||
git commit -m "test(task-4): Add comprehensive tests for Task 4
|
||||
|
||||
- Unit tests for core functionality
|
||||
- Integration tests for API endpoints
|
||||
- All tests passing
|
||||
|
||||
Task 4: [Main task title] - Testing complete"
|
||||
|
||||
# 16. Push the task branch
|
||||
git push origin task-004
|
||||
|
||||
# 17. Create Pull Request
|
||||
# Title: "Task 4: [Task Title]"
|
||||
# Description should include:
|
||||
# - Task overview
|
||||
# - Subtasks completed
|
||||
# - Testing approach
|
||||
# - Any breaking changes or considerations
|
||||
```
|
||||
|
||||
### **Phase 5: PR Merge & Cleanup**
|
||||
```bash
|
||||
# 18. Human reviews and merges PR into main
|
||||
|
||||
# 19. Switch back to main and pull merged changes
|
||||
git checkout main
|
||||
git pull origin main
|
||||
|
||||
# 20. Delete the feature branch (optional cleanup)
|
||||
git branch -d task-004
|
||||
git push origin --delete task-004
|
||||
```
|
||||
|
||||
## **Commit Message Standards**
|
||||
|
||||
### **Subtask Commits**
|
||||
```bash
|
||||
# ✅ DO: Consistent subtask commit format
|
||||
git commit -m "feat(task-4): Complete subtask 4.1 - Initialize Express server
|
||||
|
||||
- Set up Express.js with TypeScript configuration
|
||||
- Added CORS and body parsing middleware
|
||||
- Implemented health check endpoints
|
||||
- Basic error handling middleware
|
||||
|
||||
Subtask 4.1: Initialize project with npm and install dependencies
|
||||
Relates to Task 4: Setup Express.js Server Project"
|
||||
|
||||
# ❌ DON'T: Vague or inconsistent commits
|
||||
git commit -m "fixed stuff"
|
||||
git commit -m "working on task"
|
||||
```
|
||||
|
||||
### **Test Commits**
|
||||
```bash
|
||||
# ✅ DO: Separate test commits when substantial
|
||||
git commit -m "test(task-4): Add comprehensive tests for Express server setup
|
||||
|
||||
- Unit tests for middleware configuration
|
||||
- Integration tests for health check endpoints
|
||||
- Mock tests for database connection
|
||||
- All tests passing with 95% coverage
|
||||
|
||||
Task 4: Setup Express.js Server Project - Testing complete"
|
||||
```
|
||||
|
||||
### **Commit Type Prefixes**
|
||||
- `feat(task-X):` - New feature implementation
|
||||
- `fix(task-X):` - Bug fixes
|
||||
- `test(task-X):` - Test additions/modifications
|
||||
- `docs(task-X):` - Documentation updates
|
||||
- `refactor(task-X):` - Code refactoring
|
||||
- `chore(task-X):` - Build/tooling changes
|
||||
|
||||
## **Task Master Commands Integration**
|
||||
|
||||
### **Essential Commands for Git Workflow**
|
||||
```bash
|
||||
# Task management (uses current tag context automatically)
|
||||
task-master show <id> # Get task/subtask details
|
||||
task-master next # Find next task to work on
|
||||
task-master set-status --id=<id> --status=<status>
|
||||
task-master update-subtask --id=<id> --prompt="..." --research
|
||||
|
||||
# Task expansion (for complex tasks)
|
||||
task-master expand --id=<id> --research --force
|
||||
|
||||
# Progress tracking
|
||||
task-master list # View all tasks and status
|
||||
task-master list --status=in-progress # View active tasks
|
||||
```
|
||||
|
||||
### **MCP Tool Equivalents**
|
||||
When using Cursor or other MCP-integrated tools:
|
||||
- `get_task` instead of `task-master show`
|
||||
- `next_task` instead of `task-master next`
|
||||
- `set_task_status` instead of `task-master set-status`
|
||||
- `update_subtask` instead of `task-master update-subtask`
|
||||
|
||||
## **Branch Management Rules**
|
||||
|
||||
### **Branch Protection**
|
||||
```bash
|
||||
# ✅ DO: Always work on task branches
|
||||
git checkout -b task-005
|
||||
# Make changes
|
||||
git commit -m "..."
|
||||
git push origin task-005
|
||||
|
||||
# ❌ DON'T: Commit directly to main
|
||||
git checkout main
|
||||
git commit -m "..." # NEVER do this
|
||||
```
|
||||
|
||||
### **Keeping Branches Updated**
|
||||
```bash
|
||||
# ✅ DO: Regularly sync with main (for long-running tasks)
|
||||
git checkout task-005
|
||||
git fetch origin
|
||||
git rebase origin/main # or merge if preferred
|
||||
|
||||
# Resolve any conflicts and continue
|
||||
```
|
||||
|
||||
## **Pull Request Guidelines**
|
||||
|
||||
### **PR Title Format**
|
||||
```
|
||||
Task <ID>: <Task Title>
|
||||
|
||||
Examples:
|
||||
Task 4: Setup Express.js Server Project
|
||||
Task 7: Implement User Authentication
|
||||
Task 12: Add Stripe Payment Integration
|
||||
```
|
||||
|
||||
### **PR Description Template**
|
||||
```markdown
|
||||
## Task Overview
|
||||
Brief description of the main task objective.
|
||||
|
||||
## Subtasks Completed
|
||||
- [x] 4.1: Initialize project with npm and install dependencies
|
||||
- [x] 4.2: Configure TypeScript, ESLint and Prettier
|
||||
- [x] 4.3: Create basic Express app with middleware and health check route
|
||||
|
||||
## Implementation Details
|
||||
- Key architectural decisions made
|
||||
- Important code changes
|
||||
- Any deviations from original plan
|
||||
|
||||
## Testing
|
||||
- [ ] Unit tests added/updated
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Manual testing completed
|
||||
|
||||
## Breaking Changes
|
||||
List any breaking changes or migration requirements.
|
||||
|
||||
## Related Tasks
|
||||
Mention any dependent tasks or follow-up work needed.
|
||||
```
|
||||
|
||||
## **Conflict Resolution**
|
||||
|
||||
### **Task Conflicts with Tagged System**
|
||||
```bash
|
||||
# With tagged task lists, merge conflicts are significantly reduced:
|
||||
# 1. Different branches can use different tag contexts
|
||||
# 2. Tasks in separate tags are completely isolated
|
||||
# 3. Use Task Master's move functionality to reorganize if needed
|
||||
|
||||
# Manual git integration available:
|
||||
# - Use `task-master add-tag --from-branch` to create tags from current branch
|
||||
# - Manually switch contexts with `task-master use-tag <name>`
|
||||
# - Simple, predictable workflow without automatic behavior
|
||||
```
|
||||
|
||||
### **Code Conflicts**
|
||||
```bash
|
||||
# Standard Git conflict resolution
|
||||
git fetch origin
|
||||
git rebase origin/main
|
||||
# Resolve conflicts in files
|
||||
git add .
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
## **Emergency Procedures**
|
||||
|
||||
### **Hotfixes**
|
||||
```bash
|
||||
# For urgent production fixes:
|
||||
git checkout main
|
||||
git pull origin main
|
||||
git checkout -b hotfix-urgent-issue
|
||||
|
||||
# Make minimal fix
|
||||
git commit -m "hotfix: Fix critical production issue
|
||||
|
||||
- Specific fix description
|
||||
- Minimal impact change
|
||||
- Requires immediate deployment"
|
||||
|
||||
git push origin hotfix-urgent-issue
|
||||
# Create emergency PR for immediate review
|
||||
```
|
||||
|
||||
### **Task Abandonment**
|
||||
```bash
|
||||
# If task needs to be abandoned or significantly changed:
|
||||
# 1. Update task status
|
||||
task-master set-status --id=<id> --status=cancelled
|
||||
|
||||
# 2. Clean up branch
|
||||
git checkout main
|
||||
git branch -D task-<id>
|
||||
git push origin --delete task-<id>
|
||||
|
||||
# 3. Document reasoning in task
|
||||
task-master update-task --id=<id> --prompt="Task cancelled due to..."
|
||||
```
|
||||
|
||||
## **Tagged System Benefits for Git Workflows**
|
||||
|
||||
### **Multi-Team Development**
|
||||
- **Isolated Contexts**: Different teams can work on separate tag contexts without conflicts
|
||||
- **Feature Branches**: Each feature branch can have its own task context
|
||||
- **Release Management**: Separate tags for different release versions or environments
|
||||
|
||||
### **Merge Conflict Prevention**
|
||||
- **Context Separation**: Tasks in different tags don't interfere with each other
|
||||
- **Clean Merges**: Reduced likelihood of task-related merge conflicts
|
||||
- **Parallel Development**: Multiple developers can work simultaneously without task conflicts
|
||||
|
||||
### **Manual Git Integration**
|
||||
- **Branch-Based Tag Creation**: Use `--from-branch` option to create tags from current git branch
|
||||
- **Manual Context Management**: Explicitly switch tag contexts as needed
|
||||
- **Predictable Workflow**: Simple, manual control without automatic behavior
|
||||
|
||||
---
|
||||
|
||||
**References:**
|
||||
- [Task Master Workflow](mdc:.cursor/rules/dev_workflow.mdc)
|
||||
- [Architecture Guidelines](mdc:.cursor/rules/architecture.mdc)
|
||||
- [Task Master Commands](mdc:.cursor/rules/taskmaster.mdc)
|
||||
@@ -7,20 +7,20 @@ alwaysApply: true
|
||||
|
||||
This file provides a quick reference to the purpose of each rule file located in the `.cursor/rules` directory.
|
||||
|
||||
- **[`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)**: Describes the high-level architecture of the Task Master CLI application.
|
||||
- **[`architecture.mdc`](mdc:.cursor/rules/architecture.mdc)**: Describes the high-level architecture of the Task Master CLI application, including the new tagged task lists system.
|
||||
- **[`changeset.mdc`](mdc:.cursor/rules/changeset.mdc)**: Guidelines for using Changesets (npm run changeset) to manage versioning and changelogs.
|
||||
- **[`commands.mdc`](mdc:.cursor/rules/commands.mdc)**: Guidelines for implementing CLI commands using Commander.js.
|
||||
- **[`cursor_rules.mdc`](mdc:.cursor/rules/cursor_rules.mdc)**: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
|
||||
- **[`dependencies.mdc`](mdc:.cursor/rules/dependencies.mdc)**: Guidelines for managing task dependencies and relationships.
|
||||
- **[`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)**: Guide for using Task Master to manage task-driven development workflows.
|
||||
- **[`dependencies.mdc`](mdc:.cursor/rules/dependencies.mdc)**: Guidelines for managing task dependencies and relationships across tagged task contexts.
|
||||
- **[`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc)**: Guide for using Task Master to manage task-driven development workflows with tagged task lists support.
|
||||
- **[`glossary.mdc`](mdc:.cursor/rules/glossary.mdc)**: This file; provides a glossary of other Cursor rules.
|
||||
- **[`mcp.mdc`](mdc:.cursor/rules/mcp.mdc)**: Guidelines for implementing and interacting with the Task Master MCP Server.
|
||||
- **[`new_features.mdc`](mdc:.cursor/rules/new_features.mdc)**: Guidelines for integrating new features into the Task Master CLI.
|
||||
- **[`new_features.mdc`](mdc:.cursor/rules/new_features.mdc)**: Guidelines for integrating new features into the Task Master CLI with tagged system considerations.
|
||||
- **[`self_improve.mdc`](mdc:.cursor/rules/self_improve.mdc)**: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
|
||||
- **[`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)**: Comprehensive reference for Taskmaster MCP tools and CLI commands.
|
||||
- **[`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)**: Guidelines for implementing task management operations.
|
||||
- **[`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc)**: Comprehensive reference for Taskmaster MCP tools and CLI commands with tagged task lists information.
|
||||
- **[`tasks.mdc`](mdc:.cursor/rules/tasks.mdc)**: Guidelines for implementing task management operations with tagged task lists system support.
|
||||
- **[`tests.mdc`](mdc:.cursor/rules/tests.mdc)**: Guidelines for implementing and maintaining tests for Task Master CLI.
|
||||
- **[`ui.mdc`](mdc:.cursor/rules/ui.mdc)**: Guidelines for implementing and maintaining user interface components.
|
||||
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions.
|
||||
- **[`utilities.mdc`](mdc:.cursor/rules/utilities.mdc)**: Guidelines for implementing utility functions including tagged task lists utilities.
|
||||
- **[`telemetry.mdc`](mdc:.cursor/rules/telemetry.mdc)**: Guidelines for integrating AI usage telemetry across Task Master.
|
||||
|
||||
|
||||
@@ -24,17 +24,22 @@ alwaysApply: false
|
||||
The standard pattern for adding a feature follows this workflow:
|
||||
|
||||
1. **Core Logic**: Implement the business logic in the appropriate module (e.g., [`task-manager.js`](mdc:scripts/modules/task-manager.js)).
|
||||
2. **AI Integration (If Applicable)**:
|
||||
2. **Context Gathering (If Applicable)**:
|
||||
- For AI-powered commands that benefit from project context, use the standardized context gathering patterns from [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc).
|
||||
- Import `ContextGatherer` and `FuzzyTaskSearch` utilities for reusable context extraction.
|
||||
- Support multiple context types: tasks, files, custom text, project tree.
|
||||
- Implement detailed token breakdown display for transparency.
|
||||
3. **AI Integration (If Applicable)**:
|
||||
- Import necessary service functions (e.g., `generateTextService`, `streamTextService`) from [`ai-services-unified.js`](mdc:scripts/modules/ai-services-unified.js).
|
||||
- Prepare parameters (`role`, `session`, `systemPrompt`, `prompt`).
|
||||
- Call the service function.
|
||||
- Handle the response (direct text or stream object).
|
||||
- **Important**: Prefer `generateTextService` for calls sending large context (like stringified JSON) where incremental display is not needed. See [`ai_services.mdc`](mdc:.cursor/rules/ai_services.mdc) for detailed usage patterns and cautions.
|
||||
3. **UI Components**: Add any display functions to [`ui.js`](mdc:scripts/modules/ui.js) following [`ui.mdc`](mdc:.cursor/rules/ui.mdc).
|
||||
4. **Command Integration**: Add the CLI command to [`commands.js`](mdc:scripts/modules/commands.js) following [`commands.mdc`](mdc:.cursor/rules/commands.mdc).
|
||||
5. **Testing**: Write tests for all components of the feature (following [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
|
||||
6. **Configuration**: Update configuration settings or add new ones in [`config-manager.js`](mdc:scripts/modules/config-manager.js) and ensure getters/setters are appropriate. Update documentation in [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc). Update the `.taskmasterconfig` structure if needed.
|
||||
7. **Documentation**: Update help text and documentation in [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
4. **UI Components**: Add any display functions to [`ui.js`](mdc:scripts/modules/ui.js) following [`ui.mdc`](mdc:.cursor/rules/ui.mdc). Consider enhanced formatting with syntax highlighting for code blocks.
|
||||
5. **Command Integration**: Add the CLI command to [`commands.js`](mdc:scripts/modules/commands.js) following [`commands.mdc`](mdc:.cursor/rules/commands.mdc).
|
||||
6. **Testing**: Write tests for all components of the feature (following [`tests.mdc`](mdc:.cursor/rules/tests.mdc))
|
||||
7. **Configuration**: Update configuration settings or add new ones in [`config-manager.js`](mdc:scripts/modules/config-manager.js) and ensure getters/setters are appropriate. Update documentation in [`utilities.mdc`](mdc:.cursor/rules/utilities.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc). Update the `.taskmasterconfig` structure if needed.
|
||||
8. **Documentation**: Update help text and documentation in [`dev_workflow.mdc`](mdc:.cursor/rules/dev_workflow.mdc) and [`taskmaster.mdc`](mdc:.cursor/rules/taskmaster.mdc).
|
||||
|
||||
## Critical Checklist for New Features
|
||||
|
||||
@@ -629,3 +634,287 @@ When implementing project initialization commands:
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Feature Planning
|
||||
|
||||
- **Core Logic First**:
|
||||
- ✅ DO: Implement core logic in `scripts/modules/` before CLI or MCP interfaces
|
||||
- ✅ DO: Consider tagged task lists system compatibility from the start
|
||||
- ✅ DO: Design functions to work with both legacy and tagged data formats
|
||||
- ✅ DO: Use tag resolution functions (`getTasksForTag`, `setTasksForTag`) for task data access
|
||||
- ❌ DON'T: Directly manipulate tagged data structure in new features
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Design tagged-aware core functions
|
||||
async function newFeatureCore(tasksPath, featureParams, options = {}) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Perform feature logic on tasks array
|
||||
const result = performFeatureLogic(tasks, featureParams);
|
||||
|
||||
// Save back using tag resolution
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
- **Backward Compatibility**:
|
||||
- ✅ DO: Ensure new features work with existing projects seamlessly
|
||||
- ✅ DO: Test with both legacy and tagged task data formats
|
||||
- ✅ DO: Support silent migration during feature usage
|
||||
- ❌ DON'T: Break existing workflows when adding tagged system features
|
||||
|
||||
## CLI Command Implementation
|
||||
|
||||
- **Command Structure**:
|
||||
- ✅ DO: Follow the established pattern in [`commands.js`](mdc:scripts/modules/commands.js)
|
||||
- ✅ DO: Use Commander.js for argument parsing
|
||||
- ✅ DO: Include comprehensive help text and examples
|
||||
- ✅ DO: Support tagged task context awareness
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement CLI commands with tagged system awareness
|
||||
program
|
||||
.command('new-feature')
|
||||
.description('Description of the new feature with tagged task lists support')
|
||||
.option('-t, --tag <tag>', 'Specify tag context (defaults to current tag)')
|
||||
.option('-p, --param <value>', 'Feature-specific parameter')
|
||||
.option('--force', 'Force operation without confirmation')
|
||||
.action(async (options) => {
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) {
|
||||
console.error('Not in a Task Master project directory');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// Use specified tag or current tag
|
||||
const targetTag = options.tag || getCurrentTag() || 'master';
|
||||
|
||||
const result = await newFeatureCore(
|
||||
path.join(projectRoot, '.taskmaster', 'tasks', 'tasks.json'),
|
||||
{ param: options.param },
|
||||
{
|
||||
force: options.force,
|
||||
targetTag: targetTag,
|
||||
outputFormat: 'text'
|
||||
}
|
||||
);
|
||||
|
||||
console.log('Feature executed successfully');
|
||||
} catch (error) {
|
||||
console.error(`Error: ${error.message}`);
|
||||
process.exit(1);
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
- **Error Handling**:
|
||||
- ✅ DO: Provide clear error messages for common failures
|
||||
- ✅ DO: Handle tagged system migration errors gracefully
|
||||
- ✅ DO: Include suggestion for resolution when possible
|
||||
- ✅ DO: Exit with appropriate codes for scripting
|
||||
|
||||
## MCP Tool Implementation
|
||||
|
||||
- **Direct Function Pattern**:
|
||||
- ✅ DO: Create direct function wrappers in `mcp-server/src/core/direct-functions/`
|
||||
- ✅ DO: Follow silent mode patterns to prevent console output interference
|
||||
- ✅ DO: Use `findTasksJsonPath` for consistent path resolution
|
||||
- ✅ DO: Ensure tagged system compatibility
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement MCP direct functions with tagged awareness
|
||||
export async function newFeatureDirect(args, log, context = {}) {
|
||||
try {
|
||||
const tasksPath = findTasksJsonPath(args, log);
|
||||
|
||||
// Enable silent mode for clean MCP responses
|
||||
enableSilentMode();
|
||||
|
||||
try {
|
||||
const result = await newFeatureCore(
|
||||
tasksPath,
|
||||
{ param: args.param },
|
||||
{
|
||||
force: args.force,
|
||||
targetTag: args.tag || 'master', // Support tag specification
|
||||
mcpLog: log,
|
||||
session: context.session,
|
||||
outputFormat: 'json'
|
||||
}
|
||||
);
|
||||
|
||||
return {
|
||||
success: true,
|
||||
data: result,
|
||||
fromCache: false
|
||||
};
|
||||
} finally {
|
||||
disableSilentMode();
|
||||
}
|
||||
} catch (error) {
|
||||
log.error(`Error in newFeatureDirect: ${error.message}`);
|
||||
return {
|
||||
success: false,
|
||||
error: { code: 'FEATURE_ERROR', message: error.message },
|
||||
fromCache: false
|
||||
};
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **Tool Registration**:
|
||||
- ✅ DO: Create tool definitions in `mcp-server/src/tools/`
|
||||
- ✅ DO: Use Zod for parameter validation
|
||||
- ✅ DO: Include optional tag parameter for multi-context support
|
||||
- ✅ DO: Follow established naming conventions
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Register MCP tools with tagged system support
|
||||
export function registerNewFeatureTool(server) {
|
||||
server.addTool({
|
||||
name: "new_feature",
|
||||
description: "Description of the new feature with tagged task lists support",
|
||||
inputSchema: z.object({
|
||||
param: z.string().describe("Feature-specific parameter"),
|
||||
tag: z.string().optional().describe("Target tag context (defaults to current tag)"),
|
||||
force: z.boolean().optional().describe("Force operation without confirmation"),
|
||||
projectRoot: z.string().optional().describe("Project root directory")
|
||||
}),
|
||||
execute: withNormalizedProjectRoot(async (args, { log, session }) => {
|
||||
try {
|
||||
const result = await newFeatureDirect(
|
||||
{ ...args, projectRoot: args.projectRoot },
|
||||
log,
|
||||
{ session }
|
||||
);
|
||||
return handleApiResult(result, log);
|
||||
} catch (error) {
|
||||
return handleApiResult({
|
||||
success: false,
|
||||
error: { code: 'EXECUTION_ERROR', message: error.message }
|
||||
}, log);
|
||||
}
|
||||
})
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- **Unit Tests**:
|
||||
- ✅ DO: Test core logic independently with both data formats
|
||||
- ✅ DO: Mock file system operations appropriately
|
||||
- ✅ DO: Test tag resolution behavior
|
||||
- ✅ DO: Verify migration compatibility
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Test new features with tagged system awareness
|
||||
describe('newFeature', () => {
|
||||
beforeEach(() => {
|
||||
jest.clearAllMocks();
|
||||
});
|
||||
|
||||
it('should work with legacy task format', async () => {
|
||||
const legacyData = { tasks: [/* test data */] };
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(legacyData));
|
||||
|
||||
const result = await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
expect(result).toBeDefined();
|
||||
// Test legacy format handling
|
||||
});
|
||||
|
||||
it('should work with tagged task format', async () => {
|
||||
const taggedData = {
|
||||
master: { tasks: [/* test data */] },
|
||||
feature: { tasks: [/* test data */] }
|
||||
};
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(taggedData));
|
||||
|
||||
const result = await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
expect(result).toBeDefined();
|
||||
// Test tagged format handling
|
||||
});
|
||||
|
||||
it('should handle tag migration during feature usage', async () => {
|
||||
const legacyData = { tasks: [/* test data */] };
|
||||
fs.readFileSync.mockReturnValue(JSON.stringify(legacyData));
|
||||
|
||||
await newFeatureCore('/test/tasks.json', { param: 'test' });
|
||||
|
||||
// Verify migration occurred
|
||||
expect(fs.writeFileSync).toHaveBeenCalledWith(
|
||||
'/test/tasks.json',
|
||||
expect.stringContaining('"master"')
|
||||
);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
- **Integration Tests**:
|
||||
- ✅ DO: Test CLI and MCP interfaces with real task data
|
||||
- ✅ DO: Verify end-to-end workflows across tag contexts
|
||||
- ✅ DO: Test error scenarios and recovery
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
- **Rule Updates**:
|
||||
- ✅ DO: Update relevant `.cursor/rules/*.mdc` files
|
||||
- ✅ DO: Include tagged system considerations in architecture docs
|
||||
- ✅ DO: Add examples showing multi-context usage
|
||||
- ✅ DO: Update workflow documentation as needed
|
||||
|
||||
- **User Documentation**:
|
||||
- ✅ DO: Add feature documentation to `/docs` folder
|
||||
- ✅ DO: Include tagged system usage examples
|
||||
- ✅ DO: Update command reference documentation
|
||||
- ✅ DO: Provide migration notes if relevant
|
||||
|
||||
## Migration Considerations
|
||||
|
||||
- **Silent Migration Support**:
|
||||
- ✅ DO: Ensure new features trigger migration when needed
|
||||
- ✅ DO: Handle migration errors gracefully in feature code
|
||||
- ✅ DO: Test feature behavior with pre-migration projects
|
||||
- ❌ DON'T: Assume projects are already migrated
|
||||
|
||||
- **Tag Context Handling**:
|
||||
- ✅ DO: Default to current tag when not specified
|
||||
- ✅ DO: Support explicit tag selection in advanced features
|
||||
- ✅ DO: Validate tag existence before operations
|
||||
- ✅ DO: Provide clear messaging about tag context
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
- **Efficient Tag Operations**:
|
||||
- ✅ DO: Minimize file I/O operations per feature execution
|
||||
- ✅ DO: Cache tag resolution results when appropriate
|
||||
- ✅ DO: Use streaming for large task datasets
|
||||
- ❌ DON'T: Load all tags when only one is needed
|
||||
|
||||
- **Memory Management**:
|
||||
- ✅ DO: Process large task lists efficiently
|
||||
- ✅ DO: Clean up temporary data structures
|
||||
- ✅ DO: Avoid keeping all tag data in memory simultaneously
|
||||
|
||||
## Deployment and Versioning
|
||||
|
||||
- **Changesets**:
|
||||
- ✅ DO: Create appropriate changesets for new features
|
||||
- ✅ DO: Use semantic versioning (minor for new features)
|
||||
- ✅ DO: Include tagged system information in release notes
|
||||
- ✅ DO: Document breaking changes if any
|
||||
|
||||
- **Feature Flags**:
|
||||
- ✅ DO: Consider feature flags for experimental functionality
|
||||
- ✅ DO: Ensure tagged system features work with flags
|
||||
- ✅ DO: Provide clear documentation about flag usage
|
||||
|
||||
By following these guidelines, new features will integrate smoothly with the Task Master ecosystem while supporting the enhanced tagged task lists system for multi-context development workflows.
|
||||
|
||||
229
.cursor/rules/tags.mdc
Normal file
229
.cursor/rules/tags.mdc
Normal file
@@ -0,0 +1,229 @@
|
||||
---
|
||||
description:
|
||||
globs: scripts/modules/*
|
||||
alwaysApply: false
|
||||
---
|
||||
# Tagged Task Lists Command Patterns
|
||||
|
||||
This document outlines the standardized patterns that **ALL** Task Master commands must follow to properly support the tagged task lists system.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Every command** that reads or writes tasks.json must be tag-aware
|
||||
- **Consistent tag resolution** across all commands using `getCurrentTag(projectRoot)`
|
||||
- **Proper context passing** to core functions with `{ projectRoot, tag }`
|
||||
- **Standardized CLI options** with `--tag <tag>` flag
|
||||
|
||||
## Required Imports
|
||||
|
||||
All command files must import `getCurrentTag`:
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Import getCurrentTag in commands.js
|
||||
import {
|
||||
log,
|
||||
readJSON,
|
||||
writeJSON,
|
||||
findProjectRoot,
|
||||
getCurrentTag
|
||||
} from './utils.js';
|
||||
|
||||
// ✅ DO: Import getCurrentTag in task-manager files
|
||||
import {
|
||||
readJSON,
|
||||
writeJSON,
|
||||
getCurrentTag
|
||||
} from '../utils.js';
|
||||
```
|
||||
|
||||
## CLI Command Pattern
|
||||
|
||||
Every CLI command that operates on tasks must follow this exact pattern:
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Standard tag-aware CLI command pattern
|
||||
programInstance
|
||||
.command('command-name')
|
||||
.description('Command description')
|
||||
.option('-f, --file <file>', 'Path to the tasks file', TASKMASTER_TASKS_FILE)
|
||||
.option('--tag <tag>', 'Specify tag context for task operations') // REQUIRED
|
||||
.action(async (options) => {
|
||||
// 1. Find project root
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) {
|
||||
console.error(chalk.red('Error: Could not find project root.'));
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
// 2. Resolve tag using standard pattern
|
||||
const tag = options.tag || getCurrentTag(projectRoot) || 'master';
|
||||
|
||||
// 3. Call core function with proper context
|
||||
await coreFunction(
|
||||
tasksPath,
|
||||
// ... other parameters ...
|
||||
{ projectRoot, tag } // REQUIRED context object
|
||||
);
|
||||
});
|
||||
```
|
||||
|
||||
## Core Function Pattern
|
||||
|
||||
All core functions in `scripts/modules/task-manager/` must follow this pattern:
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Standard tag-aware core function pattern
|
||||
async function coreFunction(
|
||||
tasksPath,
|
||||
// ... other parameters ...
|
||||
context = {} // REQUIRED context parameter
|
||||
) {
|
||||
const { projectRoot, tag } = context;
|
||||
|
||||
// Use tag-aware readJSON/writeJSON
|
||||
const data = readJSON(tasksPath, projectRoot, tag);
|
||||
|
||||
// ... function logic ...
|
||||
|
||||
writeJSON(tasksPath, data, projectRoot, tag);
|
||||
}
|
||||
```
|
||||
|
||||
## Tag Resolution Priority
|
||||
|
||||
The tag resolution follows this exact priority order:
|
||||
|
||||
1. **Explicit `--tag` flag**: `options.tag`
|
||||
2. **Current active tag**: `getCurrentTag(projectRoot)`
|
||||
3. **Default fallback**: `'master'`
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Standard tag resolution pattern
|
||||
const tag = options.tag || getCurrentTag(projectRoot) || 'master';
|
||||
```
|
||||
|
||||
## Commands Requiring Updates
|
||||
|
||||
### High Priority (Core Task Operations)
|
||||
- [x] `add-task` - ✅ Fixed
|
||||
- [x] `list` - ✅ Fixed
|
||||
- [x] `update-task` - ✅ Fixed
|
||||
- [x] `update-subtask` - ✅ Fixed
|
||||
- [x] `set-status` - ✅ Already correct
|
||||
- [x] `remove-task` - ✅ Already correct
|
||||
- [x] `remove-subtask` - ✅ Fixed
|
||||
- [x] `add-subtask` - ✅ Already correct
|
||||
- [x] `clear-subtasks` - ✅ Fixed
|
||||
- [x] `move-task` - ✅ Already correct
|
||||
|
||||
### Medium Priority (Analysis & Expansion)
|
||||
- [x] `expand` - ✅ Fixed
|
||||
- [ ] `next` - ✅ Fixed
|
||||
- [ ] `show` (get-task) - Needs checking
|
||||
- [ ] `analyze-complexity` - Needs checking
|
||||
- [ ] `generate` - ✅ Fixed
|
||||
|
||||
### Lower Priority (Utilities)
|
||||
- [ ] `research` - Needs checking
|
||||
- [ ] `complexity-report` - Needs checking
|
||||
- [ ] `validate-dependencies` - ✅ Fixed
|
||||
- [ ] `fix-dependencies` - ✅ Fixed
|
||||
- [ ] `add-dependency` - ✅ Fixed
|
||||
- [ ] `remove-dependency` - ✅ Fixed
|
||||
|
||||
## MCP Integration Pattern
|
||||
|
||||
MCP direct functions must also follow the tag-aware pattern:
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Tag-aware MCP direct function
|
||||
export async function coreActionDirect(args, log, context = {}) {
|
||||
const { session } = context;
|
||||
const { projectRoot, tag } = args; // MCP passes these in args
|
||||
|
||||
try {
|
||||
const result = await coreAction(
|
||||
tasksPath,
|
||||
// ... other parameters ...
|
||||
{ projectRoot, tag, session, mcpLog: logWrapper }
|
||||
);
|
||||
|
||||
return { success: true, data: result };
|
||||
} catch (error) {
|
||||
return { success: false, error: { code: 'ERROR_CODE', message: error.message } };
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## File Generation Tag-Aware Naming
|
||||
|
||||
The `generate` command must use tag-aware file naming:
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Tag-aware file naming
|
||||
const taskFileName = targetTag === 'master'
|
||||
? `task_${task.id.toString().padStart(3, '0')}.txt`
|
||||
: `task_${task.id.toString().padStart(3, '0')}_${targetTag}.txt`;
|
||||
```
|
||||
|
||||
**Examples:**
|
||||
- Master tag: `task_001.txt`, `task_002.txt`
|
||||
- Other tags: `task_001_feature.txt`, `task_002_feature.txt`
|
||||
|
||||
## Common Anti-Patterns
|
||||
|
||||
```javascript
|
||||
// ❌ DON'T: Missing getCurrentTag import
|
||||
import { readJSON, writeJSON } from '../utils.js'; // Missing getCurrentTag
|
||||
|
||||
// ❌ DON'T: Hard-coded tag resolution
|
||||
const tag = options.tag || 'master'; // Missing getCurrentTag
|
||||
|
||||
// ❌ DON'T: Missing --tag option
|
||||
.option('-f, --file <file>', 'Path to tasks file') // Missing --tag option
|
||||
|
||||
// ❌ DON'T: Missing context parameter
|
||||
await coreFunction(tasksPath, param1, param2); // Missing { projectRoot, tag }
|
||||
|
||||
// ❌ DON'T: Incorrect readJSON/writeJSON calls
|
||||
const data = readJSON(tasksPath); // Missing projectRoot and tag
|
||||
writeJSON(tasksPath, data); // Missing projectRoot and tag
|
||||
```
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
For each command, verify:
|
||||
|
||||
- [ ] Imports `getCurrentTag` from utils.js
|
||||
- [ ] Has `--tag <tag>` CLI option
|
||||
- [ ] Uses standard tag resolution: `options.tag || getCurrentTag(projectRoot) || 'master'`
|
||||
- [ ] Finds `projectRoot` with error handling
|
||||
- [ ] Passes `{ projectRoot, tag }` context to core functions
|
||||
- [ ] Core functions accept and use context parameter
|
||||
- [ ] Uses `readJSON(tasksPath, projectRoot, tag)` and `writeJSON(tasksPath, data, projectRoot, tag)`
|
||||
|
||||
## Testing Tag Resolution
|
||||
|
||||
Test each command with:
|
||||
|
||||
```bash
|
||||
# Test with explicit tag
|
||||
node bin/task-master command-name --tag test-tag
|
||||
|
||||
# Test with active tag (should use current active tag)
|
||||
node bin/task-master use-tag test-tag
|
||||
node bin/task-master command-name
|
||||
|
||||
# Test with master tag (default)
|
||||
node bin/task-master use-tag master
|
||||
node bin/task-master command-name
|
||||
```
|
||||
|
||||
## Migration Strategy
|
||||
|
||||
1. **Audit Phase**: Systematically check each command against the checklist
|
||||
2. **Fix Phase**: Apply the standard patterns to non-compliant commands
|
||||
3. **Test Phase**: Verify tag resolution works correctly
|
||||
4. **Document Phase**: Update command documentation with tag support
|
||||
|
||||
This ensures consistent, predictable behavior across all Task Master commands and prevents tag deletion bugs.
|
||||
@@ -11,6 +11,8 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
|
||||
**Important:** Several MCP tools involve AI processing... The AI-powered tools include `parse_prd`, `analyze_project_complexity`, `update_subtask`, `update_task`, `update`, `expand_all`, `expand_task`, and `add_task`.
|
||||
|
||||
**🏷️ Tagged Task Lists System:** Task Master now supports **tagged task lists** for multi-context task management. This allows you to maintain separate, isolated lists of tasks for different features, branches, or experiments. Existing projects are seamlessly migrated to use a default "master" tag. Most commands now support a `--tag <name>` flag to specify which context to operate on. If omitted, commands use the currently active tag.
|
||||
|
||||
---
|
||||
|
||||
## Initialization & Setup
|
||||
@@ -37,6 +39,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* `yes`: `Skip prompts and use defaults/provided arguments. Default is false.` (CLI: `-y, --yes`)
|
||||
* **Usage:** Run this once at the beginning of a new project, typically via an integrated tool like Cursor. Operates on the current working directory of the MCP server.
|
||||
* **Important:** Once complete, you *MUST* parse a prd in order to generate tasks. There will be no tasks files until then. The next step after initializing should be to create a PRD using the example PRD in .taskmaster/templates/example_prd.txt.
|
||||
* **Tagging:** Use the `--tag` option to parse the PRD into a specific, non-default tag context. If the tag doesn't exist, it will be created automatically. Example: `task-master parse-prd spec.txt --tag=new-feature`.
|
||||
|
||||
### 2. Parse PRD (`parse_prd`)
|
||||
|
||||
@@ -92,8 +95,9 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **CLI Command:** `task-master list [options]`
|
||||
* **Description:** `List your Taskmaster tasks, optionally filtering by status and showing subtasks.`
|
||||
* **Key Parameters/Options:**
|
||||
* `status`: `Show only Taskmaster tasks matching this status, e.g., 'pending' or 'done'.` (CLI: `-s, --status <status>`)
|
||||
* `status`: `Show only Taskmaster tasks matching this status (or multiple statuses, comma-separated), e.g., 'pending' or 'done,in-progress'.` (CLI: `-s, --status <status>`)
|
||||
* `withSubtasks`: `Include subtasks indented under their parent tasks in the list.` (CLI: `--with-subtasks`)
|
||||
* `tag`: `Specify which tag context to list tasks from. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Get an overview of the project status, often used at the start of a work session.
|
||||
|
||||
@@ -110,11 +114,13 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
|
||||
* **MCP Tool:** `get_task`
|
||||
* **CLI Command:** `task-master show [id] [options]`
|
||||
* **Description:** `Display detailed information for a specific Taskmaster task or subtask by its ID.`
|
||||
* **Description:** `Display detailed information for one or more specific Taskmaster tasks or subtasks by ID.`
|
||||
* **Key Parameters/Options:**
|
||||
* `id`: `Required. The ID of the Taskmaster task, e.g., '15', or subtask, e.g., '15.2', you want to view.` (CLI: `[id]` positional or `-i, --id <id>`)
|
||||
* `id`: `Required. The ID of the Taskmaster task (e.g., '15'), subtask (e.g., '15.2'), or a comma-separated list of IDs ('1,5,10.2') you want to view.` (CLI: `[id]` positional or `-i, --id <id>`)
|
||||
* `tag`: `Specify which tag context to get the task(s) from. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Understand the full details, implementation notes, and test strategy for a specific task before starting work.
|
||||
* **Usage:** Understand the full details for a specific task. When multiple IDs are provided, a summary table is shown.
|
||||
* **CRITICAL INFORMATION** If you need to collect information from multiple tasks, use comma-separated IDs (i.e. 1,2,3) to receive an array of tasks. Do not needlessly get tasks one at a time if you need to get many as that is wasteful.
|
||||
|
||||
---
|
||||
|
||||
@@ -168,13 +174,15 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
|
||||
* **MCP Tool:** `update_task`
|
||||
* **CLI Command:** `task-master update-task [options]`
|
||||
* **Description:** `Modify a specific Taskmaster task or subtask by its ID, incorporating new information or changes.`
|
||||
* **Description:** `Modify a specific Taskmaster task by ID, incorporating new information or changes. By default, this replaces the existing task details.`
|
||||
* **Key Parameters/Options:**
|
||||
* `id`: `Required. The specific ID of the Taskmaster task, e.g., '15', or subtask, e.g., '15.2', you want to update.` (CLI: `-i, --id <id>`)
|
||||
* `id`: `Required. The specific ID of the Taskmaster task, e.g., '15', you want to update.` (CLI: `-i, --id <id>`)
|
||||
* `prompt`: `Required. Explain the specific changes or provide the new information Taskmaster should incorporate into this task.` (CLI: `-p, --prompt <text>`)
|
||||
* `append`: `If true, appends the prompt content to the task's details with a timestamp, rather than replacing them. Behaves like update-subtask.` (CLI: `--append`)
|
||||
* `research`: `Enable Taskmaster to use the research role for more informed updates. Requires appropriate API key.` (CLI: `-r, --research`)
|
||||
* `tag`: `Specify which tag context the task belongs to. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Refine a specific task based on new understanding or feedback. Example CLI: `task-master update-task --id='15' --prompt='Clarification: Use PostgreSQL instead of MySQL.\nUpdate schema details...'`
|
||||
* **Usage:** Refine a specific task based on new understanding. Use `--append` to log progress without creating subtasks.
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
|
||||
|
||||
### 10. Update Subtask (`update_subtask`)
|
||||
@@ -183,12 +191,12 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **CLI Command:** `task-master update-subtask [options]`
|
||||
* **Description:** `Append timestamped notes or details to a specific Taskmaster subtask without overwriting existing content. Intended for iterative implementation logging.`
|
||||
* **Key Parameters/Options:**
|
||||
* `id`: `Required. The specific ID of the Taskmaster subtask, e.g., '15.2', you want to add information to.` (CLI: `-i, --id <id>`)
|
||||
* `prompt`: `Required. Provide the information or notes Taskmaster should append to the subtask's details. Ensure this adds *new* information not already present.` (CLI: `-p, --prompt <text>`)
|
||||
* `research`: `Enable Taskmaster to use the research role for more informed updates. Requires appropriate API key.` (CLI: `-r, --research`)
|
||||
* `id`: `Required. The ID of the Taskmaster task, e.g., '5', or subtask, e.g., '5.2', to permanently remove.` (CLI: `-i, --id <id>`)
|
||||
* `yes`: `Skip the confirmation prompt and immediately delete the task.` (CLI: `-y, --yes`)
|
||||
* `tag`: `Specify which tag context to remove the task from. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Add implementation notes, code snippets, or clarifications to a subtask during development. Before calling, review the subtask's current details to append only fresh insights, helping to build a detailed log of the implementation journey and avoid redundancy. Example CLI: `task-master update-subtask --id='15.2' --prompt='Discovered that the API requires header X.\nImplementation needs adjustment...'`
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
|
||||
* **Usage:** Permanently delete tasks or subtasks that are no longer needed in the project.
|
||||
* **Notes:** Use with caution as this operation cannot be undone. Consider using 'blocked', 'cancelled', or 'deferred' status instead if you just want to exclude a task from active planning but keep it for reference. The command automatically cleans up dependency references in other tasks.
|
||||
|
||||
### 11. Set Task Status (`set_task_status`)
|
||||
|
||||
@@ -228,6 +236,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* `research`: `Enable Taskmaster to use the research role for more informed subtask generation. Requires appropriate API key.` (CLI: `-r, --research`)
|
||||
* `prompt`: `Optional: Provide extra context or specific instructions to Taskmaster for generating the subtasks.` (CLI: `-p, --prompt <text>`)
|
||||
* `force`: `Optional: If true, clear existing subtasks before generating new ones. Default is false (append).` (CLI: `--force`)
|
||||
* `tag`: `Specify which tag context the task belongs to. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Generate a detailed implementation plan for a complex task before starting coding. Automatically uses complexity report recommendations if available and `num` is not specified.
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
|
||||
@@ -242,6 +251,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* `research`: `Enable research role for more informed subtask generation. Requires appropriate API key.` (CLI: `-r, --research`)
|
||||
* `prompt`: `Optional: Provide extra context for Taskmaster to apply generally during expansion.` (CLI: `-p, --prompt <text>`)
|
||||
* `force`: `Optional: If true, clear existing subtasks before generating new ones for each eligible task. Default is false (append).` (CLI: `--force`)
|
||||
* `tag`: `Specify which tag context to expand. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Useful after initial task generation or complexity analysis to break down multiple tasks at once.
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
|
||||
@@ -335,6 +345,7 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **CLI Command:** `task-master fix-dependencies [options]`
|
||||
* **Description:** `Automatically fix dependency issues (like circular references or links to non-existent tasks) in your Taskmaster tasks.`
|
||||
* **Key Parameters/Options:**
|
||||
* `tag`: `Specify which tag context to fix dependencies in. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Clean up dependency errors automatically.
|
||||
|
||||
@@ -348,9 +359,10 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **CLI Command:** `task-master analyze-complexity [options]`
|
||||
* **Description:** `Have Taskmaster analyze your tasks to determine their complexity and suggest which ones need to be broken down further.`
|
||||
* **Key Parameters/Options:**
|
||||
* `output`: `Where to save the complexity analysis report (default: '.taskmaster/reports/task-complexity-report.json').` (CLI: `-o, --output <file>`)
|
||||
* `output`: `Where to save the complexity analysis report. Default is '.taskmaster/reports/task-complexity-report.json' (or '..._tagname.json' if a tag is used).` (CLI: `-o, --output <file>`)
|
||||
* `threshold`: `The minimum complexity score (1-10) that should trigger a recommendation to expand a task.` (CLI: `-t, --threshold <number>`)
|
||||
* `research`: `Enable research role for more accurate complexity analysis. Requires appropriate API key.` (CLI: `-r, --research`)
|
||||
* `tag`: `Specify which tag context to analyze. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Used before breaking down tasks to identify which ones need the most attention.
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. Please inform users to hang tight while the operation is in progress.
|
||||
@@ -375,8 +387,126 @@ This document provides a detailed reference for interacting with Taskmaster, cov
|
||||
* **Description:** `Create or update individual Markdown files for each task based on your tasks.json.`
|
||||
* **Key Parameters/Options:**
|
||||
* `output`: `The directory where Taskmaster should save the task files (default: in a 'tasks' directory).` (CLI: `-o, --output <directory>`)
|
||||
* `tag`: `Specify which tag context to generate files for. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `file`: `Path to your Taskmaster 'tasks.json' file. Default relies on auto-detection.` (CLI: `-f, --file <file>`)
|
||||
* **Usage:** Run this after making changes to tasks.json to keep individual task files up to date.
|
||||
* **Usage:** Run this after making changes to tasks.json to keep individual task files up to date. This command is now manual and no longer runs automatically.
|
||||
|
||||
---
|
||||
|
||||
## AI-Powered Research
|
||||
|
||||
### 25. Research (`research`)
|
||||
|
||||
* **MCP Tool:** `research`
|
||||
* **CLI Command:** `task-master research [options]`
|
||||
* **Description:** `Perform AI-powered research queries with project context to get fresh, up-to-date information beyond the AI's knowledge cutoff.`
|
||||
* **Key Parameters/Options:**
|
||||
* `query`: `Required. Research query/prompt (e.g., "What are the latest best practices for React Query v5?").` (CLI: `[query]` positional or `-q, --query <text>`)
|
||||
* `taskIds`: `Comma-separated list of task/subtask IDs from the current tag context (e.g., "15,16.2,17").` (CLI: `-i, --id <ids>`)
|
||||
* `filePaths`: `Comma-separated list of file paths for context (e.g., "src/api.js,docs/readme.md").` (CLI: `-f, --files <paths>`)
|
||||
* `customContext`: `Additional custom context text to include in the research.` (CLI: `-c, --context <text>`)
|
||||
* `includeProjectTree`: `Include project file tree structure in context (default: false).` (CLI: `--tree`)
|
||||
* `detailLevel`: `Detail level for the research response: 'low', 'medium', 'high' (default: medium).` (CLI: `--detail <level>`)
|
||||
* `saveTo`: `Task or subtask ID (e.g., "15", "15.2") to automatically save the research conversation to.` (CLI: `--save-to <id>`)
|
||||
* `saveFile`: `If true, saves the research conversation to a markdown file in '.taskmaster/docs/research/'.` (CLI: `--save-file`)
|
||||
* `noFollowup`: `Disables the interactive follow-up question menu in the CLI.` (CLI: `--no-followup`)
|
||||
* `tag`: `Specify which tag context to use for task-based context gathering. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
* `projectRoot`: `The directory of the project. Must be an absolute path.` (CLI: Determined automatically)
|
||||
* **Usage:** **This is a POWERFUL tool that agents should use FREQUENTLY** to:
|
||||
* Get fresh information beyond knowledge cutoff dates
|
||||
* Research latest best practices, library updates, security patches
|
||||
* Find implementation examples for specific technologies
|
||||
* Validate approaches against current industry standards
|
||||
* Get contextual advice based on project files and tasks
|
||||
* **When to Consider Using Research:**
|
||||
* **Before implementing any task** - Research current best practices
|
||||
* **When encountering new technologies** - Get up-to-date implementation guidance (libraries, apis, etc)
|
||||
* **For security-related tasks** - Find latest security recommendations
|
||||
* **When updating dependencies** - Research breaking changes and migration guides
|
||||
* **For performance optimization** - Get current performance best practices
|
||||
* **When debugging complex issues** - Research known solutions and workarounds
|
||||
* **Research + Action Pattern:**
|
||||
* Use `research` to gather fresh information
|
||||
* Use `update_subtask` to commit findings with timestamps
|
||||
* Use `update_task` to incorporate research into task details
|
||||
* Use `add_task` with research flag for informed task creation
|
||||
* **Important:** This MCP tool makes AI calls and can take up to a minute to complete. The research provides FRESH data beyond the AI's training cutoff, making it invaluable for current best practices and recent developments.
|
||||
|
||||
---
|
||||
|
||||
## Tag Management
|
||||
|
||||
This new suite of commands allows you to manage different task contexts (tags).
|
||||
|
||||
### 26. List Tags (`tags`)
|
||||
|
||||
* **MCP Tool:** `list_tags`
|
||||
* **CLI Command:** `task-master tags [options]`
|
||||
* **Description:** `List all available tags with task counts, completion status, and other metadata.`
|
||||
* **Key Parameters/Options:**
|
||||
* `--show-metadata`: `Include detailed metadata in the output (e.g., creation date, description).` (CLI: `--show-metadata`)
|
||||
|
||||
### 27. Add Tag (`add_tag`)
|
||||
|
||||
* **MCP Tool:** `add_tag`
|
||||
* **CLI Command:** `task-master add-tag <tagName> [options]`
|
||||
* **Description:** `Create a new, empty tag context, or copy tasks from another tag.`
|
||||
* **Key Parameters/Options:**
|
||||
* `tagName`: `Name of the new tag to create (alphanumeric, hyphens, underscores).` (CLI: `<tagName>` positional)
|
||||
* `--from-branch`: `Creates a tag with a name derived from the current git branch, ignoring the <tagName> argument.` (CLI: `--from-branch`)
|
||||
* `--copy-from-current`: `Copy tasks from the currently active tag to the new tag.` (CLI: `--copy-from-current`)
|
||||
* `--copy-from <tag>`: `Copy tasks from a specific source tag to the new tag.` (CLI: `--copy-from <tag>`)
|
||||
* `--description <text>`: `Provide an optional description for the new tag.` (CLI: `-d, --description <text>`)
|
||||
|
||||
### 28. Delete Tag (`delete_tag`)
|
||||
|
||||
* **MCP Tool:** `delete_tag`
|
||||
* **CLI Command:** `task-master delete-tag <tagName> [options]`
|
||||
* **Description:** `Permanently delete a tag and all of its associated tasks.`
|
||||
* **Key Parameters/Options:**
|
||||
* `tagName`: `Name of the tag to delete.` (CLI: `<tagName>` positional)
|
||||
* `--yes`: `Skip the confirmation prompt.` (CLI: `-y, --yes`)
|
||||
|
||||
### 29. Use Tag (`use_tag`)
|
||||
|
||||
* **MCP Tool:** `use_tag`
|
||||
* **CLI Command:** `task-master use-tag <tagName>`
|
||||
* **Description:** `Switch your active task context to a different tag.`
|
||||
* **Key Parameters/Options:**
|
||||
* `tagName`: `Name of the tag to switch to.` (CLI: `<tagName>` positional)
|
||||
|
||||
### 30. Rename Tag (`rename_tag`)
|
||||
|
||||
* **MCP Tool:** `rename_tag`
|
||||
* **CLI Command:** `task-master rename-tag <oldName> <newName>`
|
||||
* **Description:** `Rename an existing tag.`
|
||||
* **Key Parameters/Options:**
|
||||
* `oldName`: `The current name of the tag.` (CLI: `<oldName>` positional)
|
||||
* `newName`: `The new name for the tag.` (CLI: `<newName>` positional)
|
||||
|
||||
### 31. Copy Tag (`copy_tag`)
|
||||
|
||||
* **MCP Tool:** `copy_tag`
|
||||
* **CLI Command:** `task-master copy-tag <sourceName> <targetName> [options]`
|
||||
* **Description:** `Copy an entire tag context, including all its tasks and metadata, to a new tag.`
|
||||
* **Key Parameters/Options:**
|
||||
* `sourceName`: `Name of the tag to copy from.` (CLI: `<sourceName>` positional)
|
||||
* `targetName`: `Name of the new tag to create.` (CLI: `<targetName>` positional)
|
||||
* `--description <text>`: `Optional description for the new tag.` (CLI: `-d, --description <text>`)
|
||||
|
||||
---
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
### 32. Sync Readme (`sync-readme`) -- experimental
|
||||
|
||||
* **MCP Tool:** N/A
|
||||
* **CLI Command:** `task-master sync-readme [options]`
|
||||
* **Description:** `Exports your task list to your project's README.md file, useful for showcasing progress.`
|
||||
* **Key Parameters/Options:**
|
||||
* `status`: `Filter tasks by status (e.g., 'pending', 'done').` (CLI: `-s, --status <status>`)
|
||||
* `withSubtasks`: `Include subtasks in the export.` (CLI: `--with-subtasks`)
|
||||
* `tag`: `Specify which tag context to export from. Defaults to the current active tag.` (CLI: `--tag <name>`)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,9 +3,19 @@ description: Guidelines for implementing task management operations
|
||||
globs: scripts/modules/task-manager.js
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Task Management Guidelines
|
||||
|
||||
## Tagged Task Lists System
|
||||
|
||||
Task Master now uses a **tagged task lists system** for multi-context task management:
|
||||
|
||||
- **Data Structure**: Tasks are organized into separate contexts (tags) within `tasks.json`
|
||||
- **Legacy Format**: `{"tasks": [...]}`
|
||||
- **Tagged Format**: `{"master": {"tasks": [...]}, "feature-branch": {"tasks": [...]}}`
|
||||
- **Silent Migration**: Legacy format automatically converts to tagged format on first use
|
||||
- **Tag Resolution**: Core functions receive legacy format for 100% backward compatibility
|
||||
- **Default Tag**: "master" is used for all existing and new tasks unless otherwise specified
|
||||
|
||||
## Task Structure Standards
|
||||
|
||||
- **Core Task Properties**:
|
||||
@@ -28,6 +38,25 @@ alwaysApply: false
|
||||
};
|
||||
```
|
||||
|
||||
- **Tagged Data Structure**:
|
||||
- ✅ DO: Access tasks through tag resolution layer
|
||||
- ✅ DO: Use `getTasksForTag(data, tagName)` to retrieve tasks for a specific tag
|
||||
- ✅ DO: Use `setTasksForTag(data, tagName, tasks)` to update tasks for a specific tag
|
||||
- ❌ DON'T: Directly manipulate the tagged structure in core functions
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use tag resolution functions
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Manipulate tasks as normal...
|
||||
|
||||
// Save back to the tagged structure
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
- **Subtask Structure**:
|
||||
- ✅ DO: Use consistent properties across subtasks
|
||||
- ✅ DO: Maintain simple numeric IDs within parent tasks
|
||||
@@ -48,53 +77,56 @@ alwaysApply: false
|
||||
## Task Creation and Parsing
|
||||
|
||||
- **ID Management**:
|
||||
- ✅ DO: Assign unique sequential IDs to tasks
|
||||
- ✅ DO: Calculate the next ID based on existing tasks
|
||||
- ❌ DON'T: Hardcode or reuse IDs
|
||||
- ✅ DO: Assign unique sequential IDs to tasks within each tag context
|
||||
- ✅ DO: Calculate the next ID based on existing tasks in the current tag
|
||||
- ❌ DON'T: Hardcode or reuse IDs within the same tag
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Calculate the next available ID
|
||||
const highestId = Math.max(...data.tasks.map(t => t.id));
|
||||
// ✅ DO: Calculate the next available ID within the current tag
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
const highestId = Math.max(...tasks.map(t => t.id));
|
||||
const nextTaskId = highestId + 1;
|
||||
```
|
||||
|
||||
- **PRD Parsing**:
|
||||
- ✅ DO: Extract tasks from PRD documents using AI
|
||||
- ✅ DO: Create tasks in the current tag context (defaults to "master")
|
||||
- ✅ DO: Provide clear prompts to guide AI task generation
|
||||
- ✅ DO: Validate and clean up AI-generated tasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Validate AI responses
|
||||
try {
|
||||
// Parse the JSON response
|
||||
taskData = JSON.parse(jsonContent);
|
||||
|
||||
// Check that we have the required fields
|
||||
if (!taskData.title || !taskData.description) {
|
||||
throw new Error("Missing required fields in the generated task");
|
||||
}
|
||||
} catch (error) {
|
||||
log('error', "Failed to parse AI's response as valid task JSON:", error);
|
||||
process.exit(1);
|
||||
}
|
||||
// ✅ DO: Parse into current tag context
|
||||
const tasksData = readJSON(tasksPath) || {};
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
|
||||
// Parse tasks and add to current tag
|
||||
const newTasks = await parseTasksFromPRD(prdContent);
|
||||
setTasksForTag(tasksData, currentTag, newTasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
## Task Updates and Modifications
|
||||
|
||||
- **Status Management**:
|
||||
- ✅ DO: Provide functions for updating task status
|
||||
- ✅ DO: Provide functions for updating task status within current tag context
|
||||
- ✅ DO: Handle both individual tasks and subtasks
|
||||
- ✅ DO: Consider subtask status when updating parent tasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle status updates for both tasks and subtasks
|
||||
// ✅ DO: Handle status updates within tagged context
|
||||
async function setTaskStatus(tasksPath, taskIdInput, newStatus) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Check if it's a subtask (e.g., "1.2")
|
||||
if (taskIdInput.includes('.')) {
|
||||
const [parentId, subtaskId] = taskIdInput.split('.').map(id => parseInt(id, 10));
|
||||
|
||||
// Find the parent task and subtask
|
||||
const parentTask = data.tasks.find(t => t.id === parentId);
|
||||
const parentTask = tasks.find(t => t.id === parentId);
|
||||
const subtask = parentTask.subtasks.find(st => st.id === subtaskId);
|
||||
|
||||
// Update subtask status
|
||||
@@ -109,7 +141,7 @@ alwaysApply: false
|
||||
}
|
||||
} else {
|
||||
// Handle regular task
|
||||
const task = data.tasks.find(t => t.id === parseInt(taskIdInput, 10));
|
||||
const task = tasks.find(t => t.id === parseInt(taskIdInput, 10));
|
||||
task.status = newStatus;
|
||||
|
||||
// If marking as done, also mark subtasks
|
||||
@@ -119,16 +151,24 @@ alwaysApply: false
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
// Save updated tasks back to tagged structure
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
}
|
||||
```
|
||||
|
||||
- **Task Expansion**:
|
||||
- ✅ DO: Use AI to generate detailed subtasks
|
||||
- ✅ DO: Use AI to generate detailed subtasks within current tag context
|
||||
- ✅ DO: Consider complexity analysis for subtask counts
|
||||
- ✅ DO: Ensure proper IDs for newly created subtasks
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Generate appropriate subtasks based on complexity
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
if (taskAnalysis) {
|
||||
log('info', `Found complexity analysis for task ${taskId}: Score ${taskAnalysis.complexityScore}/10`);
|
||||
|
||||
@@ -138,6 +178,11 @@ alwaysApply: false
|
||||
log('info', `Using recommended number of subtasks: ${numSubtasks}`);
|
||||
}
|
||||
}
|
||||
|
||||
// Generate subtasks and save back
|
||||
// ... subtask generation logic ...
|
||||
setTasksForTag(tasksData, currentTag, tasks);
|
||||
writeJSON(tasksPath, tasksData);
|
||||
```
|
||||
|
||||
## Task File Generation
|
||||
@@ -155,67 +200,65 @@ alwaysApply: false
|
||||
|
||||
// Format dependencies with their status
|
||||
if (task.dependencies && task.dependencies.length > 0) {
|
||||
content += `# Dependencies: ${formatDependenciesWithStatus(task.dependencies, data.tasks)}\n`;
|
||||
content += `# Dependencies: ${formatDependenciesWithStatus(task.dependencies, tasks)}\n`;
|
||||
} else {
|
||||
content += '# Dependencies: None\n';
|
||||
}
|
||||
```
|
||||
|
||||
- **Subtask Inclusion**:
|
||||
- ✅ DO: Include subtasks in parent task files
|
||||
- ✅ DO: Use consistent indentation for subtask sections
|
||||
- ✅ DO: Display subtask dependencies with proper formatting
|
||||
- **Tagged Context Awareness**:
|
||||
- ✅ DO: Generate task files from current tag context
|
||||
- ✅ DO: Include tag information in generated files
|
||||
- ❌ DON'T: Mix tasks from different tags in file generation
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Format subtasks correctly in task files
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
content += '\n# Subtasks:\n';
|
||||
// ✅ DO: Generate files for current tag context
|
||||
async function generateTaskFiles(tasksPath, outputDir) {
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
task.subtasks.forEach(subtask => {
|
||||
content += `## ${subtask.id}. ${subtask.title} [${subtask.status || 'pending'}]\n`;
|
||||
|
||||
// Format subtask dependencies
|
||||
if (subtask.dependencies && subtask.dependencies.length > 0) {
|
||||
// Format the dependencies
|
||||
content += `### Dependencies: ${formattedDeps}\n`;
|
||||
} else {
|
||||
content += '### Dependencies: None\n';
|
||||
}
|
||||
|
||||
content += `### Description: ${subtask.description || ''}\n`;
|
||||
content += '### Details:\n';
|
||||
content += (subtask.details || '').split('\n').map(line => line).join('\n');
|
||||
content += '\n\n';
|
||||
});
|
||||
// Add tag context to file header
|
||||
let content = `# Tag Context: ${currentTag}\n`;
|
||||
content += `# Task ID: ${task.id}\n`;
|
||||
// ... rest of file generation
|
||||
}
|
||||
```
|
||||
|
||||
## Task Listing and Display
|
||||
|
||||
- **Filtering and Organization**:
|
||||
- ✅ DO: Allow filtering tasks by status
|
||||
- ✅ DO: Allow filtering tasks by status within current tag context
|
||||
- ✅ DO: Handle subtask display in lists
|
||||
- ✅ DO: Use consistent table formats
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement clear filtering and organization
|
||||
// ✅ DO: Implement clear filtering within tag context
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Filter tasks by status if specified
|
||||
const filteredTasks = statusFilter
|
||||
? data.tasks.filter(task =>
|
||||
? tasks.filter(task =>
|
||||
task.status && task.status.toLowerCase() === statusFilter.toLowerCase())
|
||||
: data.tasks;
|
||||
: tasks;
|
||||
```
|
||||
|
||||
- **Progress Tracking**:
|
||||
- ✅ DO: Calculate and display completion statistics
|
||||
- ✅ DO: Calculate and display completion statistics for current tag
|
||||
- ✅ DO: Track both task and subtask completion
|
||||
- ✅ DO: Use visual progress indicators
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Track and display progress
|
||||
// ✅ DO: Track and display progress within tag context
|
||||
const tasksData = readJSON(tasksPath);
|
||||
const currentTag = getCurrentTag() || 'master';
|
||||
const tasks = getTasksForTag(tasksData, currentTag);
|
||||
|
||||
// Calculate completion statistics
|
||||
const totalTasks = data.tasks.length;
|
||||
const completedTasks = data.tasks.filter(task =>
|
||||
const totalTasks = tasks.length;
|
||||
const completedTasks = tasks.filter(task =>
|
||||
task.status === 'done' || task.status === 'completed').length;
|
||||
const completionPercentage = totalTasks > 0 ? (completedTasks / totalTasks) * 100 : 0;
|
||||
|
||||
@@ -223,7 +266,7 @@ alwaysApply: false
|
||||
let totalSubtasks = 0;
|
||||
let completedSubtasks = 0;
|
||||
|
||||
data.tasks.forEach(task => {
|
||||
tasks.forEach(task => {
|
||||
if (task.subtasks && task.subtasks.length > 0) {
|
||||
totalSubtasks += task.subtasks.length;
|
||||
completedSubtasks += task.subtasks.filter(st =>
|
||||
@@ -232,99 +275,52 @@ alwaysApply: false
|
||||
});
|
||||
```
|
||||
|
||||
## Complexity Analysis
|
||||
## Migration and Compatibility
|
||||
|
||||
- **Scoring System**:
|
||||
- ✅ DO: Use AI to analyze task complexity
|
||||
- ✅ DO: Include complexity scores (1-10)
|
||||
- ✅ DO: Generate specific expansion recommendations
|
||||
- **Silent Migration Handling**:
|
||||
- ✅ DO: Implement silent migration in `readJSON()` function
|
||||
- ✅ DO: Detect legacy format and convert automatically
|
||||
- ✅ DO: Preserve all existing task data during migration
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle complexity analysis properly
|
||||
const report = {
|
||||
meta: {
|
||||
generatedAt: new Date().toISOString(),
|
||||
tasksAnalyzed: tasksData.tasks.length,
|
||||
thresholdScore: thresholdScore,
|
||||
projectName: tasksData.meta?.projectName || 'Your Project Name',
|
||||
usedResearch: useResearch
|
||||
},
|
||||
complexityAnalysis: complexityAnalysis
|
||||
};
|
||||
```
|
||||
|
||||
- **Analysis-Based Workflow**:
|
||||
- ✅ DO: Use complexity reports to guide task expansion
|
||||
- ✅ DO: Prioritize complex tasks for more detailed breakdown
|
||||
- ✅ DO: Use expansion prompts from complexity analysis
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Apply complexity analysis to workflow
|
||||
// Sort tasks by complexity if report exists, otherwise by ID
|
||||
if (complexityReport && complexityReport.complexityAnalysis) {
|
||||
log('info', 'Sorting tasks by complexity...');
|
||||
// ✅ DO: Handle silent migration (implemented in utils.js)
|
||||
function readJSON(filepath) {
|
||||
let data = JSON.parse(fs.readFileSync(filepath, 'utf8'));
|
||||
|
||||
// Create a map of task IDs to complexity scores
|
||||
const complexityMap = new Map();
|
||||
complexityReport.complexityAnalysis.forEach(analysis => {
|
||||
complexityMap.set(analysis.taskId, analysis.complexityScore);
|
||||
});
|
||||
// Silent migration for tasks.json files
|
||||
if (data.tasks && Array.isArray(data.tasks) && !data.master && isTasksFile) {
|
||||
const migratedData = {
|
||||
master: {
|
||||
tasks: data.tasks
|
||||
}
|
||||
};
|
||||
writeJSON(filepath, migratedData);
|
||||
data = migratedData;
|
||||
}
|
||||
|
||||
// Sort tasks by complexity score (high to low)
|
||||
tasksToExpand.sort((a, b) => {
|
||||
const scoreA = complexityMap.get(a.id) || 0;
|
||||
const scoreB = complexityMap.get(b.id) || 0;
|
||||
return scoreB - scoreA;
|
||||
});
|
||||
return data;
|
||||
}
|
||||
```
|
||||
|
||||
## Next Task Selection
|
||||
|
||||
- **Eligibility Criteria**:
|
||||
- ✅ DO: Consider dependencies when finding next tasks
|
||||
- ✅ DO: Prioritize by task priority and dependency count
|
||||
- ✅ DO: Skip completed tasks
|
||||
- **Tag Resolution**:
|
||||
- ✅ DO: Use tag resolution functions to maintain backward compatibility
|
||||
- ✅ DO: Return legacy format to core functions
|
||||
- ❌ DON'T: Expose tagged structure to existing core logic
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use proper task prioritization logic
|
||||
function findNextTask(tasks) {
|
||||
// Get all completed task IDs
|
||||
const completedTaskIds = new Set(
|
||||
tasks
|
||||
.filter(t => t.status === 'done' || t.status === 'completed')
|
||||
.map(t => t.id)
|
||||
);
|
||||
// ✅ DO: Use tag resolution layer
|
||||
function getTasksForTag(data, tagName) {
|
||||
if (data.tasks && Array.isArray(data.tasks)) {
|
||||
// Legacy format - return as-is
|
||||
return data.tasks;
|
||||
}
|
||||
|
||||
// Filter for pending tasks whose dependencies are all satisfied
|
||||
const eligibleTasks = tasks.filter(task =>
|
||||
(task.status === 'pending' || task.status === 'in-progress') &&
|
||||
task.dependencies &&
|
||||
task.dependencies.every(depId => completedTaskIds.has(depId))
|
||||
);
|
||||
if (data[tagName] && data[tagName].tasks) {
|
||||
// Tagged format - return tasks for specified tag
|
||||
return data[tagName].tasks;
|
||||
}
|
||||
|
||||
// Sort by priority, dependency count, and ID
|
||||
const priorityValues = { 'high': 3, 'medium': 2, 'low': 1 };
|
||||
|
||||
const nextTask = eligibleTasks.sort((a, b) => {
|
||||
// Priority first
|
||||
const priorityA = priorityValues[a.priority || 'medium'] || 2;
|
||||
const priorityB = priorityValues[b.priority || 'medium'] || 2;
|
||||
|
||||
if (priorityB !== priorityA) {
|
||||
return priorityB - priorityA; // Higher priority first
|
||||
}
|
||||
|
||||
// Dependency count next
|
||||
if (a.dependencies.length !== b.dependencies.length) {
|
||||
return a.dependencies.length - b.dependencies.length; // Fewer dependencies first
|
||||
}
|
||||
|
||||
// ID last
|
||||
return a.id - b.id; // Lower ID first
|
||||
})[0];
|
||||
|
||||
return nextTask;
|
||||
return [];
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -150,4 +150,91 @@ alwaysApply: false
|
||||
));
|
||||
```
|
||||
|
||||
Refer to [`ui.js`](mdc:scripts/modules/ui.js) for implementation examples and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines.
|
||||
## Enhanced Display Patterns
|
||||
|
||||
### **Token Breakdown Display**
|
||||
- Use detailed, granular token breakdowns for AI-powered commands
|
||||
- Display context sources with individual token counts
|
||||
- Show both token count and character count for transparency
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Display detailed token breakdown
|
||||
function displayDetailedTokenBreakdown(tokenBreakdown, systemTokens, userTokens) {
|
||||
const sections = [];
|
||||
|
||||
if (tokenBreakdown.tasks?.length > 0) {
|
||||
const taskDetails = tokenBreakdown.tasks.map(task =>
|
||||
`${task.type === 'subtask' ? ' ' : ''}${task.id}: ${task.tokens.toLocaleString()}`
|
||||
).join('\n');
|
||||
sections.push(`Tasks (${tokenBreakdown.tasks.reduce((sum, t) => sum + t.tokens, 0).toLocaleString()}):\n${taskDetails}`);
|
||||
}
|
||||
|
||||
const content = sections.join('\n\n');
|
||||
console.log(boxen(content, {
|
||||
title: chalk.cyan('Token Usage'),
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'cyan'
|
||||
}));
|
||||
}
|
||||
```
|
||||
|
||||
### **Code Block Syntax Highlighting**
|
||||
- Use `cli-highlight` library for syntax highlighting in terminal output
|
||||
- Process code blocks in AI responses for better readability
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Enhance code blocks with syntax highlighting
|
||||
import { highlight } from 'cli-highlight';
|
||||
|
||||
function processCodeBlocks(text) {
|
||||
return text.replace(/```(\w+)?\n([\s\S]*?)```/g, (match, language, code) => {
|
||||
try {
|
||||
const highlighted = highlight(code.trim(), {
|
||||
language: language || 'javascript',
|
||||
theme: 'default'
|
||||
});
|
||||
return `\n${highlighted}\n`;
|
||||
} catch (error) {
|
||||
return `\n${code.trim()}\n`;
|
||||
}
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### **Multi-Section Result Display**
|
||||
- Use separate boxes for headers, content, and metadata
|
||||
- Maintain consistent styling across different result types
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use structured result display
|
||||
function displayResults(result, query, detailLevel) {
|
||||
// Header with query info
|
||||
const header = boxen(
|
||||
chalk.green.bold('Research Results') + '\n\n' +
|
||||
chalk.gray('Query: ') + chalk.white(query) + '\n' +
|
||||
chalk.gray('Detail Level: ') + chalk.cyan(detailLevel),
|
||||
{
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 1, bottom: 0 },
|
||||
borderStyle: 'round',
|
||||
borderColor: 'green'
|
||||
}
|
||||
);
|
||||
console.log(header);
|
||||
|
||||
// Process and display main content
|
||||
const processedResult = processCodeBlocks(result);
|
||||
const contentBox = boxen(processedResult, {
|
||||
padding: { top: 1, bottom: 1, left: 2, right: 2 },
|
||||
margin: { top: 0, bottom: 1 },
|
||||
borderStyle: 'single',
|
||||
borderColor: 'gray'
|
||||
});
|
||||
console.log(contentBox);
|
||||
|
||||
console.log(chalk.green('✓ Operation complete'));
|
||||
}
|
||||
```
|
||||
|
||||
Refer to [`ui.js`](mdc:scripts/modules/ui.js) for implementation examples, [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for context display patterns, and [`new_features.mdc`](mdc:.cursor/rules/new_features.mdc) for integration guidelines.
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
description: Guidelines for implementing utility functions
|
||||
globs: scripts/modules/utils.js, mcp-server/src/**/*
|
||||
description:
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
# Utility Function Guidelines
|
||||
@@ -46,7 +46,7 @@ alwaysApply: false
|
||||
- **Location**:
|
||||
- **Core CLI Utilities**: Place utilities used primarily by the core `task-master` CLI logic and command modules (`scripts/modules/*`) into [`scripts/modules/utils.js`](mdc:scripts/modules/utils.js).
|
||||
- **MCP Server Utilities**: Place utilities specifically designed to support the MCP server implementation into the appropriate subdirectories within `mcp-server/src/`.
|
||||
- Path/Core Logic Helpers: [`mcp-server/src/core/utils/`](mdc:mcp-server/src/core/utils/) (e.g., `path-utils.js`).
|
||||
- Path/Core Logic Helpers: [`mcp-server/src/core/utils/`](mdc:mcp-server/src/core/utils) (e.g., `path-utils.js`).
|
||||
- Tool Execution/Response Helpers: [`mcp-server/src/tools/utils.js`](mdc:mcp-server/src/tools/utils.js).
|
||||
|
||||
## Documentation Standards
|
||||
@@ -110,7 +110,7 @@ Taskmaster configuration (excluding API keys) is primarily managed through the `
|
||||
- ✅ DO: Use appropriate icons for different log levels
|
||||
- ✅ DO: Respect the configured log level
|
||||
- ❌ DON'T: Add direct console.log calls outside the logging utility
|
||||
- **Note on Passed Loggers**: When a logger object (like the FastMCP `log` object) is passed *as a parameter* (e.g., as `mcpLog`) into core Task Master functions, the receiving function often expects specific methods (`.info`, `.warn`, `.error`, etc.) to be directly callable on that object (e.g., `mcpLog[level](...)`). If the passed logger doesn't have this exact structure, a wrapper object may be needed. See the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for the standard pattern used in direct functions.
|
||||
- **Note on Passed Loggers**: When a logger object (like the FastMCP `log` object) is passed *as a parameter* (e.g., as `mcpLog`) into core Task Master functions, the receiving function often expects specific methods (`.info`, `.warn`, `.error`, etc.) to be directly callable on that object (e.g., `mcpLog[level](mdc:...)`). If the passed logger doesn't have this exact structure, a wrapper object may be needed. See the **Handling Logging Context (`mcpLog`)** section in [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) for the standard pattern used in direct functions.
|
||||
|
||||
- **Logger Wrapper Pattern**:
|
||||
- ✅ DO: Use the logger wrapper pattern when passing loggers to prevent `mcpLog[level] is not a function` errors:
|
||||
@@ -548,4 +548,628 @@ export {
|
||||
};
|
||||
```
|
||||
|
||||
Refer to [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
## Context Gathering Utilities
|
||||
|
||||
### **ContextGatherer** (`scripts/modules/utils/contextGatherer.js`)
|
||||
|
||||
- **Multi-Source Context Extraction**:
|
||||
- ✅ DO: Use for AI-powered commands that need project context
|
||||
- ✅ DO: Support tasks, files, custom text, and project tree context
|
||||
- ✅ DO: Implement detailed token counting with `gpt-tokens` library
|
||||
- ✅ DO: Provide multiple output formats (research, chat, system-prompt)
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use ContextGatherer for consistent context extraction
|
||||
import { ContextGatherer } from '../utils/contextGatherer.js';
|
||||
|
||||
const gatherer = new ContextGatherer(projectRoot, tasksPath);
|
||||
const result = await gatherer.gather({
|
||||
tasks: ['15', '16.2'],
|
||||
files: ['src/api.js'],
|
||||
customContext: 'Additional context',
|
||||
includeProjectTree: true,
|
||||
format: 'research',
|
||||
includeTokenCounts: true
|
||||
});
|
||||
```
|
||||
|
||||
### **FuzzyTaskSearch** (`scripts/modules/utils/fuzzyTaskSearch.js`)
|
||||
|
||||
- **Intelligent Task Discovery**:
|
||||
- ✅ DO: Use for automatic task relevance detection
|
||||
- ✅ DO: Configure search parameters based on use case context
|
||||
- ✅ DO: Implement purpose-based categorization for better matching
|
||||
- ✅ DO: Sort results by relevance score and task ID
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use FuzzyTaskSearch for intelligent task discovery
|
||||
import { FuzzyTaskSearch } from '../utils/fuzzyTaskSearch.js';
|
||||
|
||||
const fuzzySearch = new FuzzyTaskSearch(tasksData.tasks, 'research');
|
||||
const searchResults = fuzzySearch.findRelevantTasks(query, {
|
||||
maxResults: 8,
|
||||
includeRecent: true,
|
||||
includeCategoryMatches: true
|
||||
});
|
||||
const taskIds = fuzzySearch.getTaskIds(searchResults);
|
||||
```
|
||||
|
||||
- **Integration Guidelines**:
|
||||
- ✅ DO: Use fuzzy search to supplement user-provided task IDs
|
||||
- ✅ DO: Display discovered task IDs to users for transparency
|
||||
- ✅ DO: Sort discovered task IDs numerically for better readability
|
||||
- ❌ DON'T: Replace explicit user task selections with fuzzy results
|
||||
|
||||
Refer to [`context_gathering.mdc`](mdc:.cursor/rules/context_gathering.mdc) for detailed implementation patterns, [`mcp.mdc`](mdc:.cursor/rules/mcp.mdc) and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for more context on MCP server architecture and integration.
|
||||
|
||||
## File System Operations
|
||||
|
||||
- **JSON File Handling**:
|
||||
- ✅ DO: Use `readJSON` and `writeJSON` for all JSON operations
|
||||
- ✅ DO: Include error handling for file operations
|
||||
- ✅ DO: Validate JSON structure after reading
|
||||
- ❌ DON'T: Use raw `fs.readFileSync` or `fs.writeFileSync` for JSON
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Use utility functions with error handling
|
||||
function readJSON(filepath) {
|
||||
try {
|
||||
if (!fs.existsSync(filepath)) {
|
||||
return null; // or appropriate default
|
||||
}
|
||||
|
||||
let data = JSON.parse(fs.readFileSync(filepath, 'utf8'));
|
||||
|
||||
// Silent migration for tasks.json files: Transform old format to tagged format
|
||||
const isTasksFile = filepath.includes('tasks.json') || path.basename(filepath) === 'tasks.json';
|
||||
|
||||
if (data && data.tasks && Array.isArray(data.tasks) && !data.master && isTasksFile) {
|
||||
// Migrate from old format { "tasks": [...] } to new format { "master": { "tasks": [...] } }
|
||||
const migratedData = {
|
||||
master: {
|
||||
tasks: data.tasks
|
||||
}
|
||||
};
|
||||
|
||||
writeJSON(filepath, migratedData);
|
||||
|
||||
// Set global flag for CLI notice and perform complete migration
|
||||
global.taskMasterMigrationOccurred = true;
|
||||
performCompleteTagMigration(filepath);
|
||||
|
||||
data = migratedData;
|
||||
}
|
||||
|
||||
return data;
|
||||
} catch (error) {
|
||||
log('error', `Failed to read JSON from ${filepath}: ${error.message}`);
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
function writeJSON(filepath, data) {
|
||||
try {
|
||||
const dirPath = path.dirname(filepath);
|
||||
if (!fs.existsSync(dirPath)) {
|
||||
fs.mkdirSync(dirPath, { recursive: true });
|
||||
}
|
||||
fs.writeFileSync(filepath, JSON.stringify(data, null, 2));
|
||||
} catch (error) {
|
||||
log('error', `Failed to write JSON to ${filepath}: ${error.message}`);
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **Path Resolution**:
|
||||
- ✅ DO: Use `path.join()` for cross-platform path construction
|
||||
- ✅ DO: Use `path.resolve()` for absolute paths
|
||||
- ✅ DO: Validate paths before file operations
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Handle paths correctly
|
||||
function findProjectRoot(startPath = process.cwd()) {
|
||||
let currentPath = path.resolve(startPath);
|
||||
const rootPath = path.parse(currentPath).root;
|
||||
|
||||
while (currentPath !== rootPath) {
|
||||
const taskMasterPath = path.join(currentPath, '.taskmaster');
|
||||
if (fs.existsSync(taskMasterPath)) {
|
||||
return currentPath;
|
||||
}
|
||||
currentPath = path.dirname(currentPath);
|
||||
}
|
||||
|
||||
return null; // Not found
|
||||
}
|
||||
```
|
||||
|
||||
## Tagged Task Lists System Utilities
|
||||
|
||||
- **Tag Resolution Functions**:
|
||||
- ✅ DO: Use tag resolution layer for all task data access
|
||||
- ✅ DO: Provide backward compatibility with legacy format
|
||||
- ✅ DO: Default to "master" tag when no tag is specified
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement tag resolution functions
|
||||
function getTasksForTag(data, tagName = 'master') {
|
||||
if (!data) {
|
||||
return [];
|
||||
}
|
||||
|
||||
// Handle legacy format - direct tasks array
|
||||
if (data.tasks && Array.isArray(data.tasks)) {
|
||||
return data.tasks;
|
||||
}
|
||||
|
||||
// Handle tagged format - tasks under specific tag
|
||||
if (data[tagName] && data[tagName].tasks && Array.isArray(data[tagName].tasks)) {
|
||||
return data[tagName].tasks;
|
||||
}
|
||||
|
||||
return [];
|
||||
}
|
||||
|
||||
function setTasksForTag(data, tagName = 'master', tasks) {
|
||||
// Ensure data object exists
|
||||
if (!data) {
|
||||
data = {};
|
||||
}
|
||||
|
||||
// Create tag structure if it doesn't exist
|
||||
if (!data[tagName]) {
|
||||
data[tagName] = {};
|
||||
}
|
||||
|
||||
// Set tasks for the tag
|
||||
data[tagName].tasks = tasks;
|
||||
|
||||
return data;
|
||||
}
|
||||
|
||||
function getCurrentTag() {
|
||||
// Get current tag from state.json or default to 'master'
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) return 'master';
|
||||
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
if (fs.existsSync(statePath)) {
|
||||
const state = readJSON(statePath);
|
||||
return state.currentTag || 'master';
|
||||
}
|
||||
} catch (error) {
|
||||
log('debug', `Error reading current tag: ${error.message}`);
|
||||
}
|
||||
|
||||
return 'master';
|
||||
}
|
||||
```
|
||||
|
||||
- **Migration Functions**:
|
||||
- ✅ DO: Implement complete migration for all related files
|
||||
- ✅ DO: Handle configuration and state file creation
|
||||
- ✅ DO: Provide migration status tracking
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement complete migration system
|
||||
function performCompleteTagMigration(tasksJsonPath) {
|
||||
try {
|
||||
// Derive project root from tasks.json path
|
||||
const projectRoot = findProjectRoot(path.dirname(tasksJsonPath)) || path.dirname(tasksJsonPath);
|
||||
|
||||
// 1. Migrate config.json - add defaultTag and tags section
|
||||
const configPath = path.join(projectRoot, '.taskmaster', 'config.json');
|
||||
if (fs.existsSync(configPath)) {
|
||||
migrateConfigJson(configPath);
|
||||
}
|
||||
|
||||
// 2. Create state.json if it doesn't exist
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
if (!fs.existsSync(statePath)) {
|
||||
createStateJson(statePath);
|
||||
}
|
||||
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Completed tagged task lists migration for project');
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error during complete tag migration: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function migrateConfigJson(configPath) {
|
||||
try {
|
||||
const config = readJSON(configPath);
|
||||
if (!config) return;
|
||||
|
||||
let modified = false;
|
||||
|
||||
// Add global.defaultTag if missing
|
||||
if (!config.global) {
|
||||
config.global = {};
|
||||
}
|
||||
if (!config.global.defaultTag) {
|
||||
config.global.defaultTag = 'master';
|
||||
modified = true;
|
||||
}
|
||||
|
||||
// Add tags section if missing
|
||||
if (!config.tags) {
|
||||
config.tags = {
|
||||
// Git integration settings removed - now manual only
|
||||
};
|
||||
modified = true;
|
||||
}
|
||||
|
||||
if (modified) {
|
||||
writeJSON(configPath, config);
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Updated config.json with tagged task system settings');
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error migrating config.json: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function createStateJson(statePath) {
|
||||
try {
|
||||
const initialState = {
|
||||
currentTag: 'master',
|
||||
lastSwitched: new Date().toISOString(),
|
||||
migrationNoticeShown: false
|
||||
};
|
||||
|
||||
writeJSON(statePath, initialState);
|
||||
if (getDebugFlag()) {
|
||||
log('debug', 'Created initial state.json for tagged task system');
|
||||
}
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error creating state.json: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function markMigrationForNotice() {
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (!projectRoot) return;
|
||||
|
||||
const statePath = path.join(projectRoot, '.taskmaster', 'state.json');
|
||||
const state = readJSON(statePath) || {};
|
||||
|
||||
state.migrationNoticeShown = false; // Reset to show notice
|
||||
writeJSON(statePath, state);
|
||||
} catch (error) {
|
||||
if (getDebugFlag()) {
|
||||
log('warn', `Error marking migration for notice: ${error.message}`);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Logging Functions
|
||||
|
||||
- **Consistent Logging**:
|
||||
- ✅ DO: Use the central `log` function for all output
|
||||
- ✅ DO: Use appropriate log levels (info, warn, error, debug)
|
||||
- ✅ DO: Support silent mode for programmatic usage
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement consistent logging with silent mode
|
||||
let silentMode = false;
|
||||
|
||||
function log(level, ...messages) {
|
||||
if (silentMode && level !== 'error') {
|
||||
return; // Suppress non-error logs in silent mode
|
||||
}
|
||||
|
||||
const timestamp = new Date().toISOString();
|
||||
const formattedMessage = messages.join(' ');
|
||||
|
||||
switch (level) {
|
||||
case 'error':
|
||||
console.error(`[ERROR] ${formattedMessage}`);
|
||||
break;
|
||||
case 'warn':
|
||||
console.warn(`[WARN] ${formattedMessage}`);
|
||||
break;
|
||||
case 'info':
|
||||
console.log(`[INFO] ${formattedMessage}`);
|
||||
break;
|
||||
case 'debug':
|
||||
if (getDebugFlag()) {
|
||||
console.log(`[DEBUG] ${formattedMessage}`);
|
||||
}
|
||||
break;
|
||||
default:
|
||||
console.log(formattedMessage);
|
||||
}
|
||||
}
|
||||
|
||||
function enableSilentMode() {
|
||||
silentMode = true;
|
||||
}
|
||||
|
||||
function disableSilentMode() {
|
||||
silentMode = false;
|
||||
}
|
||||
|
||||
function isSilentMode() {
|
||||
return silentMode;
|
||||
}
|
||||
```
|
||||
|
||||
## Task Utilities
|
||||
|
||||
- **Task Finding and Manipulation**:
|
||||
- ✅ DO: Use tagged task system aware functions
|
||||
- ✅ DO: Handle both task and subtask operations
|
||||
- ✅ DO: Validate task IDs before operations
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement tag-aware task utilities
|
||||
function findTaskById(tasks, taskId) {
|
||||
if (!Array.isArray(tasks)) {
|
||||
return null;
|
||||
}
|
||||
return tasks.find(task => task.id === taskId) || null;
|
||||
}
|
||||
|
||||
function findSubtaskById(tasks, parentId, subtaskId) {
|
||||
const parentTask = findTaskById(tasks, parentId);
|
||||
if (!parentTask || !parentTask.subtasks) {
|
||||
return null;
|
||||
}
|
||||
|
||||
return parentTask.subtasks.find(subtask => subtask.id === subtaskId) || null;
|
||||
}
|
||||
|
||||
function getNextTaskId(tasks) {
|
||||
if (!Array.isArray(tasks) || tasks.length === 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
const maxId = Math.max(...tasks.map(task => task.id));
|
||||
return maxId + 1;
|
||||
}
|
||||
|
||||
function getNextSubtaskId(parentTask) {
|
||||
if (!parentTask.subtasks || parentTask.subtasks.length === 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
const maxId = Math.max(...parentTask.subtasks.map(subtask => subtask.id));
|
||||
return maxId + 1;
|
||||
}
|
||||
```
|
||||
|
||||
## String Utilities
|
||||
|
||||
- **Text Processing**:
|
||||
- ✅ DO: Handle text truncation appropriately
|
||||
- ✅ DO: Provide consistent formatting functions
|
||||
- ✅ DO: Support different output formats
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement useful string utilities
|
||||
function truncate(str, maxLength = 50) {
|
||||
if (!str || typeof str !== 'string') {
|
||||
return '';
|
||||
}
|
||||
|
||||
if (str.length <= maxLength) {
|
||||
return str;
|
||||
}
|
||||
|
||||
return str.substring(0, maxLength - 3) + '...';
|
||||
}
|
||||
|
||||
function formatDuration(ms) {
|
||||
const seconds = Math.floor(ms / 1000);
|
||||
const minutes = Math.floor(seconds / 60);
|
||||
const hours = Math.floor(minutes / 60);
|
||||
|
||||
if (hours > 0) {
|
||||
return `${hours}h ${minutes % 60}m ${seconds % 60}s`;
|
||||
} else if (minutes > 0) {
|
||||
return `${minutes}m ${seconds % 60}s`;
|
||||
} else {
|
||||
return `${seconds}s`;
|
||||
}
|
||||
}
|
||||
|
||||
function capitalizeFirst(str) {
|
||||
if (!str || typeof str !== 'string') {
|
||||
return '';
|
||||
}
|
||||
|
||||
return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
|
||||
}
|
||||
```
|
||||
|
||||
## Dependency Management Utilities
|
||||
|
||||
- **Dependency Analysis**:
|
||||
- ✅ DO: Detect circular dependencies
|
||||
- ✅ DO: Validate dependency references
|
||||
- ✅ DO: Support cross-tag dependency checking (future enhancement)
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement dependency utilities
|
||||
function findCycles(tasks) {
|
||||
const cycles = [];
|
||||
const visited = new Set();
|
||||
const recStack = new Set();
|
||||
|
||||
function dfs(taskId, path = []) {
|
||||
if (recStack.has(taskId)) {
|
||||
// Found a cycle
|
||||
const cycleStart = path.indexOf(taskId);
|
||||
const cycle = path.slice(cycleStart).concat([taskId]);
|
||||
cycles.push(cycle);
|
||||
return;
|
||||
}
|
||||
|
||||
if (visited.has(taskId)) {
|
||||
return;
|
||||
}
|
||||
|
||||
visited.add(taskId);
|
||||
recStack.add(taskId);
|
||||
|
||||
const task = findTaskById(tasks, taskId);
|
||||
if (task && task.dependencies) {
|
||||
task.dependencies.forEach(depId => {
|
||||
dfs(depId, path.concat([taskId]));
|
||||
});
|
||||
}
|
||||
|
||||
recStack.delete(taskId);
|
||||
}
|
||||
|
||||
tasks.forEach(task => {
|
||||
if (!visited.has(task.id)) {
|
||||
dfs(task.id);
|
||||
}
|
||||
});
|
||||
|
||||
return cycles;
|
||||
}
|
||||
|
||||
function validateDependencies(tasks) {
|
||||
const validationErrors = [];
|
||||
const taskIds = new Set(tasks.map(task => task.id));
|
||||
|
||||
tasks.forEach(task => {
|
||||
if (task.dependencies) {
|
||||
task.dependencies.forEach(depId => {
|
||||
if (!taskIds.has(depId)) {
|
||||
validationErrors.push({
|
||||
taskId: task.id,
|
||||
invalidDependency: depId,
|
||||
message: `Task ${task.id} depends on non-existent task ${depId}`
|
||||
});
|
||||
}
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
return validationErrors;
|
||||
}
|
||||
```
|
||||
|
||||
## Environment and Configuration Utilities
|
||||
|
||||
- **Environment Variable Resolution**:
|
||||
- ✅ DO: Support both `.env` files and MCP session environment
|
||||
- ✅ DO: Provide fallbacks for missing values
|
||||
- ✅ DO: Handle API key resolution correctly
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Implement flexible environment resolution
|
||||
function resolveEnvVariable(key, sessionEnv = null) {
|
||||
// First check session environment (for MCP)
|
||||
if (sessionEnv && sessionEnv[key]) {
|
||||
return sessionEnv[key];
|
||||
}
|
||||
|
||||
// Then check process environment
|
||||
if (process.env[key]) {
|
||||
return process.env[key];
|
||||
}
|
||||
|
||||
// Finally try .env file if in project root
|
||||
try {
|
||||
const projectRoot = findProjectRoot();
|
||||
if (projectRoot) {
|
||||
const envPath = path.join(projectRoot, '.env');
|
||||
if (fs.existsSync(envPath)) {
|
||||
const envContent = fs.readFileSync(envPath, 'utf8');
|
||||
const lines = envContent.split('\n');
|
||||
|
||||
for (const line of lines) {
|
||||
const [envKey, envValue] = line.split('=');
|
||||
if (envKey && envKey.trim() === key) {
|
||||
return envValue ? envValue.trim().replace(/^["']|["']$/g, '') : undefined;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
log('debug', `Error reading .env file: ${error.message}`);
|
||||
}
|
||||
|
||||
return undefined;
|
||||
}
|
||||
|
||||
function getDebugFlag() {
|
||||
const debugFlag = resolveEnvVariable('TASKMASTER_DEBUG') ||
|
||||
resolveEnvVariable('DEBUG') ||
|
||||
'false';
|
||||
return debugFlag.toLowerCase() === 'true';
|
||||
}
|
||||
```
|
||||
|
||||
## Export Pattern
|
||||
|
||||
- **Module Exports**:
|
||||
- ✅ DO: Export all utility functions explicitly
|
||||
- ✅ DO: Group related functions logically
|
||||
- ✅ DO: Include new tagged system utilities
|
||||
|
||||
```javascript
|
||||
// ✅ DO: Export utilities in logical groups
|
||||
module.exports = {
|
||||
// File system utilities
|
||||
readJSON,
|
||||
writeJSON,
|
||||
findProjectRoot,
|
||||
|
||||
// Tagged task system utilities
|
||||
getTasksForTag,
|
||||
setTasksForTag,
|
||||
getCurrentTag,
|
||||
performCompleteTagMigration,
|
||||
migrateConfigJson,
|
||||
createStateJson,
|
||||
markMigrationForNotice,
|
||||
|
||||
// Logging utilities
|
||||
log,
|
||||
enableSilentMode,
|
||||
disableSilentMode,
|
||||
isSilentMode,
|
||||
|
||||
// Task utilities
|
||||
findTaskById,
|
||||
findSubtaskById,
|
||||
getNextTaskId,
|
||||
getNextSubtaskId,
|
||||
|
||||
// String utilities
|
||||
truncate,
|
||||
formatDuration,
|
||||
capitalizeFirst,
|
||||
|
||||
// Dependency utilities
|
||||
findCycles,
|
||||
validateDependencies,
|
||||
|
||||
// Environment utilities
|
||||
resolveEnvVariable,
|
||||
getDebugFlag,
|
||||
|
||||
// Legacy utilities (maintained for compatibility)
|
||||
aggregateTelemetry
|
||||
};
|
||||
```
|
||||
|
||||
Refer to [`utils.js`](mdc:scripts/modules/utils.js) for implementation examples and [`architecture.mdc`](mdc:.cursor/rules/architecture.mdc) for integration patterns.
|
||||
|
||||
Reference in New Issue
Block a user