[ENHANCEMENT] modes configuration

[ainthek]

Problem (one or two sentences)

Why do we have one .roomodes and not .roo/modes/slug-*/.roomode strtucture. It would simpligy sharing modes, it would allow for modes to have custom mcp.json per mode etc etc... It would also create possibilities to store rules per mode inside the folder and avoid quite cryptic configs we have now. RooCode is very limited what cen be configured per what and too many settings are global, preventing real and correct agentic behavious (scope, setiings) per different agents/roles (modes)

Context (who is affected and when)

Anyone trying to design anything more serious and more preciselly configured based on modes.

Desired behavior (conceptual, not technical)

Allow .roo/modes/slug-*/.roomode or similar structure where per mode configs will be allowed.

Constraints / preferences (optional)

I understand it will be main trouble for UI....

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote-v0]

I've been looking into this issue and explored the current modes architecture. Here is what I found:

Current state:

• Modes are configured via a flat .roomodes YAML file at project root (or custom_modes.yaml globally)
• The CustomModesManager merges project-level (.roomodes) and global modes into a single list
• Per-mode rules already exist via .roo/rules-{mode-slug}/ directories
• MCP settings are global (mcp_settings.json), not per-mode
• Mode export/import already supports bundling rules files alongside mode config

The request is to move to a directory-based structure like .roo/modes/{slug}/.roomode where each mode gets its own folder that can contain mode config, rules, and potentially per-mode MCP settings.

Before proposing an implementation plan, I need some clarification to ensure the right solution:

1. Backward compatibility: Should the existing .roomodes file continue to work alongside the new directory structure, or would this be a full migration? A phased approach (support both, prefer new structure) seems safest.

2. Scope of per-mode config: Beyond the mode definition itself (slug, name, roleDefinition, groups) and rules files, which additional settings should be per-mode? The issue mentions mcp.json per mode -- are there others (e.g., auto-approval settings, temperature, specific provider config)?

3. Global vs project level: The current system has both global (~/.roo/settings/custom_modes.yaml) and project-level (.roomodes) modes. Should the new directory structure apply to both levels (i.e., ~/.roo/modes/{slug}/ globally and .roo/modes/{slug}/ at project level)?

4. Priority/merging: If a mode exists both globally and at project level, which takes precedence? Currently project-level wins. Should the new structure allow partial overrides (e.g., project-level only overrides MCP settings but inherits everything else from global)?

5. Rules migration: Per-mode rules currently live in .roo/rules-{slug}/. Should these move into the new mode directory (e.g., .roo/modes/{slug}/rules/), or remain where they are?

6. Minimum viable scope: Given the complexity, would it be acceptable to start with just the directory-based mode config (moving .roomode definitions into .roo/modes/{slug}/) without per-mode MCP in the first iteration?

Please tag @roomote in your response with answers, and I will be happy to propose a concrete implementation plan.

[R-omk]

related #9014 #5346