Feature Request

Summary

The kilocode CLI currently does not support loading custom modes from custom_modes.yaml, while the VS Code extension does. This creates an inconsistency between the two interfaces.

Current Behavior

VS Code Extension ✅

• Loads custom modes from ~/.../globalStorage/kilocode.kilo-code/settings/custom_modes.yaml
• Supports project-specific .kilocodemodes files
• Users can define custom modes with specific roles, permissions, and instructions

CLI ❌

• Only supports 5 hardcoded built-in modes: architect, code, ask, debug, orchestrator
• Does not read custom_modes.yaml file
• Does not support .kilocodemodes files

Expected Behavior

The CLI should load and support custom modes from:

1. Global: ~/.../globalStorage/kilocode.kilo-code/settings/custom_modes.yaml
2. Project: .kilocodemodes (in project root)

This would allow users to use the same custom modes (e.g., intern, junior, senior, micromanager, designer, etc.) in both the CLI and VS Code extension.

Use Case

Users who have invested time creating sophisticated custom mode hierarchies (like apprentice → junior → midlevel → senior workflows) should be able to use these modes consistently across both interfaces.

Implementation Notes

The custom_modes.yaml file format is already well-defined and used by the extension:

customModes:
  - slug: mode-identifier
    name: Display Name
    roleDefinition: Role description
    customInstructions: Detailed instructions
    groups:
      - read
      - edit
      - browser
      - command
      - mcp
    source: global

The CLI would need to:

1. Detect and read custom_modes.yaml from the global storage location
2. Detect and read .kilocodemodes from the project directory
3. Merge custom modes with built-in modes
4. Update the -m, --mode <mode> option to include custom mode slugs in validation

Benefits

• Consistency: Same modes work in both CLI and extension
• Flexibility: Users can leverage custom modes for CLI automation
• Workflow efficiency: Complex mode hierarchies work everywhere
• User experience: No confusion about why modes work in one interface but not the other

Related

This is related to #3063 (importing settings from VS Code extension) but specifically focuses on custom modes support.