-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
What specific problem does this solve?
- Problem: The
Mode Writermode currently lacks the functionality to create "global" modes that are accessible across all projects. It does not prompt the user to choose between a global or local scope, and it fails to write the mode files to the correct global directory even when explicitly requested. - Who is affected: Users who want to create reusable custom modes that can be used in multiple projects without having to manually copy them.
- When this happens: When a user tries to create a new mode using the
Mode Writerand intends for it to be global. - Current behavior: The
Mode Writermode defaults to creating all modes locally within the current project's.roomodesand.roo/directories. It does not ask for the desired scope. - Expected behavior: The
Mode Writermode should be enhanced to first ask the user whether the new mode should be "Global" (available in all projects) or "Local" (specific to the current project).- If "Global" is chosen, it should write the mode's configuration to the global
custom_modes.yamlfile and the rules to the global.roo/rules-[mode-slug]/directory. - If "Local" is chosen, it should continue to use the project's
.roomodesand.roo/directories.
- If "Global" is chosen, it should write the mode's configuration to the global
- Impact: This missing feature limits the utility and reusability of custom modes, creating friction for users who work across multiple projects and want a consistent set of tools.
Additional context (optional)
No response
Roo Code Task Links (Optional)
No response
Request checklist
- I've searched existing Issues and Discussions for duplicates
- This describes a specific problem with clear impact and context
Interested in implementing this?
- Yes, I'd like to help implement this feature
Implementation requirements
- I understand this needs approval before implementation begins
How should this be solved? (REQUIRED if contributing, optional otherwise)
How should this be solved?
The solution involves enhancing the Mode Writer mode to differentiate between global and local mode creation. This is achieved by updating the core workflow to first ask the user for their desired scope and then using that choice to determine the correct file paths for all subsequent operations.
What exactly will change?
-
Workflow Instructions (
.roo/rules-mode-writer/1_mode_creation_workflow.xml): The primary instruction file for theMode Writerwill be modified to include a new initial step. This step will use theask_followup_questiontool to prompt the user to choose between "Global" and "Local" mode creation. The rest of the workflow will be updated to branch based on this selection, ensuring that directories are created and files are written to the correct absolute paths for global modes or relative paths for local modes. -
Mode Configuration (
.roomodes): The configuration for themode-writeritself will be updated. ThefileRegexfor its edit permissions will be broadened from(\.roomodes$|\.roo/.*\.xml$|\.yaml$)to(\.roomodes$|.*\.xml$|.*\.yaml$). This change is critical as it grants the mode permission to write to the globalcustom_modes.yamlfile located outside the project's directory structure.
How will users interact with it?
When a user starts the Mode Writer workflow, they will immediately be presented with a clear choice: "Should this be a global mode (available in all projects) or a local mode (only for this project)?". The user's selection will dictate the entire subsequent process without requiring any further path-related input.
What will the new behaviour look like?
- If the user selects "Global", the
Mode Writerwill write the new mode's definition to thecustom_modes.yamlfile located in the user's global settings directory (C:\Users\VooDoo\AppData\Roaming\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\) and place the corresponding rule files in the global rules directory. - If the user selects "Local", the mode will be created within the project's local
.roomodesand.roo/rules-[mode-slug]/directories, maintaining the previous default behavior.
How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
How will we know it works? (Acceptance Criteria)
Scenario 1: Creating a Global Mode
- Given I am using the
Mode Writermode to create a new custom mode. - When I am prompted to choose the mode's scope and I select "Global".
- Then the new mode's configuration is correctly added to the global
custom_modes.yamlfile (C:\Users\Username\AppData\Roaming\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\custom_modes.yaml). - And the mode's XML rule files are created in the corresponding global rules directory (
...\.roo\rules-[mode-slug]\). - But the local project's
.roomodesfile is not modified in any way.
Scenario 2: Creating a Local Mode
- Given I am using the
Mode Writermode to create a new custom mode. - When I am prompted to choose the mode's scope and I select "Local".
- Then the new mode's configuration is correctly added to the local project's
.roomodesfile. - And the mode's XML rule files are created in the local project's
.roo/rules-[mode-slug]/directory. - But the global
custom_modes.yamlfile is not modified in any way.
Technical considerations (REQUIRED if contributing, optional otherwise)
Technical considerations
-
Implementation approach or architecture changes:
- The core of this feature will be implemented by modifying the
Mode Writer's workflow file (.roo/rules-mode-writer/1_mode_creation_workflow.xml). - A new initial step must be added to the workflow to prompt the user for the desired scope (Global vs. Local).
- The logic will need to read the
Home Directoryfrom theSYSTEM INFORMATIONcontext to reliably construct the absolute file path for global mode storage across different user setups. - The
fileRegexpermission for themode-writerin.roomodesmust be updated to(\.roomodes$|.*\.xml$|.*\.yaml$)to allow it to write to the globalcustom_modes.yamlfile, which exists outside the project directory.
- The core of this feature will be implemented by modifying the
-
Systems that might be affected:
- This will primarily affect the
Mode Writermode. It will also interact with the file system at both the project level (for local modes) and the user's global VS Code settings directory (for global modes).
- This will primarily affect the
-
Potential blockers you can foresee:
- The primary potential blocker is file system permissions. The tool must have the necessary rights to write to the user's global application data directory (e.g.,
AppDataon Windows). Any permission issues could cause the feature to fail.
- The primary potential blocker is file system permissions. The tool must have the necessary rights to write to the user's global application data directory (e.g.,
Trade-offs and risks (REQUIRED if contributing, optional otherwise)
Trade-offs and risks
-
Alternative approaches and why you chose this one:
- An alternative would be to have a separate command or a configuration setting to toggle the
Mode Writerbetween "global" and "local" states. - This was not chosen because a direct prompt at the beginning of the workflow is more explicit and user-friendly. It prevents users from forgetting the current setting and accidentally saving a mode in the wrong scope.
- An alternative would be to have a separate command or a configuration setting to toggle the
-
Edge cases that need careful handling:
- Name Collisions: The implementation must gracefully handle cases where a mode with the same slug already exists in the target location (either globally or locally). It should warn the user and prevent overwriting an existing mode.
- Path Variability: The path to the global settings directory can vary between operating systems (Windows, macOS, Linux). The solution must correctly identify this path to ensure cross-platform compatibility.
- File Integrity: If the global
custom_modes.yamlfile is malformed or read-only, the operation will fail. The system should ideally detect this and provide a clear error message.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status