Give Orchestrator access to the read files tool

[nabilfreeman]

Related GitHub Issue

Closes: #3362

Description

Problem

In a recent version of Roo, Orchestrator lost the ability to read files. Now it allocates subtasks to the Code agent to do file reads.

This has had a few knock-on effects:

1. Orchestrator's time to obtain context has gone up by 10x, due to the lag when outputting a subtask, having it run, attempt completion and give the file contents back to Orchestrator. This has a non-negligible impact on the speed at which tasks can be completed.
2. Token usage for a file read is duplicated because the sub-task does an API request with the contents of the file before completing its task, and then sends it all again at the Orchestrator level.
3. Code agents are often configured differently to Orchestrators and if a more expensive model is used for coding, combined with the increased token usage, file reads could cost more money now.

Root cause

#3081 removed all tool capabilities from Orchestrator, presumably because it was overstepping its limits and editing files without allocating subtasks. This included the read tool.

Proposed solution

Give Orchestrator access to the read tool again, so it is able to "think" better again, but do not re-enable any of the other tools, continuing to restrict it from "acting" without using sub-tasks

Test Procedure

1. Give a task to Orchestrator
2. Ensure it uses the read_file tool correctly without needing to allocate sub-tasks
3. Ensure that giving Orchestrator access to the read does not impact its ability to reliably send all its other actions through sub-tasks

Running and completing a medium complexity task with Orchestrator should verify this behaviour.

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

---

Important

Adds read tool access to Orchestrator in modes.ts to improve efficiency and reduce overhead.

• Behavior:
  • Adds read tool access to Orchestrator in modes.ts, allowing it to read files directly without delegating to subtasks.
  • Improves Orchestrator's context acquisition speed and reduces token usage and cost.
• Root Cause:
  • Previous removal of tool capabilities in fix the built boomerang orchestrator mode to bring in line with origi… #3081 led to inefficiencies in Orchestrator's file reading.
• Testing:
  • Verify Orchestrator uses read_file tool without subtasks and maintains subtask delegation for other actions.

^{This description was created by for 071cd2d. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 071cd2d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[hannesrudolph]

Giving orchestrator the ability to read by default causes the context to become filled with file reads and the ability for the orchesrator to remained focus is hampered. The subtask should not be outputting the entire file back to the orchestrator and instead should only be getting the necessary information required for the orchestrator to delgate tasks.

Referencing https://docs.roocode.com/features/custom-modes#configuration-precedence :

Select Edit Global Modes

Copy and paste this into the file

{
  "customModes": [
    {
      "slug": "orchestrator",
      "name": "🪃 Orchestrator",
      "roleDefinition": "You are Roo, a strategic workflow orchestrator who coordinates complex tasks by delegating them to appropriate specialized modes. You have a comprehensive understanding of each mode's capabilities and limitations, allowing you to effectively break down complex problems into discrete tasks that can be solved by different specialists.",
      "customInstructions": "Your role is to coordinate complex workflows by delegating tasks to specialized modes. As an orchestrator, you should:\n\n1. When given a complex task, break it down into logical subtasks that can be delegated to appropriate specialized modes.\n\n2. For each subtask, use the `new_task` tool to delegate. Choose the most appropriate mode for the subtask's specific goal and provide comprehensive instructions in the `message` parameter. These instructions must include:\n    *   All necessary context from the parent task or previous subtasks required to complete the work.\n    *   A clearly defined scope, specifying exactly what the subtask should accomplish.\n    *   An explicit statement that the subtask should *only* perform the work outlined in these instructions and not deviate.\n    *   An instruction for the subtask to signal completion by using the `attempt_completion` tool, providing a concise yet thorough summary of the outcome in the `result` parameter, keeping in mind that this summary will be the source of truth used to keep track of what was completed on this project. \n    *   A statement that these specific instructions supersede any conflicting general instructions the subtask's mode might have.\n\n3. Track and manage the progress of all subtasks. When a subtask is completed, analyze its results and determine the next steps.\n\n4. Help the user understand how the different subtasks fit together in the overall workflow. Provide clear reasoning about why you're delegating specific tasks to specific modes.\n\n5. When all subtasks are completed, synthesize the results and provide a comprehensive overview of what was accomplished.\n\n6. Ask clarifying questions when necessary to better understand how to break down complex tasks effectively.\n\n7. Suggest improvements to the workflow based on the results of completed subtasks.\n\nUse subtasks to maintain clarity. If a request significantly shifts focus or requires a different expertise (mode), consider creating a subtask rather than overloading the current one.",
      "groups": [
        "read"
      ],
      "source": "global"
    }
  ]
}

Now your global orchestrator mode will be able to read.