exp-rooedits-1

[James-Cherished]

Related GitHub Issue

Fixes #8494
Providing Roo work here in case someone wants to pick this up

[ENHANCEMENT] Mode Families: Organize Custom Modes into Grouped Collections

Problem (one or two sentences)

Users with many custom modes struggle to manage and switch between different mode collections for various workflows, leading to cluttered mode lists and difficulty finding the right mode for specific tasks.

Context (who is affected and when)

This affects power users and teams who have created multiple specialized custom modes for different types of development work (e.g., frontend development, backend APIs, documentation, testing, DevOps tasks). The problem becomes more pronounced as the number of custom modes grows beyond 5-10 modes, making it hard to quickly find and switch to the appropriate mode for the current task.

Desired behavior (conceptual, not technical)

Users should be able to create "families" or "groups" of modes that represent different workflows or contexts (e.g., "Frontend Development", "API Development", "Documentation"). When a family is selected, only the modes in that family should be available for selection, while other modes remain stored but hidden from the active session. This allows users to focus on relevant modes for their current work while maintaining access to all their custom modes.

Constraints / preferences (optional)

• Should work globally across all workspaces, not be workspace-specific
• Built-in modes (Code, Architect, Ask, Debug) should be includable in families
• Family configurations should be stored in VS Code settings (global)
• Should maintain backward compatibility with existing mode configurations
• UI should integrate seamlessly with existing modes management interface

Request checklist

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

Acceptance criteria (optional)

Given a user has multiple custom modes for different workflows
When they create a mode family for "Frontend Development" containing relevant modes
Then only those modes should be visible when the family is active
And other modes should remain stored but not interfere with the current session
And users should be able to quickly switch between different families

Given a user switches to a different mode family
When the family contains modes that don't exist in current configuration
Then those modes should be gracefully ignored with appropriate validation feedback
But the family should still function with available modes

Proposed approach (optional)

Implement a three-phase approach:

Phase 1: Backend Foundation

• Create ModeFamiliesManager class for family CRUD operations
• Design storage schema using VS Code extension context global state
• Integrate with existing CustomModesManager for mode filtering

Phase 2: Frontend Integration

• Create ModeFamiliesSettings component for family management
• Integrate family selector into existing modes management interface
• Add visual indicators for family membership in mode listings

Phase 3: User Experience Enhancement

• Auto-create "All Modes" family on first run
• Add validation for mode conflicts and missing modes
• Implement intuitive family switching interface

Architecture Overview

graph TB
    A[ModeFamiliesManager] --> B[VS Code Settings Storage]
    A --> C[CustomModesManager]
    C --> D[Mode Filtering Logic]
    D --> E[Active Modes List]
    E --> F[UI Mode Selection]

Loading

Data Structure

interface ModeFamily {
    id: string
    name: string
    description?: string
    enabledModeSlugs: string[]  // Only these modes are active
    isDefault?: boolean
    createdAt: number
    updatedAt: number
}

Trade-offs / risks (optional)

Benefits:

• Reduces cognitive load for users with many modes
• Improves mode discovery and organization
• Maintains all existing functionality
• Scales well as mode collections grow

Potential Risks:

• Added complexity to mode management
• Learning curve for existing users
• Storage overhead for family configurations
• Potential for confusion if families become too restrictive

Migration Strategy:

• Auto-create "All Modes" family on first run
• Include all existing modes in default family
• Maintain full backward compatibility

This enhancement would significantly improve the mode management experience for users with extensive custom mode collections while maintaining the simplicity for users who prefer the current approach.

Test Procedure

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.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

---

Important

Introduces mode families feature to group custom modes, with new UI components and state management updates for creating, editing, and managing these families.

• Behavior:
  • Introduces mode families to group custom modes in ModeFamiliesManager.
  • Adds UI components for managing mode families: FamilyContextIndicator, FamilySwitcher, FamilyList, ModeFamiliesSettings, ModeFamilyEditor, and ModeToggleGrid.
  • Updates ModesView to integrate mode family selection and display.
• State Management:
  • Updates ExtensionStateContext to include mode families state and active family management.
  • Adds new types for mode families in types.ts.
• UI Integration:
  • Adds mode family management to SettingsView with a new tab for mode families.
  • Provides UI for creating, editing, deleting, and toggling modes within families.

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

[hannesrudolph]

@James-Cherished can you please add screenshots?

[roomote]

I found several integration and correctness issues that will block this feature and break builds. Inline comments call out precise spots with fixes.

[roomote]

[P0] Broken TSX due to leftover search-and-replace markers. The file contains raw </search> / </search_and_replace> tokens which will fail compilation. First occurrence is here; additional occurrences at ~653–654, 733–735, and 775–777. Remove these artifacts and ensure the destructuring + JSX are valid.

[roomote]

[P0] Frontend posts messages that are not handled in the backend. getModeFamilies (and later createModeFamily / updateModeFamily / deleteModeFamily / setActiveModeFamily) have no corresponding cases in webviewMessageHandler.ts in this PR, so the UI won’t load or mutate families. Add handlers that wire to a ModeFamiliesManager (persist to global state) and return a modeFamiliesResponse payload.

[roomote]

[P1] Contract mismatch with backend. UI uses enabledModes: string[] but server-side ModeFamiliesManager defines enabledModeSlugs. This will silently break mapping. Align on a single name (e.g., enabledModeSlugs) or add a mapper at the webview boundary.

[roomote]

[P2] Unused cache key + ineffective invalidation. activeFamilyId and cacheKey are computed but the cache still uses a single cachedModes/cachedAt. Either key the cache by activeFamilyId (e.g., Map<string|null, {modes, ts}>) or drop cacheKey. As-is, family switches can return stale results during TTL.

[roomote]

[P1] Shared cache between getAllModes and getCustomModes can cross-contaminate results. getAllModes() sets this.cachedModes (unfiltered), which may cause subsequent getCustomModes() calls to return unfiltered data until TTL. Use separate caches or include the activeFamilyId in the cache key.

[James-Cherished]

I have difficulties pushing my fixes to git.
I have built a visualizer to help better understand my vision : see below.
I am afraid I might not have the time or funds to commit to this PR, I have created it in case someone wants to pick up the work.

[daniel-lxs]

Thanks for the effort on this! I’m going to close this PR for now - I’m not fully clear on what specific problem it’s solving. It would help to reword the proposal or description so it’s clearer why the current search bar isn’t sufficient and what behavior this change is improving.