Skip to content

Feature: Add Global/Local Scope option to "Mode Writer" modeΒ #5972

@VooDisss

Description

@VooDisss

What specific problem does this solve?

  • Problem: The Mode Writer mode 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 Writer and intends for it to be global.
  • Current behavior: The Mode Writer mode defaults to creating all modes locally within the current project's .roomodes and .roo/ directories. It does not ask for the desired scope.
  • Expected behavior: The Mode Writer mode 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.yaml file and the rules to the global .roo/rules-[mode-slug]/ directory.
    • If "Local" is chosen, it should continue to use the project's .roomodes and .roo/ directories.
  • 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?

  1. Workflow Instructions (.roo/rules-mode-writer/1_mode_creation_workflow.xml): The primary instruction file for the Mode Writer will be modified to include a new initial step. This step will use the ask_followup_question tool 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.

  2. Mode Configuration (.roomodes): The configuration for the mode-writer itself will be updated. The fileRegex for 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 global custom_modes.yaml file 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 Writer will write the new mode's definition to the custom_modes.yaml file 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 .roomodes and .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 Writer mode 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.yaml file (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 .roomodes file is not modified in any way.

Scenario 2: Creating a Local Mode

  • Given I am using the Mode Writer mode 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 .roomodes file.
  • And the mode's XML rule files are created in the local project's .roo/rules-[mode-slug]/ directory.
  • But the global custom_modes.yaml file 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 Directory from the SYSTEM INFORMATION context to reliably construct the absolute file path for global mode storage across different user setups.
    • The fileRegex permission for the mode-writer in .roomodes must be updated to (\.roomodes$|.*\.xml$|.*\.yaml$) to allow it to write to the global custom_modes.yaml file, which exists outside the project directory.
  • Systems that might be affected:

    • This will primarily affect the Mode Writer mode. 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).
  • 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., AppData on Windows). Any permission issues could cause the feature to fail.

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 Writer between "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.
  • 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.yaml file is malformed or read-only, the operation will fail. The system should ideally detect this and provide a clear error message.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue/PR - TriageNew issue. Needs quick review to confirm validity and assign labels.enhancementNew feature or requestproposal

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions