switch_mode

The switch_mode tool enables VJSP to switch between different operating modes, each with specialized capabilities for specific task types. When the current task requires different professional capabilities, seamless switching between code mode, architecture mode, consulting mode, debugging mode, and other modes is supported.

Parameter Description

The tool accepts the following parameters:

• mode_slug (required): Identifier for the target mode to switch to (examples: "code", "ask", "architect")
• reason (optional): Reason for the mode switch, providing contextual explanation for the user

Functionality

When the current task is better suited for the capabilities of another mode, a mode switch request can be initiated using this tool. Upon completing the mode switch, the tool adjusts VJSP's core focus direction and available toolset to match the requirements of the new task phase while maintaining task context continuity.

Application Scenarios

• Transitioning from the information gathering phase to the code implementation phase
• Switching from code development to architecture design
• When the current task requires calling exclusive capabilities only available in other modes
• When specific phases of complex projects require specialized domain expertise

Core Features

• Maintains task context continuity during cross-mode switching
• Provides clear explanations for mode switch recommendations
• Requires user confirmation for all mode switch operations
• Strictly enforces tool group usage restrictions specific to each mode
• Seamlessly adapts the available toolset based on the selected mode
• Supports switching between both standard and custom modes
• Displays mode switch operations and corresponding reasons in the user interface
• Adopts XML format for standardized parameter definition
• Adapts to file type restriction rules corresponding to specific modes

Limitations

• Cannot switch to modes not defined in the system
• Each mode switch requires explicit user confirmation
• Cannot call exclusive tools of the target mode before the mode switch is complete
• A 500-millisecond delay is triggered after mode switch to ensure the operation takes effect
• Some modes have file type restrictions (example: architecture mode only supports editing Markdown files)
• Mode recovery retention mechanism only applies to the new_task function, not to regular mode switch operations

Execution Flow

After calling the switch_mode tool, the following process will be executed:

1. Request Validation

   • Verify that the target mode to switch to is defined in the system
   • Check that the required parameter mode_slug has been passed and has a valid format
   • Confirm that the system is not already in the target mode
   • If the optional parameter reason is passed, verify its format is compliant

2. Switch Preparation

   • Package the mode switch request with the passed reason information
   • Display the mode switch request to the user and wait for confirmation

3. Mode Activation (After User Confirmation)

   • Update the user interface to display the newly switched mode
   • Adjust the system's available toolset according to the target mode's tool group configuration
   • Load the target mode's exclusive prompts and behavior rules
   • Trigger a 500-millisecond delay to ensure the mode switch takes effect before executing subsequent tool calls
   • Enable file type restriction rules corresponding to the target mode

4. Task Continuation

   • Accept and continue executing the current task based on the capabilities of the new mode
   • Retain relevant task context from previous interaction processes

Tool Group Affiliation

The switch_mode tool belongs to the "modes" tool group and is also included in the "always available" tool list, with the following characteristics:

• Not restricted by mode tool group configuration, can be called in any mode
• Coexists globally with core tools such as ask_followup_question and attempt_completion
• Can initiate mode switches at any node in the workflow when task requirements change

Mode Structure

Each mode in the system follows the following fixed structure definition:

• slug: Unique identifier for the mode (examples: "code", "ask")
• name: Display name of the mode in the interface (examples: "Code", "Ask")
• roleDefinition: Exclusive role positioning and core capability description for the mode
• customInstructions: Optional configuration for guiding exclusive rules for mode behavior
• groups: List of tool groups that can be called by the mode, supporting configuration of exclusive usage restrictions

Mode Capabilities

The system's core modes have the following exclusive capabilities:

• Code Mode: Focuses on code development tasks, supports calling the full set of code editing tools
• Architecture Mode: Specialized for system design and architecture planning, only supports editing Markdown files
• Consulting Mode: Optimized for question answering and information provision scenarios
• Debug Mode: Equipped with systematic problem diagnosis and troubleshooting capabilities

Custom Modes

In addition to core modes, the system supports defining custom modes based on specific project requirements, with the following characteristics:

• Can configure exclusive enabled tool groups for custom modes
• Can customize the role positioning and behavior rules of the mode
• The system will prioritize checking custom modes, and call core modes if no match is found
• If a custom mode has the same identifier (slug) as a core mode, the custom mode definition will override the core mode

File Type Restrictions

Different modes can be configured with exclusive file type restriction rules, with core rules as follows:

• Architecture Mode: Only supports editing files with the .md extension
• When attempting to edit restricted file types, the system will throw a FileRestrictionError exception
• This restriction mechanism is used to standardize the responsibility boundaries of different modes and ensure clear task division

Typical Application Examples

• When discussing new feature requirements, VJSP switches from consulting mode to architecture mode to assist with system structure design
• After architecture planning is completed in architecture mode, VJSP switches to code mode to implement the designed functionality
• When encountering program defects during development, VJSP switches from code mode to debug mode to conduct systematic problem investigation

Calling Examples

Switching to code mode for function implementation:

<switch_mode>
<mode_slug>code</mode_slug>
<reason>Based on the confirmed architecture plan, implement the login function module</reason>
</switch_mode>

Switching to architecture mode for plan design:

<switch_mode>
<mode_slug>architect</mode_slug>
<reason>Complete the overall system architecture plan design before function implementation</reason>
</switch_mode>

Switching to debug mode for problem investigation:

<switch_mode>
<mode_slug>debug</mode_slug>
<reason>Conduct systematic diagnostic investigation on abnormalities in the authentication process</reason>
</switch_mode>

Switching to consulting mode for question answering:

<switch_mode>
<mode_slug>ask</mode_slug>
<reason>Answer related consultation questions regarding the implemented function module</reason>
</switch_mode>