mirror of
https://github.com/RooVetGit/Roo-Code.git
synced 2026-08-28 05:27:24 +00:00
feat: change default mode to architect for new installations (#5289)
* feat: change default mode to architect for new installations - Reordered modes array to put architect mode first - Updated test to reflect architect as the default mode - Maintains backward compatibility for existing users * test: update snapshots and fix tests for architect default mode - Update all snapshot tests to reflect architect as the default mode - Fix mode destructuring in validateToolUse tests - All tests now pass with the new default mode configuration * docs: add comment explaining mode ordering for default selection Addresses PR review feedback to clarify that the first mode in the array serves as the default for new installations * fix: Update integration test to use lowercase mode name The test was using 'Ask' (capitalized) but modes are now lowercase 'ask'. This was causing the test to timeout as the mode validation failed.
This commit is contained in:
Hannes Rudolph
GitHub
parent
298908fe1d
commit
18c3f5dc33
26 changed files with 192 additions and 288 deletions
|
|
@ -20,7 +20,7 @@ suite("Roo Code Task", function () {
|
|||
})
|
||||
|
||||
const taskId = await api.startNewTask({
|
||||
configuration: { mode: "Ask", alwaysAllowModeSwitch: true, autoApprovalEnabled: true },
|
||||
configuration: { mode: "ask", alwaysAllowModeSwitch: true, autoApprovalEnabled: true },
|
||||
text: "Hello world, what is your name? Respond with 'My name is ...'",
|
||||
})
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ USER'S CUSTOM INSTRUCTIONS
|
|||
The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-architect:
|
||||
# Rules from .clinerules-code:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -6,7 +6,7 @@ USER'S CUSTOM INSTRUCTIONS
|
|||
The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -12,7 +12,7 @@ Mode-specific Instructions:
|
|||
Custom test instructions
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -6,7 +6,7 @@ USER'S CUSTOM INSTRUCTIONS
|
|||
The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -6,7 +6,7 @@ USER'S CUSTOM INSTRUCTIONS
|
|||
The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -12,7 +12,7 @@ Mode-specific Instructions:
|
|||
Mode-specific instructions
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## use_mcp_tool
|
||||
Description: Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
|
||||
Parameters:
|
||||
|
|
@ -558,8 +536,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## use_mcp_tool
|
||||
Description: Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
|
||||
Parameters:
|
||||
|
|
@ -564,8 +542,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -274,28 +274,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -501,8 +479,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -12,7 +12,7 @@ Mode-specific Instructions:
|
|||
Second instruction
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -9,7 +9,7 @@ Mode-specific Instructions:
|
|||
Custom mode instructions
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -6,7 +6,7 @@ USER'S CUSTOM INSTRUCTIONS
|
|||
The following additional instructions are provided by the user, and should be followed to the best of your ability without interfering with the TOOL USE guidelines.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -9,7 +9,7 @@ Mode-specific Instructions:
|
|||
Custom test instructions
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -9,7 +9,7 @@ Language Preference:
|
|||
You should always speak and think in the "es" language.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -496,8 +474,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -322,28 +322,6 @@ Example: Requesting to click on the element at coordinates 450,300
|
|||
<coordinate>450,300</coordinate>
|
||||
</browser_action>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -552,8 +530,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -496,8 +474,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -357,28 +357,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -584,8 +562,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -496,8 +474,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -322,28 +322,6 @@ Example: Requesting to click on the element at coordinates 450,300
|
|||
<coordinate>450,300</coordinate>
|
||||
</browser_action>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -552,8 +530,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## use_mcp_tool
|
||||
Description: Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
|
||||
Parameters:
|
||||
|
|
@ -564,8 +542,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.
|
||||
You are Roo, an experienced technical leader who is inquisitive and an excellent planner. Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
|
||||
|
||||
====
|
||||
|
||||
|
|
@ -269,28 +269,6 @@ Examples:
|
|||
<ignore_case>true</ignore_case>
|
||||
</search_and_replace>
|
||||
|
||||
## execute_command
|
||||
Description: Request to execute a CLI command on the system. Use this when you need to perform system operations or run specific commands to accomplish any step in the user's task. You must tailor your command to the user's system and provide a clear explanation of what the command does. For command chaining, use the appropriate chaining syntax for the user's shell. Prefer to execute complex CLI commands over creating executable scripts, as they are more flexible and easier to run. Prefer relative commands and paths that avoid location sensitivity for terminal consistency, e.g: `touch ./testdata/example.file`, `dir ./examples/model1/data/yaml`, or `go test ./cmd/front --config ./cmd/front/config.yml`. If directed by the user, you may open a terminal in a different directory by using the `cwd` parameter.
|
||||
Parameters:
|
||||
- command: (required) The CLI command to execute. This should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
|
||||
- cwd: (optional) The working directory to execute the command in (default: /test/path)
|
||||
Usage:
|
||||
<execute_command>
|
||||
<command>Your command here</command>
|
||||
<cwd>Working directory path (optional)</cwd>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute npm run dev
|
||||
<execute_command>
|
||||
<command>npm run dev</command>
|
||||
</execute_command>
|
||||
|
||||
Example: Requesting to execute ls in a specific directory if directed
|
||||
<execute_command>
|
||||
<command>ls -la</command>
|
||||
<cwd>/home/user/projects</cwd>
|
||||
</execute_command>
|
||||
|
||||
## ask_followup_question
|
||||
Description: Ask the user a question to gather additional information needed to complete the task. This tool should be used when you encounter ambiguities, need clarification, or require more details to proceed effectively. It allows for interactive problem-solving by enabling direct communication with the user. Use this tool judiciously to maintain a balance between gathering necessary information and avoiding excessive back-and-forth.
|
||||
Parameters:
|
||||
|
|
@ -496,8 +474,21 @@ The following additional instructions are provided by the user, and should be fo
|
|||
Language Preference:
|
||||
You should always speak and think in the "en" language.
|
||||
|
||||
Mode-specific Instructions:
|
||||
1. Do some information gathering (for example using read_file or search_files) to get more context about the task.
|
||||
|
||||
2. You should also ask the user clarifying questions to get a better understanding of the task.
|
||||
|
||||
3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.
|
||||
|
||||
4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.
|
||||
|
||||
5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.
|
||||
|
||||
6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.
|
||||
|
||||
Rules:
|
||||
# Rules from .clinerules-code:
|
||||
# Rules from .clinerules-architect:
|
||||
Mock mode-specific rules
|
||||
# Rules from .clinerules:
|
||||
Mock generic rules
|
||||
|
|
@ -7,7 +7,9 @@ import { TOOL_GROUPS } from "../../../shared/tools"
|
|||
|
||||
import { validateToolUse } from "../validateToolUse"
|
||||
|
||||
const [codeMode, architectMode, askMode] = modes.map((mode) => mode.slug)
|
||||
const codeMode = modes.find((m) => m.slug === "code")?.slug || "code"
|
||||
const architectMode = modes.find((m) => m.slug === "architect")?.slug || "architect"
|
||||
const askMode = modes.find((m) => m.slug === "ask")?.slug || "ask"
|
||||
|
||||
describe("mode-validator", () => {
|
||||
describe("isToolAllowedForMode", () => {
|
||||
|
|
|
|||
|
|
@ -356,7 +356,7 @@ describe("FileRestrictionError", () => {
|
|||
const result = await getFullModeDetails("non-existent")
|
||||
expect(result).toMatchObject({
|
||||
...modes[0],
|
||||
customInstructions: "",
|
||||
// The first mode (architect) has its own customInstructions
|
||||
})
|
||||
})
|
||||
})
|
||||
|
|
|
|||
|
|
@ -60,17 +60,8 @@ export function getToolsForMode(groups: readonly GroupEntry[]): string[] {
|
|||
}
|
||||
|
||||
// Main modes configuration as an ordered array
|
||||
// Note: The first mode in this array is the default mode for new installations
|
||||
export const modes: readonly ModeConfig[] = [
|
||||
{
|
||||
slug: "code",
|
||||
name: "💻 Code",
|
||||
roleDefinition:
|
||||
"You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.",
|
||||
whenToUse:
|
||||
"Use this mode when you need to write, modify, or refactor code. Ideal for implementing features, fixing bugs, creating new files, or making code improvements across any programming language or framework.",
|
||||
description: "Write, modify, and refactor code",
|
||||
groups: ["read", "edit", "browser", "command", "mcp"],
|
||||
},
|
||||
{
|
||||
slug: "architect",
|
||||
name: "🏗️ Architect",
|
||||
|
|
@ -83,6 +74,16 @@ export const modes: readonly ModeConfig[] = [
|
|||
customInstructions:
|
||||
"1. Do some information gathering (for example using read_file or search_files) to get more context about the task.\n\n2. You should also ask the user clarifying questions to get a better understanding of the task.\n\n3. Once you've gained more context about the user's request, you should create a detailed plan for how to accomplish the task. Include Mermaid diagrams if they help make your plan clearer.\n\n4. Ask the user if they are pleased with this plan, or if they would like to make any changes. Think of this as a brainstorming session where you can discuss the task and plan the best way to accomplish it.\n\n5. Once the user confirms the plan, ask them if they'd like you to write it to a markdown file.\n\n6. Use the switch_mode tool to request that the user switch to another mode to implement the solution.",
|
||||
},
|
||||
{
|
||||
slug: "code",
|
||||
name: "💻 Code",
|
||||
roleDefinition:
|
||||
"You are Roo, a highly skilled software engineer with extensive knowledge in many programming languages, frameworks, design patterns, and best practices.",
|
||||
whenToUse:
|
||||
"Use this mode when you need to write, modify, or refactor code. Ideal for implementing features, fixing bugs, creating new files, or making code improvements across any programming language or framework.",
|
||||
description: "Write, modify, and refactor code",
|
||||
groups: ["read", "edit", "browser", "command", "mcp"],
|
||||
},
|
||||
{
|
||||
slug: "ask",
|
||||
name: "❓ Ask",
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue