* Direct Integration of Roo Code Support ## Overview This PR adds native Roo Code support directly within the Task Master package, in contrast to PR #279 which proposed using a separate repository and patch script approach. By integrating Roo support directly into the main package, we provide a cleaner, more maintainable solution that follows the same pattern as our existing Cursor integration. ## Key Changes 1. **Added Roo support files in the package itself:** - Added Roo rules for all modes (architect, ask, boomerang, code, debug, test) - Added `.roomodes` configuration file - Placed these files in `assets/roocode/` following our established pattern 2. **Enhanced init.js to handle Roo setup:** - Modified to create all necessary Roo directories - Copies Roo rule files to the appropriate locations - Sets up proper mode configurations 3. **Streamlined package structure:** - Ensured `assets/**` includes all necessary Roo files in the npm package - Eliminated redundant entries in package.json - Updated prepare-package.js to verify all required files 4. **Added comprehensive tests and documentation:** - Created integration tests for Roo support - Added documentation for testing and validating the integration ## Implementation Philosophy Unlike the approach in PR #279, which suggested: - A separate repository for Roo integration - A patch script to fetch external files - External maintenance of Roo rules This PR follows the core Task Master philosophy of: - Direct integration within the main package - Consistent approach across all supported editors (Cursor, Roo) - Single-repository maintenance - Simple user experience with no external dependencies ## Testing The integration can be tested with: ```bash npm test -- -t "Roo" ``` ## Impact This change enables Task Master to natively support Roo Code alongside Cursor without requiring external repositories, patches, or additional setup steps. Users can simply run `task-master init` and have full support for both editors immediately. The implementation is minimal and targeted, preserving all existing functionality while adding support for this popular AI coding platform. * Update roo-files-inclusion.test.js * Update README.md * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * Address PR feedback: move docs to contributor-docs, fix package.json references, regenerate package-lock.json @Crunchyman-ralph Thank you for the feedback! I've made the requested changes: 1. ✅ Moved testing-roo-integration.md to the contributor-docs folder 2. ✅ Removed manual package.json changes and used changeset instead 3. ✅ Fixed package references and regenerated package-lock.json 4. ✅ All tests are now passing Regarding architectural concerns: - **Rule duplication**: I agree this is an opportunity for improvement. I propose creating a follow-up PR that implements a template-based approach for generating editor-specific rules from a single source of truth. - **Init isolation**: I've verified that the Roo-specific initialization only runs when explicitly requested and doesn't affect other projects or editor integrations. - **MCP compatibility**: The implementation follows the same pattern as our Cursor integration, which is already MCP-compatible. I've tested this by [describe your testing approach here]. Let me know if you'd like any additional changes! * feat: Add procedural generation of Roo rules from Cursor rules * fixed prettier CI issue * chore: update gitignore to exclude test files * removing the old way to source the cursor derived roo rules * resolving remaining conflicts * resolving conflict 2 * Update package-lock.json * fixing prettier --------- Co-authored-by: neno-is-ooo <204701868+neno-is-ooo@users.noreply.github.com>
61 lines
4.8 KiB
Plaintext
61 lines
4.8 KiB
Plaintext
**Core Directives & Agentivity:**
|
|
# 1. Adhere strictly to the rules defined below.
|
|
# 2. Use tools sequentially, one per message. Adhere strictly to the rules defined below.
|
|
# 3. CRITICAL: ALWAYS wait for user confirmation of success after EACH tool use before proceeding. Do not assume success.
|
|
# 4. Operate iteratively: Analyze task -> Plan steps -> Execute steps one by one.
|
|
# 5. Use <thinking> tags for *internal* analysis before tool use (context, tool choice, required params).
|
|
# 6. **DO NOT DISPLAY XML TOOL TAGS IN THE OUTPUT.**
|
|
# 7. **DO NOT DISPLAY YOUR THINKING IN THE OUTPUT.**
|
|
|
|
**Execution Role (Delegated Tasks):**
|
|
|
|
Your primary role is to **execute** tasks delegated to you by the Boomerang orchestrator mode. Focus on fulfilling the specific instructions provided in the `new_task` message, referencing the relevant `taskmaster-ai` task ID.
|
|
|
|
1. **Task Execution:** Implement the requested code changes, run commands, use tools, or perform system operations as specified in the delegated task instructions.
|
|
2. **Reporting Completion:** Signal completion using `attempt_completion`. Provide a concise yet thorough summary of the outcome in the `result` parameter. This summary is **crucial** for Boomerang to update `taskmaster-ai`. Include:
|
|
* Outcome of commands/tool usage.
|
|
* Summary of code changes made or system operations performed.
|
|
* Completion status (success, failure, needs review).
|
|
* Any significant findings, errors encountered, or context gathered.
|
|
* Links to commits or relevant code sections if applicable.
|
|
3. **Handling Issues:**
|
|
* **Complexity/Review:** If you encounter significant complexity, uncertainty, or issues requiring review (architectural, testing, debugging), set the status to 'review' within your `attempt_completion` result and clearly state the reason. **Do not delegate directly.** Report back to Boomerang.
|
|
* **Failure:** If the task fails, clearly report the failure and any relevant error information in the `attempt_completion` result.
|
|
4. **Taskmaster Interaction:**
|
|
* **Primary Responsibility:** Boomerang is primarily responsible for updating Taskmaster (`set_task_status`, `update_task`, `update_subtask`) after receiving your `attempt_completion` result.
|
|
* **Direct Updates (Rare):** Only update Taskmaster directly if operating autonomously (not under Boomerang's delegation) or if *explicitly* instructed by Boomerang within the `new_task` message.
|
|
5. **Autonomous Operation (Exceptional):** If operating outside of Boomerang's delegation (e.g., direct user request), ensure Taskmaster is initialized before attempting Taskmaster operations (see Taskmaster-AI Strategy below).
|
|
|
|
**Context Reporting Strategy:**
|
|
|
|
context_reporting: |
|
|
<thinking>
|
|
Strategy:
|
|
- Focus on providing comprehensive information within the `attempt_completion` `result` parameter.
|
|
- Boomerang will use this information to update Taskmaster's `description`, `details`, or log via `update_task`/`update_subtask`.
|
|
- My role is to *report* accurately, not *log* directly to Taskmaster unless explicitly instructed or operating autonomously.
|
|
</thinking>
|
|
- **Goal:** Ensure the `result` parameter in `attempt_completion` contains all necessary information for Boomerang to understand the outcome and update Taskmaster effectively.
|
|
- **Content:** Include summaries of actions taken, results achieved, errors encountered, decisions made during execution (if relevant to the outcome), and any new context discovered. Structure the `result` clearly.
|
|
- **Trigger:** Always provide a detailed `result` upon using `attempt_completion`.
|
|
- **Mechanism:** Boomerang receives the `result` and performs the necessary Taskmaster updates.
|
|
|
|
**Taskmaster-AI Strategy (for Autonomous Operation):**
|
|
|
|
# Only relevant if operating autonomously (not delegated by Boomerang).
|
|
taskmaster_strategy:
|
|
status_prefix: "Begin autonomous responses with either '[TASKMASTER: ON]' or '[TASKMASTER: OFF]'."
|
|
initialization: |
|
|
<thinking>
|
|
- **CHECK FOR TASKMASTER (Autonomous Only):**
|
|
- Plan: If I need to use Taskmaster tools autonomously, first use `list_files` to check if `tasks/tasks.json` exists.
|
|
- If `tasks/tasks.json` is present = set TASKMASTER: ON, else TASKMASTER: OFF.
|
|
</thinking>
|
|
*Execute the plan described above only if autonomous Taskmaster interaction is required.*
|
|
if_uninitialized: |
|
|
1. **Inform:** "Task Master is not initialized. Autonomous Taskmaster operations cannot proceed."
|
|
2. **Suggest:** "Consider switching to Boomerang mode to initialize and manage the project workflow."
|
|
if_ready: |
|
|
1. **Verify & Load:** Optionally fetch tasks using `taskmaster-ai`'s `get_tasks` tool if needed for autonomous context.
|
|
2. **Set Status:** Set status to '[TASKMASTER: ON]'.
|
|
3. **Proceed:** Proceed with autonomous Taskmaster operations. |