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

.changeset/quick-flies-sniff.md

@@ -0,0 +1,5 @@
+---
+"task-master-ai": patch
+---
+
+Fix issue with generate command which was creating tasks in the legacy tasks location.

assets/.windsurfrules

@@ -1,18 +1,22 @@
 Below you will find a variety of important rules spanning:
+
 - the dev_workflow
 - the .windsurfrules document self-improvement workflow
 - the template to follow when modifying or adding new sections/rules to this document.
 
 ---
-DEV_WORKFLOW
+
----
+## DEV_WORKFLOW
+
 description: Guide for using meta-development script (scripts/dev.js) to manage task-driven development workflows
-globs: **/*
+globs: **/\*
-filesToApplyRule: **/*
+filesToApplyRule: **/\*
 alwaysApply: true
+
 ---
 
 - **Global CLI Commands**
+
   - Task Master now provides a global CLI through the `task-master` command
   - All functionality from `scripts/dev.js` is available through this interface
   - Install globally with `npm install -g claude-task-master` or use locally via `npx`
@@ -25,6 +29,7 @@ alwaysApply: true
   - The CLI provides additional commands like `task-master init` for project setup
 
 - **Development Workflow Process**
+
   - Start new projects by running `task-master init` or `node scripts/dev.js parse-prd --input=<prd-file.txt>` to generate initial tasks.json
   - Begin coding sessions with `task-master list` to see current tasks, status, and IDs
   - Analyze task complexity with `task-master analyze-complexity --research` before breaking down tasks
@@ -43,6 +48,7 @@ alwaysApply: true
   - Report progress regularly using the list command
 
 - **Task Complexity Analysis**
+
   - Run `node scripts/dev.js analyze-complexity --research` for comprehensive analysis
   - Review complexity report in scripts/task-complexity-report.json
   - Or use `node scripts/dev.js complexity-report` for a formatted, readable version of the report
@@ -51,6 +57,7 @@ alwaysApply: true
   - Note that reports are automatically used by the expand command
 
 - **Task Breakdown Process**
+
   - For tasks with complexity analysis, use `node scripts/dev.js expand --id=<id>`
   - Otherwise use `node scripts/dev.js expand --id=<id> --subtasks=<number>`
   - Add `--research` flag to leverage Perplexity AI for research-backed expansion
@@ -60,18 +67,21 @@ alwaysApply: true
   - If subtasks need regeneration, clear them first with `clear-subtasks` command
 
 - **Implementation Drift Handling**
+
   - When implementation differs significantly from planned approach
   - When future tasks need modification due to current implementation choices
   - When new dependencies or requirements emerge
   - Call `node scripts/dev.js update --from=<futureTaskId> --prompt="<explanation>"` to update tasks.json
 
 - **Task Status Management**
+
   - Use 'pending' for tasks ready to be worked on
   - Use 'done' for completed and verified tasks
   - Use 'deferred' for postponed tasks
   - Add custom status values as needed for project-specific workflows
 
 - **Task File Format Reference**
+
   ```
   # Task ID: <id>
   # Title: <title>
@@ -81,21 +91,23 @@ alwaysApply: true
   # Description: <brief description>
   # Details:
   <detailed implementation notes>
-  
+
   # Test Strategy:
   <verification approach>
   ```
 
 - **Command Reference: parse-prd**
+
   - Legacy Syntax: `node scripts/dev.js parse-prd --input=<prd-file.txt>`
   - CLI Syntax: `task-master parse-prd --input=<prd-file.txt>`
   - Description: Parses a PRD document and generates a tasks.json file with structured tasks
-  - Parameters: 
+  - Parameters:
     - `--input=<file>`: Path to the PRD text file (default: sample-prd.txt)
   - Example: `task-master parse-prd --input=requirements.txt`
   - Notes: Will overwrite existing tasks.json file. Use with caution.
 
 - **Command Reference: update**
+
   - Legacy Syntax: `node scripts/dev.js update --from=<id> --prompt="<prompt>"`
   - CLI Syntax: `task-master update --from=<id> --prompt="<prompt>"`
   - Description: Updates tasks with ID >= specified ID based on the provided prompt
@@ -106,16 +118,18 @@ alwaysApply: true
   - Notes: Only updates tasks not marked as 'done'. Completed tasks remain unchanged.
 
 - **Command Reference: generate**
+
   - Legacy Syntax: `node scripts/dev.js generate`
   - CLI Syntax: `task-master generate`
-  - Description: Generates individual task files in tasks/ directory based on tasks.json
+  - Description: Generates individual task files based on tasks.json
-  - Parameters: 
+  - Parameters:
-    - `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
+    - `--file=<path>, -f`: Use alternative tasks.json file (default: '.taskmaster/tasks/tasks.json')
-    - `--output=<dir>, -o`: Output directory (default: 'tasks')
+    - `--output=<dir>, -o`: Output directory (default: '.taskmaster/tasks')
   - Example: `task-master generate`
-  - Notes: Overwrites existing task files. Creates tasks/ directory if needed.
+  - Notes: Overwrites existing task files. Creates output directory if needed.
 
 - **Command Reference: set-status**
+
   - Legacy Syntax: `node scripts/dev.js set-status --id=<id> --status=<status>`
   - CLI Syntax: `task-master set-status --id=<id> --status=<status>`
   - Description: Updates the status of a specific task in tasks.json
@@ -126,10 +140,11 @@ alwaysApply: true
   - Notes: Common values are 'done', 'pending', and 'deferred', but any string is accepted.
 
 - **Command Reference: list**
+
   - Legacy Syntax: `node scripts/dev.js list`
   - CLI Syntax: `task-master list`
   - Description: Lists all tasks in tasks.json with IDs, titles, and status
-  - Parameters: 
+  - Parameters:
     - `--status=<status>, -s`: Filter by status
     - `--with-subtasks`: Show subtasks for each task
     - `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
@@ -137,6 +152,7 @@ alwaysApply: true
   - Notes: Provides quick overview of project progress. Use at start of sessions.
 
 - **Command Reference: expand**
+
   - Legacy Syntax: `node scripts/dev.js expand --id=<id> [--num=<number>] [--research] [--prompt="<context>"]`
   - CLI Syntax: `task-master expand --id=<id> [--num=<number>] [--research] [--prompt="<context>"]`
   - Description: Expands a task with subtasks for detailed implementation
@@ -151,6 +167,7 @@ alwaysApply: true
   - Notes: Uses complexity report recommendations if available.
 
 - **Command Reference: analyze-complexity**
+
   - Legacy Syntax: `node scripts/dev.js analyze-complexity [options]`
   - CLI Syntax: `task-master analyze-complexity [options]`
   - Description: Analyzes task complexity and generates expansion recommendations
@@ -164,6 +181,7 @@ alwaysApply: true
   - Notes: Report includes complexity scores, recommended subtasks, and tailored prompts.
 
 - **Command Reference: clear-subtasks**
+
   - Legacy Syntax: `node scripts/dev.js clear-subtasks --id=<id>`
   - CLI Syntax: `task-master clear-subtasks --id=<id>`
   - Description: Removes subtasks from specified tasks to allow regeneration
@@ -174,12 +192,13 @@ alwaysApply: true
     - `task-master clear-subtasks --id=3`
     - `task-master clear-subtasks --id=1,2,3`
     - `task-master clear-subtasks --all`
-  - Notes: 
+  - Notes:
     - Task files are automatically regenerated after clearing subtasks
     - Can be combined with expand command to immediately generate new subtasks
     - Works with both parent tasks and individual subtasks
 
 - **Task Structure Fields**
+
   - **id**: Unique identifier for the task (Example: `1`)
   - **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
   - **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
@@ -193,6 +212,7 @@ alwaysApply: true
   - **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
 
 - **Environment Variables Configuration**
+
   - **ANTHROPIC_API_KEY** (Required): Your Anthropic API key for Claude (Example: `ANTHROPIC_API_KEY=sk-ant-api03-...`)
   - **MODEL** (Default: `"claude-3-7-sonnet-20250219"`): Claude model to use (Example: `MODEL=claude-3-opus-20240229`)
   - **MAX_TOKENS** (Default: `"4000"`): Maximum tokens for responses (Example: `MAX_TOKENS=8000`)
@@ -207,6 +227,7 @@ alwaysApply: true
   - **PERPLEXITY_MODEL** (Default: `"sonar-medium-online"`): Perplexity model (Example: `PERPLEXITY_MODEL=sonar-large-online`)
 
 - **Determining the Next Task**
+
   - Run `task-master next` to show the next task to work on
   - The next command identifies tasks with all dependencies satisfied
   - Tasks are prioritized by priority level, dependency count, and ID
@@ -221,6 +242,7 @@ alwaysApply: true
   - Provides ready-to-use commands for common task actions
 
 - **Viewing Specific Task Details**
+
   - Run `task-master show <id>` or `task-master show --id=<id>` to view a specific task
   - Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
   - Displays comprehensive information similar to the next command, but for a specific task
@@ -230,6 +252,7 @@ alwaysApply: true
   - Useful for examining task details before implementation or checking status
 
 - **Managing Task Dependencies**
+
   - Use `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency
   - Use `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency
   - The system prevents circular dependencies and duplicate dependency entries
@@ -238,6 +261,7 @@ alwaysApply: true
   - Dependencies are visualized with status indicators in task listings and files
 
 - **Command Reference: add-dependency**
+
   - Legacy Syntax: `node scripts/dev.js add-dependency --id=<id> --depends-on=<id>`
   - CLI Syntax: `task-master add-dependency --id=<id> --depends-on=<id>`
   - Description: Adds a dependency relationship between two tasks
@@ -248,6 +272,7 @@ alwaysApply: true
   - Notes: Prevents circular dependencies and duplicates; updates task files automatically
 
 - **Command Reference: remove-dependency**
+
   - Legacy Syntax: `node scripts/dev.js remove-dependency --id=<id> --depends-on=<id>`
   - CLI Syntax: `task-master remove-dependency --id=<id> --depends-on=<id>`
   - Description: Removes a dependency relationship between two tasks
@@ -258,44 +283,48 @@ alwaysApply: true
   - Notes: Checks if dependency actually exists; updates task files automatically
 
 - **Command Reference: validate-dependencies**
+
   - Legacy Syntax: `node scripts/dev.js validate-dependencies [options]`
   - CLI Syntax: `task-master validate-dependencies [options]`
   - Description: Checks for and identifies invalid dependencies in tasks.json and task files
   - Parameters:
     - `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
   - Example: `task-master validate-dependencies`
-  - Notes: 
+  - Notes:
     - Reports all non-existent dependencies and self-dependencies without modifying files
     - Provides detailed statistics on task dependency state
     - Use before fix-dependencies to audit your task structure
 
 - **Command Reference: fix-dependencies**
+
   - Legacy Syntax: `node scripts/dev.js fix-dependencies [options]`
   - CLI Syntax: `task-master fix-dependencies [options]`
   - Description: Finds and fixes all invalid dependencies in tasks.json and task files
   - Parameters:
     - `--file=<path>, -f`: Use alternative tasks.json file (default: 'tasks/tasks.json')
   - Example: `task-master fix-dependencies`
-  - Notes: 
+  - Notes:
     - Removes references to non-existent tasks and subtasks
     - Eliminates self-dependencies (tasks depending on themselves)
     - Regenerates task files with corrected dependencies
     - Provides detailed report of all fixes made
 
 - **Command Reference: complexity-report**
+
   - Legacy Syntax: `node scripts/dev.js complexity-report [options]`
   - CLI Syntax: `task-master complexity-report [options]`
   - Description: Displays the task complexity analysis report in a formatted, easy-to-read way
   - Parameters:
     - `--file=<path>, -f`: Path to the complexity report file (default: 'scripts/task-complexity-report.json')
   - Example: `task-master complexity-report`
-  - Notes: 
+  - Notes:
     - Shows tasks organized by complexity score with recommended actions
     - Provides complexity distribution statistics
     - Displays ready-to-use expansion commands for complex tasks
     - If no report exists, offers to generate one interactively
 
 - **Command Reference: add-task**
+
   - CLI Syntax: `task-master add-task [options]`
   - Description: Add a new task to tasks.json using AI
   - Parameters:
@@ -307,11 +336,12 @@ alwaysApply: true
   - Notes: Uses AI to convert description into structured task with appropriate details
 
 - **Command Reference: init**
+
   - CLI Syntax: `task-master init`
   - Description: Initialize a new project with Task Master structure
   - Parameters: None
   - Example: `task-master init`
-  - Notes: 
+  - Notes:
     - Creates initial project structure with required files
     - Prompts for project settings if not provided
     - Merges with existing files when appropriate
@@ -341,15 +371,20 @@ alwaysApply: true
       - Check for any unintentional duplications or omissions
 
 ---
-WINDSURF_RULES
+
----
+## WINDSURF_RULES
+
 description: Guidelines for creating and maintaining Windsurf rules to ensure consistency and effectiveness.
 globs: .windsurfrules
 filesToApplyRule: .windsurfrules
 alwaysApply: true
+
 ---
+
 The below describes how you should be structuring new rule sections in this document.
+
 - **Required Rule Structure:**
+
   ```markdown
   ---
   description: Clear, one-line description of what the rule enforces
@@ -363,20 +398,24 @@ The below describes how you should be structuring new rule sections in this docu
   ```
 
 - **Section References:**
+
   - Use `ALL_CAPS_SECTION` to reference files
   - Example: `WINDSURF_RULES`
 
 - **Code Examples:**
+
   - Use language-specific code blocks
+
   ```typescript
   // ✅ DO: Show good examples
   const goodExample = true;
-  
+
   // ❌ DON'T: Show anti-patterns
   const badExample = false;
   ```
 
 - **Rule Content Guidelines:**
+
   - Start with high-level overview
   - Include specific, actionable requirements
   - Show examples of correct implementation
@@ -384,6 +423,7 @@ The below describes how you should be structuring new rule sections in this docu
   - Keep rules DRY by referencing other rules
 
 - **Rule Maintenance:**
+
   - Update rules when new patterns emerge
   - Add examples from actual codebase
   - Remove outdated patterns
@@ -394,18 +434,21 @@ The below describes how you should be structuring new rule sections in this docu
   - Keep descriptions concise
   - Include both DO and DON'T examples
   - Reference actual code over theoretical examples
-  - Use consistent formatting across rules 
+  - Use consistent formatting across rules
 
 ---
-SELF_IMPROVE
+
----
+## SELF_IMPROVE
+
 description: Guidelines for continuously improving this rules document based on emerging code patterns and best practices.
-globs: **/*
+globs: **/\*
-filesToApplyRule: **/*
+filesToApplyRule: **/\*
 alwaysApply: true
+
 ---
 
 - **Rule Improvement Triggers:**
+
   - New code patterns not covered by existing rules
   - Repeated similar implementations across files
   - Common error patterns that could be prevented
@@ -413,6 +456,7 @@ alwaysApply: true
   - Emerging best practices in the codebase
 
 - **Analysis Process:**
+
   - Compare new code with existing rules
   - Identify patterns that should be standardized
   - Look for references to external documentation
@@ -420,7 +464,9 @@ alwaysApply: true
   - Monitor test patterns and coverage
 
 - **Rule Updates:**
+
   - **Add New Rules When:**
+
     - A new technology/pattern is used in 3+ files
     - Common bugs could be prevented by a rule
     - Code reviews repeatedly mention the same feedback
@@ -433,13 +479,14 @@ alwaysApply: true
     - Implementation details have changed
 
 - **Example Pattern Recognition:**
+
   ```typescript
   // If you see repeated patterns like:
   const data = await prisma.user.findMany({
     select: { id: true, email: true },
-    where: { status: 'ACTIVE' }
+    where: { status: "ACTIVE" },
   });
-  
+
   // Consider adding a PRISMA section in the .windsurfrules:
   // - Standard select fields
   // - Common where conditions
@@ -447,12 +494,14 @@ alwaysApply: true
   ```
 
 - **Rule Quality Checks:**
+
   - Rules should be actionable and specific
   - Examples should come from actual code
   - References should be up to date
   - Patterns should be consistently enforced
 
 - **Continuous Improvement:**
+
   - Monitor code review comments
   - Track common development questions
   - Update rules after major refactors
@@ -460,6 +509,7 @@ alwaysApply: true
   - Cross-reference related rules
 
 - **Rule Deprecation:**
+
   - Mark outdated patterns as deprecated
   - Remove rules that no longer apply
   - Update references to deprecated rules
@@ -471,4 +521,4 @@ alwaysApply: true
   - Maintain links between related rules
   - Document breaking changes
 
-Follow WINDSURF_RULES for proper rule formatting and structure of windsurf rule sections.
+Follow WINDSURF_RULES for proper rule formatting and structure of windsurf rule sections.

biome.json

@@ -1,48 +1,50 @@
 {
-	"files": {
+  "files": {
-		"ignore": [
+    "ignore": [
-			"build",
+      "build",
-			"coverage",
+      "coverage",
-			".changeset",
+      ".changeset",
-			"tasks",
+      "tasks",
-			"package-lock.json",
+      "package-lock.json",
-			"tests/fixture/*.json"
+      "tests/fixture/*.json"
-		]
+    ]
-	},
+  },
-	"formatter": {
+  "formatter": {
-		"bracketSpacing": true,
+    "bracketSpacing": true,
-		"enabled": true,
+    "enabled": true,
-		"indentStyle": "tab",
+    "indentStyle": "tab",
-		"lineWidth": 80
+    "lineWidth": 80
-	},
+  },
-	"javascript": {
+  "javascript": {
-		"formatter": {
+    "formatter": {
-			"arrowParentheses": "always",
+      "arrowParentheses": "always",
-			"quoteStyle": "single",
+      "quoteStyle": "single",
-			"trailingCommas": "none"
+      "trailingCommas": "none"
-		}
+    }
-	},
+  },
-	"linter": {
+  "linter": {
-		"rules": {
+    "rules": {
-			"complexity": {
+      "complexity": {
-				"noForEach": "off",
+        "noForEach": "off",
-				"useOptionalChain": "off"
+        "useOptionalChain": "off",
-			},
+        "useArrowFunction": "off"
-			"correctness": {
+      },
-				"noConstantCondition": "off",
+      "correctness": {
-				"noUnreachable": "off"
+        "noConstantCondition": "off",
-			},
+        "noUnreachable": "off"
-			"suspicious": {
+      },
-				"noDuplicateTestHooks": "off",
+      "suspicious": {
-				"noPrototypeBuiltins": "off"
+        "noDuplicateTestHooks": "off",
-			},
+        "noPrototypeBuiltins": "off"
-			"style": {
+      },
-				"noUselessElse": "off",
+      "style": {
-				"useNodejsImportProtocol": "off",
+        "noUselessElse": "off",
-				"useNumberNamespace": "off",
+        "useNodejsImportProtocol": "off",
-				"noParameterAssign": "off",
+        "useNumberNamespace": "off",
-				"useTemplate": "off"
+        "noParameterAssign": "off",
-			}
+        "useTemplate": "off",
-		}
+        "noUnusedTemplateLiteral": "off"
-	}
+      }
+    }
+  }
 }

scripts/modules/commands.js

@@ -1181,7 +1181,11 @@ function registerCommands(programInstance) {
 			'Path to the tasks file',
 			TASKMASTER_TASKS_FILE
 		)
-		.option('-o, --output <dir>', 'Output directory', 'tasks')
+		.option(
+			'-o, --output <dir>',
+			'Output directory',
+			path.dirname(TASKMASTER_TASKS_FILE)
+		)
 		.action(async (options) => {
 			const tasksPath = options.file || TASKMASTER_TASKS_FILE;
 			const outputDir = options.output;