diff --git a/.cursor/rules/dev_workflow.mdc b/.cursor/rules/dev_workflow.mdc index 5b4af08a..1caedc45 100644 --- a/.cursor/rules/dev_workflow.mdc +++ b/.cursor/rules/dev_workflow.mdc @@ -1,6 +1,6 @@ --- description: guide the Cursor Agent in using the meta-development script (scripts/dev.js). It also defines the overall workflow for reading, updating, and generating tasks during AI-driven development. -globs: scripts/dev.js, tasks.json, tasks/*.txt +globs: **/* alwaysApply: true --- rules: diff --git a/README.md b/README-task-master.md similarity index 99% rename from README.md rename to README-task-master.md index 772e0b19..768d002d 100644 --- a/README.md +++ b/README-task-master.md @@ -280,6 +280,8 @@ npm run generate npm run dev -- set-status --id= --status= ``` +When marking a task as "done", all of its subtasks will automatically be marked as "done" as well. + ### Expand Tasks ```bash npm run dev -- expand --id= --subtasks= --prompt="" diff --git a/package.json b/package.json index c59460bd..2b5c90e5 100644 --- a/package.json +++ b/package.json @@ -47,7 +47,7 @@ "scripts/dev.js", "assets/**", ".cursor/**", - "README.md", + "README-task-master.md", "index.js" ] } \ No newline at end of file diff --git a/scripts/README.md b/scripts/README.md index c9217ba7..3102edb3 100644 --- a/scripts/README.md +++ b/scripts/README.md @@ -97,6 +97,30 @@ Notes: - Only tasks that aren't marked as 'done' will be updated - Tasks with ID >= the specified --from value will be updated +## Setting Task Status + +The `set-status` command allows you to change a task's status: + +```bash +# Mark a task as done +node scripts/dev.js set-status --id=3 --status=done + +# Mark a task as pending +node scripts/dev.js set-status --id=4 --status=pending + +# Mark a specific subtask as done +node scripts/dev.js set-status --id=3.1 --status=done + +# Mark multiple tasks at once +node scripts/dev.js set-status --id=1,2,3 --status=done +``` + +Notes: +- When marking a parent task as "done", all of its subtasks will automatically be marked as "done" as well +- Common status values are 'done', 'pending', and 'deferred', but any string is accepted +- You can specify multiple task IDs by separating them with commas +- Subtask IDs are specified using the format `parentId.subtaskId` (e.g., `3.1`) + ## Expanding Tasks The `expand` command allows you to break down tasks into subtasks for more detailed implementation: @@ -154,4 +178,4 @@ The script supports different logging levels controlled by the `LOG_LEVEL` envir - `warn`: Warning messages that don't prevent execution - `error`: Error messages that might prevent execution -When `DEBUG=true` is set, debug logs are also written to a `dev-debug.log` file in the project root. +When `DEBUG=true` is set, debug logs are also written to a `dev-debug.log` file in the project root. \ No newline at end of file diff --git a/scripts/dev.js b/scripts/dev.js index 61e75124..455ac1a7 100755 --- a/scripts/dev.js +++ b/scripts/dev.js @@ -662,6 +662,17 @@ function setTaskStatus(tasksPath, taskIdInput, newStatus) { const oldStatus = task.status || 'pending'; task.status = newStatus; + // Automatically update subtasks if the parent task is being marked as done + if (newStatus === 'done' && task.subtasks && Array.isArray(task.subtasks) && task.subtasks.length > 0) { + log('info', `Task ${taskId} has ${task.subtasks.length} subtasks that will be marked as done too.`); + + task.subtasks.forEach(subtask => { + const oldSubtaskStatus = subtask.status || 'pending'; + subtask.status = newStatus; + log('info', ` └─ Updated subtask ${taskId}.${subtask.id} status from '${oldSubtaskStatus}' to '${newStatus}'`); + }); + } + // Save the changes writeJSON(tasksPath, data); log('info', `Updated task ${taskId} status from '${oldStatus}' to '${newStatus}'`); diff --git a/scripts/init.js b/scripts/init.js index dd32f3a9..589998a6 100755 --- a/scripts/init.js +++ b/scripts/init.js @@ -92,8 +92,8 @@ function copyTemplateFile(templateName, targetPath, replacements = {}) { case 'self_improve.mdc': sourcePath = path.join(__dirname, '..', '.cursor', 'rules', 'self_improve.mdc'); break; - case 'README.md': - sourcePath = path.join(__dirname, '..', 'README.md'); + case 'README-task-master.md': + sourcePath = path.join(__dirname, '..', 'README-task-master.md'); break; default: // For other files like env.example, gitignore, etc. that don't have direct equivalents @@ -212,7 +212,8 @@ function createProjectStructure(projectName, projectDescription, projectVersion, "@anthropic-ai/sdk": "^0.39.0", "chalk": "^4.1.2", "commander": "^11.1.0", - "dotenv": "^16.3.1" + "dotenv": "^16.3.1", + "openai": "^4.86.1" } }; @@ -256,7 +257,7 @@ function createProjectStructure(projectName, projectDescription, projectVersion, copyTemplateFile('example_prd.txt', path.join(targetDir, 'scripts', 'example_prd.txt')); // Create main README.md - copyTemplateFile('README.md', path.join(targetDir, 'README.md'), replacements); + copyTemplateFile('README-task-master.md', path.join(targetDir, 'README.md'), replacements); // Initialize git repository if git is available try { diff --git a/scripts/prepare-package.js b/scripts/prepare-package.js index 88b77eaf..de5362ee 100755 --- a/scripts/prepare-package.js +++ b/scripts/prepare-package.js @@ -120,7 +120,7 @@ function preparePackage() { // Check for required files const requiredFiles = [ 'package.json', - 'README.md', + 'README-task-master.md', 'index.js', 'scripts/init.js', 'scripts/dev.js', diff --git a/templates/README.md b/templates/README-task-master.md similarity index 79% rename from templates/README.md rename to templates/README-task-master.md index 59dc791f..768d002d 100644 --- a/templates/README.md +++ b/templates/README-task-master.md @@ -7,6 +7,27 @@ A task management system for AI-driven development with Claude, designed to work - Node.js 14.0.0 or higher - Anthropic API key (Claude API) - Anthropic SDK version 0.39.0 or higher +- OpenAI SDK (for Perplexity API integration, optional) + +## Configuration + +The script can be configured through environment variables in a `.env` file at the root of the project: + +### Required Configuration +- `ANTHROPIC_API_KEY`: Your Anthropic API key for Claude + +### Optional Configuration +- `MODEL`: Specify which Claude model to use (default: "claude-3-7-sonnet-20250219") +- `MAX_TOKENS`: Maximum tokens for model responses (default: 4000) +- `TEMPERATURE`: Temperature for model responses (default: 0.7) +- `PERPLEXITY_API_KEY`: Your Perplexity API key for research-backed subtask generation +- `PERPLEXITY_MODEL`: Specify which Perplexity model to use (default: "sonar-medium-online") +- `DEBUG`: Enable debug logging (default: false) +- `LOG_LEVEL`: Log level - debug, info, warn, error (default: info) +- `DEFAULT_SUBTASKS`: Default number of subtasks when expanding (default: 3) +- `DEFAULT_PRIORITY`: Default priority for generated tasks (default: medium) +- `PROJECT_NAME`: Override default project name in tasks.json +- `PROJECT_VERSION`: Override default version in tasks.json ## Installation @@ -105,6 +126,7 @@ What tasks are available to work on next? The agent will: - Run `node scripts/dev.js list` to see all tasks +- Run `node scripts/dev.js list --with-subtasks` to see tasks with their subtasks - Analyze dependencies to determine which tasks are ready to be worked on - Prioritize tasks based on priority level and ID order - Suggest the next task(s) to implement @@ -194,6 +216,26 @@ The agent will execute: node scripts/dev.js expand --all ``` +For research-backed subtask generation using Perplexity AI: +``` +Please break down task 5 using research-backed generation. +``` + +The agent will execute: +```bash +node scripts/dev.js expand --id=5 --research +``` + +You can also apply research-backed generation to all tasks: +``` +Please break down all pending tasks using research-backed generation. +``` + +The agent will execute: +```bash +node scripts/dev.js expand --all --research +``` + ## Manual Command Reference While the Cursor agent will handle most commands for you, you can also run them manually: @@ -208,6 +250,21 @@ npm run parse-prd -- --input= npm run list ``` +# List tasks with a specific status +```bash +npm run dev -- list --status= +``` + +# List tasks with subtasks +```bash +npm run dev -- list --with-subtasks +``` + +# List tasks with a specific status and include subtasks +```bash +npm run dev -- list --status= --with-subtasks +``` + ### Update Tasks ```bash npm run dev -- update --from= --prompt="" @@ -223,6 +280,8 @@ npm run generate npm run dev -- set-status --id= --status= ``` +When marking a task as "done", all of its subtasks will automatically be marked as "done" as well. + ### Expand Tasks ```bash npm run dev -- expand --id= --subtasks= --prompt="" @@ -232,6 +291,15 @@ or npm run dev -- expand --all ``` +For research-backed subtask generation: +```bash +npm run dev -- expand --id= --research +``` +or +```bash +npm run dev -- expand --all --research +``` + ## Task Structure Tasks in tasks.json have the following structure: diff --git a/templates/cursor_rules.mdc b/templates/cursor_rules.mdc new file mode 100644 index 00000000..7dfae3de --- /dev/null +++ b/templates/cursor_rules.mdc @@ -0,0 +1,53 @@ +--- +description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness. +globs: .cursor/rules/*.mdc +alwaysApply: true +--- + +- **Required Rule Structure:** + ```markdown + --- + description: Clear, one-line description of what the rule enforces + globs: path/to/files/*.ext, other/path/**/* + alwaysApply: boolean + --- + + - **Main Points in Bold** + - Sub-points with details + - Examples and explanations + ``` + +- **File References:** + - Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files + - Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references + - Example: [schema.prisma](mdc:prisma/schema.prisma) for code references + +- **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 + - Reference existing code when possible + - Keep rules DRY by referencing other rules + +- **Rule Maintenance:** + - Update rules when new patterns emerge + - Add examples from actual codebase + - Remove outdated patterns + - Cross-reference related rules + +- **Best Practices:** + - Use bullet points for clarity + - Keep descriptions concise + - Include both DO and DON'T examples + - Reference actual code over theoretical examples + - Use consistent formatting across rules \ No newline at end of file diff --git a/templates/scripts_README.md b/templates/scripts_README.md index 32c0be59..6e77c640 100644 --- a/templates/scripts_README.md +++ b/templates/scripts_README.md @@ -56,6 +56,30 @@ The script can be configured through environment variables in a `.env` file at t Run `node scripts/dev.js` without arguments to see detailed usage information. +## Setting Task Status + +The `set-status` command allows you to change a task's status: + +```bash +# Mark a task as done +node scripts/dev.js set-status --id=3 --status=done + +# Mark a task as pending +node scripts/dev.js set-status --id=4 --status=pending + +# Mark a specific subtask as done +node scripts/dev.js set-status --id=3.1 --status=done + +# Mark multiple tasks at once +node scripts/dev.js set-status --id=1,2,3 --status=done +``` + +Notes: +- When marking a parent task as "done", all of its subtasks will automatically be marked as "done" as well +- Common status values are 'done', 'pending', and 'deferred', but any string is accepted +- You can specify multiple task IDs by separating them with commas +- Subtask IDs are specified using the format `parentId.subtaskId` (e.g., `3.1`) + ## Expanding Tasks The `expand` command allows you to break down tasks into subtasks for more detailed implementation: diff --git a/templates/self_improve.mdc b/templates/self_improve.mdc new file mode 100644 index 00000000..a7ea8f28 --- /dev/null +++ b/templates/self_improve.mdc @@ -0,0 +1,73 @@ +--- +description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices. +globs: **/* +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 + - New libraries or tools being used consistently + - 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 + - Check for consistent error handling patterns + - 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 + - New security or performance patterns emerge + + - **Modify Existing Rules When:** + - Better examples exist in the codebase + - Additional edge cases are discovered + - Related rules have been updated + - 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' } + }); + + // Consider adding to [prisma.mdc](mdc:.cursor/rules/prisma.mdc): + // - Standard select fields + // - Common where conditions + // - Performance optimization patterns + ``` + +- **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 + - Add links to relevant documentation + - Cross-reference related rules + +- **Rule Deprecation:** + - Mark outdated patterns as deprecated + - Remove rules that no longer apply + - Update references to deprecated rules + - Document migration paths for old patterns + +- **Documentation Updates:** + - Keep examples synchronized with code + - Update references to external docs + - Maintain links between related rules + - Document breaking changes + +Follow [cursor_rules.mdc](mdc:.cursor/rules/cursor_rules.mdc) for proper rule formatting and structure. \ No newline at end of file