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

[James-Cherished]

[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.

[James-Cherished]

I might not have the time to pursue this PR, if anyone is interested here is the Architect's plan

Mode Families Feature Implementation Plan

Based on your requirements and the current codebase analysis, I'll create a comprehensive plan for implementing mode families that organize and filter custom modes.

Architecture Overview

graph TB
    A[User Interface] --> B[ModeFamiliesSettings]
    A --> C[ModesView Integration]
    B --> D[ModeFamiliesManager]
    C --> D
    D --> E[VS Code Settings Storage]
    D --> F[CustomModesManager]
    F --> G[Mode Filtering Logic]
    G --> H[Active Modes List]
    H --> I[Chat Interface]
    H --> J[Mode Selection Dropdown]

Loading

Data Structure Design

Mode Family Schema:

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

interface ModeFamiliesConfig {
    activeFamilyId?: string
    families: Record<string, ModeFamily>
    lastUpdated: number
}

Implementation Plan

Phase 1: Backend Foundation

1.1 Create ModeFamiliesManager Class

• Location: src/core/config/ModeFamiliesManager.ts
• Responsibilities:
  • Family CRUD operations (create, read, update, delete)
  • Active family management
  • Integration with VS Code settings storage
  • Default family creation

1.2 Design Storage Schema

• Use VS Code extension context global state
• Key: modeFamilies → ModeFamiliesConfig
• Provide migration logic for existing installations

1.3 Integrate with CustomModesManager

• Modify getCustomModes() to filter based on active family
• Add family-aware mode retrieval methods
• Maintain backward compatibility

Phase 2: Frontend Integration

2.1 Create ModeFamiliesSettings Component

• Location: webview-ui/src/components/settings/ModeFamiliesSettings.tsx
• Features:
  • Family list with create/edit/delete
  • Mode toggle interface for each family
  • Active family selector
  • Default family designation

2.2 Integrate into Existing Modes Management

• Add "Families" section to current modes settings
• Modify ModesView to show family context
• Add family indicator in mode cards

2.3 Add Family Selector to Main Interface

• Integrate family dropdown into SettingsView
• Show current active family in modes interface
• Provide quick family switching

Phase 3: User Experience Enhancements

3.1 Mode Validation System

• Validate that enabled modes exist in current configuration
• Show warnings for missing modes
• Auto-disable invalid modes in families

3.2 Default Family Creation

• Auto-create "All Modes" family on first run
• Include all built-in and existing custom modes
• Set as active family by default

3.3 Visual Feedback

• Show which family is currently active
• Indicate mode status (enabled/disabled in current family)
• Provide clear family management interface

Detailed Component Structure

webview-ui/src/components/settings/
├── ModeFamiliesSettings.tsx (Main container)
├── ModeFamiliesList.tsx (Family management)
├── ModeFamilyEditor.tsx (Create/edit family)
├── ModeToggleGrid.tsx (Mode selection interface)
└── FamilySelector.tsx (Active family dropdown)

Integration Points

Backend Integration

1. Extension State Management: Add family state to extension context
2. Message Passing: Add family-related message types
3. Mode Resolution: Modify mode resolution to respect family filtering

Frontend Integration

1. Settings Tab: Add "Mode Families" section to settings
2. State Management: Integrate family state into extension state context
3. Mode Cards: Show family membership status in mode listings

Migration Strategy

1. First Run Detection: Check if mode families exist
2. Default Family Creation: Auto-create "All Modes" family
3. Existing Modes Integration: Include all current modes in default family
4. Backward Compatibility: Ensure existing behavior works unchanged

Validation & Error Handling

• Mode Existence: Validate all enabled modes exist
• Family Consistency: Ensure at least one mode per family
• Default Family: Always maintain a valid default family
• Storage Errors: Handle settings storage failures gracefully

Testing Strategy

1. Unit Tests: Test family CRUD operations
2. Integration Tests: Test mode filtering with families
3. UI Tests: Test family management interface
4. End-to-End: Test complete family switching workflow

User Interface Flow

sequenceDiagram
    participant U as User
    participant S as Settings
    participant F as ModeFamiliesManager
    participant M as CustomModesManager
    
    U->>S: Opens Mode Families settings
    S->>F: Load families configuration
    F->>S: Return families list
    S->>U: Display families and modes
    
    U->>S: Creates new family
    S->>F: Save new family
    F->>S: Confirm creation
    
    U->>S: Toggles modes in family
    S->>F: Update family mode list
    F->>S: Confirm update
    
    U->>S: Selects active family
    S->>M: Set active family filter
    M->>S: Update available modes
    S->>U: Refresh mode interface

Loading

Benefits of This Architecture

1. Non-intrusive: Existing mode system continues to work unchanged
2. Flexible: Users can create families for different workflows
3. Scalable: Easy to add new family-related features
4. Maintainable: Clear separation of concerns
5. User-friendly: Intuitive family management interface

[roomote]

I'm exploring a potential implementation of the Mode Families feature based on the detailed plan provided. I'll work on organizing custom modes into grouped collections as described and will open a PR to share progress.

[James-Cherished]

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.

I have built a visualizer to help better understand my vision : see below.

[James-Cherished]

I have used a left menu to navigate between the Custom Modes, I would recommend a similar left or top navigable menu instead of a dropdown menu to switch between modes and edit them more easily in Roo UI.

It feels much more fluid and provides much better UX imho.

[daniel-lxs]

Please see #8496 (comment)