MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-03-10 22:21:22 -07:00
Code Issues Packages Projects Releases Wiki Activity

Modify GCLI system prompt to conditionally use the CodebaseInvestigator (#10419)

Browse Source
This commit is contained in:
Silvio Junior
2025-10-02 15:37:44 -04:00
committed by GitHub
parent 452d0e21b6
commit 63efcb6b66
6 changed files with 247 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
packages/core/src/agents/codebase-investigator.ts
View File

@@ -64,9 +64,10 @@ const CODEBASE_REPORT_MARKDOWN = `<CodebaseReport>
export const CodebaseInvestigatorAgent: AgentDefinition = {
name: 'codebase_investigator',
displayName: 'Codebase Investigator Agent',
description: `Invoke this agent to delegates complex codebase exploration to an autonomous subagent.
Use for vague user requests that require searching multiple files to understand a feature or find context.
Returns a structured xml report with key file paths, symbols, architectural map and insights to solve a task.`,
description: `Your primary tool for multifile search tasks and codebase exploration.
Invoke this tool to delegate search tasks to an autonomous subagent.
Use this to find features, understand context, or locate specific files, functions, or symbols.
Returns a structured xml report with key file paths, symbols, architectural map and insights to solve a task or answer questions.`,
inputConfig: {
inputs: {
objective: {

54
packages/core/src/core/__snapshots__/prompts.test.ts.snap
View File

@@ -16,10 +16,12 @@ exports[`Core System Prompt (prompts.ts) > should append userMemory with separat
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -102,6 +104,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -132,6 +135,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -150,6 +154,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -162,6 +167,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -198,10 +204,12 @@ exports[`Core System Prompt (prompts.ts) > should include git instructions when
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -299,6 +307,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -329,6 +338,7 @@ All checks passed. This is a stable checkpoint.
Would you like me to write a commit message and commit these changes?
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -347,6 +357,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -359,6 +370,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -390,10 +402,12 @@ exports[`Core System Prompt (prompts.ts) > should include non-sandbox instructio
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -476,6 +490,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -506,6 +521,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -524,6 +540,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -536,6 +553,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -567,10 +585,12 @@ exports[`Core System Prompt (prompts.ts) > should include sandbox-specific instr
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -653,6 +673,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -683,6 +704,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -701,6 +723,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -713,6 +736,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -744,10 +768,12 @@ exports[`Core System Prompt (prompts.ts) > should include seatbelt-specific inst
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -830,6 +856,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -860,6 +887,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -878,6 +906,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -890,6 +919,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -921,10 +951,12 @@ exports[`Core System Prompt (prompts.ts) > should not include git instructions w
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -1007,6 +1039,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -1037,6 +1070,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -1055,6 +1089,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -1067,6 +1102,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -1098,10 +1134,12 @@ exports[`Core System Prompt (prompts.ts) > should return the base prompt when no
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -1184,6 +1222,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -1214,6 +1253,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -1232,6 +1272,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -1244,6 +1285,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -1275,10 +1317,12 @@ exports[`Core System Prompt (prompts.ts) > should return the base prompt when us
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -1361,6 +1405,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -1391,6 +1436,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -1409,6 +1455,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -1421,6 +1468,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:
@@ -1452,10 +1500,12 @@ exports[`Core System Prompt (prompts.ts) > should return the base prompt when us
- **Path Construction:** Before using any file system tool (e.g., read_file' or 'write_file'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
1. **Understand:** Think about the user's request and the relevant codebase context. Use 'search_file_content' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use 'read_file' and 'read_many_files' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
@@ -1538,6 +1588,7 @@ user: start the server implemented in server.js
model: [tool_call: run_shell_command for 'node server.js &' because it must run in the background]
</example>
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -1568,6 +1619,7 @@ All checks passed. This is a stable checkpoint.
</example>
<example>
user: Delete the temp directory.
model: I can run \`rm -rf /path/to/project/temp\`. This will permanently delete the directory and all its contents.
@@ -1586,6 +1638,7 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: run_shell_command for 'npm run test']
</example>
<example>
user: How do I update the user's profile information in this system?
model:
@@ -1598,6 +1651,7 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.
model:

2
packages/core/src/core/client.test.ts
View File

@@ -2406,7 +2406,7 @@ ${JSON.stringify(
model: DEFAULT_GEMINI_FLASH_MODEL,
config: {
abortSignal,
systemInstruction: getCoreSystemPrompt(''),
systemInstruction: getCoreSystemPrompt({} as unknown as Config, ''),
temperature: 0.5,
topP: 1,
},

4
packages/core/src/core/client.ts
View File

@@ -240,7 +240,7 @@ export class GeminiClient {
];
try {
const userMemory = this.config.getUserMemory();
const systemInstruction = getCoreSystemPrompt(userMemory);
const systemInstruction = getCoreSystemPrompt(this.config, userMemory);
const model = this.config.getModel();
const config: GenerateContentConfig = { ...this.generateContentConfig };
@@ -594,7 +594,7 @@ export class GeminiClient {
try {
const userMemory = this.config.getUserMemory();
const systemInstruction = getCoreSystemPrompt(userMemory);
const systemInstruction = getCoreSystemPrompt(this.config, userMemory);
const requestConfig: GenerateContentConfig = {
abortSignal,

129
packages/core/src/core/prompts.test.ts
View File

@@ -11,6 +11,8 @@ import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';
import { GEMINI_CONFIG_DIR } from '../tools/memoryTool.js';
import type { Config } from '../config/config.js';
import { CodebaseInvestigatorAgent } from '../agents/codebase-investigator.js';
// Mock tool names if they are dynamically generated or complex
vi.mock('../tools/ls', () => ({ LSTool: { Name: 'list_directory' } }));
@@ -27,21 +29,30 @@ vi.mock('../tools/shell', () => ({
vi.mock('../tools/write-file', () => ({
WriteFileTool: { Name: 'write_file' },
}));
vi.mock('../agents/codebase-investigator.js', () => ({
CodebaseInvestigatorAgent: { name: 'codebase_investigator' },
}));
vi.mock('../utils/gitUtils', () => ({
isGitRepository: vi.fn(),
}));
vi.mock('node:fs');
describe('Core System Prompt (prompts.ts)', () => {
let mockConfig: Config;
beforeEach(() => {
vi.resetAllMocks();
vi.stubEnv('GEMINI_SYSTEM_MD', undefined);
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', undefined);
mockConfig = {
getToolRegistry: vi.fn().mockReturnValue({
getAllToolNames: vi.fn().mockReturnValue([]),
}),
} as unknown as Config;
});
it('should return the base prompt when no userMemory is provided', () => {
vi.stubEnv('SANDBOX', undefined);
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig, '');
expect(prompt).not.toContain('---\n\n'); // Separator should not be present
expect(prompt).toContain('You are an interactive CLI agent'); // Check for core content
expect(prompt).toMatchSnapshot(); // Use snapshot for base prompt structure
@@ -49,7 +60,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should return the base prompt when userMemory is empty string', () => {
vi.stubEnv('SANDBOX', undefined);
const prompt = getCoreSystemPrompt('');
const prompt = getCoreSystemPrompt(mockConfig, '');
expect(prompt).not.toContain('---\n\n');
expect(prompt).toContain('You are an interactive CLI agent');
expect(prompt).toMatchSnapshot();
@@ -57,7 +68,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should return the base prompt when userMemory is whitespace only', () => {
vi.stubEnv('SANDBOX', undefined);
const prompt = getCoreSystemPrompt(' \n \t ');
const prompt = getCoreSystemPrompt(mockConfig, ' \n \t ');
expect(prompt).not.toContain('---\n\n');
expect(prompt).toContain('You are an interactive CLI agent');
expect(prompt).toMatchSnapshot();
@@ -67,7 +78,7 @@ describe('Core System Prompt (prompts.ts)', () => {
vi.stubEnv('SANDBOX', undefined);
const memory = 'This is custom user memory.\nBe extra polite.';
const expectedSuffix = `\n\n---\n\n${memory}`;
const prompt = getCoreSystemPrompt(memory);
const prompt = getCoreSystemPrompt(mockConfig, memory);
expect(prompt.endsWith(expectedSuffix)).toBe(true);
expect(prompt).toContain('You are an interactive CLI agent'); // Ensure base prompt follows
@@ -76,7 +87,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should include sandbox-specific instructions when SANDBOX env var is set', () => {
vi.stubEnv('SANDBOX', 'true'); // Generic sandbox value
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain('# Sandbox');
expect(prompt).not.toContain('# macOS Seatbelt');
expect(prompt).not.toContain('# Outside of Sandbox');
@@ -85,7 +96,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should include seatbelt-specific instructions when SANDBOX env var is "sandbox-exec"', () => {
vi.stubEnv('SANDBOX', 'sandbox-exec');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain('# macOS Seatbelt');
expect(prompt).not.toContain('# Sandbox');
expect(prompt).not.toContain('# Outside of Sandbox');
@@ -93,8 +104,8 @@ describe('Core System Prompt (prompts.ts)', () => {
});
it('should include non-sandbox instructions when SANDBOX env var is not set', () => {
vi.stubEnv('SANDBOX', undefined); // Ensure it's not set
const prompt = getCoreSystemPrompt();
vi.stubEnv('SANDBOX', undefined); // Ensure it\'s not set
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain('# Outside of Sandbox');
expect(prompt).not.toContain('# Sandbox');
expect(prompt).not.toContain('# macOS Seatbelt');
@@ -104,7 +115,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should include git instructions when in a git repo', () => {
vi.stubEnv('SANDBOX', undefined);
vi.mocked(isGitRepository).mockReturnValue(true);
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain('# Git Repository');
expect(prompt).toMatchSnapshot();
});
@@ -112,22 +123,92 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should not include git instructions when not in a git repo', () => {
vi.stubEnv('SANDBOX', undefined);
vi.mocked(isGitRepository).mockReturnValue(false);
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).not.toContain('# Git Repository');
expect(prompt).toMatchSnapshot();
});
describe('with CodebaseInvestigator enabled', () => {
beforeEach(() => {
mockConfig = {
getToolRegistry: vi.fn().mockReturnValue({
getAllToolNames: vi
.fn()
.mockReturnValue([CodebaseInvestigatorAgent.name]),
}),
} as unknown as Config;
});
it('should include CodebaseInvestigator instructions in the prompt', () => {
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain(
`your **first and primary tool** must be '${CodebaseInvestigatorAgent.name}'`,
);
expect(prompt).toContain(
`Do not ignore the output of '${CodebaseInvestigatorAgent.name}'`,
);
expect(prompt).not.toContain(
"Use 'search_file_content' and 'glob' search tools extensively",
);
});
it('should include CodebaseInvestigator examples in the prompt', () => {
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).toContain(
"First, I'll use the Codebase Investigator to understand the current implementation",
);
expect(prompt).toContain(
`[tool_call: ${CodebaseInvestigatorAgent.name} for query 'Analyze the authentication logic`,
);
expect(prompt).toContain(
"I'll use the Codebase Investigator to find the relevant code and APIs.",
);
expect(prompt).toContain(
`[tool_call: ${CodebaseInvestigatorAgent.name} for query 'Find the code responsible for updating user profile information`,
);
});
});
describe('with CodebaseInvestigator disabled', () => {
// No beforeEach needed, will use the default from the parent describe
it('should include standard tool instructions in the prompt', () => {
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).not.toContain(
`your **first and primary tool** must be '${CodebaseInvestigatorAgent.name}'`,
);
expect(prompt).toContain(
"Use 'search_file_content' and 'glob' search tools extensively",
);
});
it('should include standard tool examples in the prompt', () => {
const prompt = getCoreSystemPrompt(mockConfig);
expect(prompt).not.toContain(
"First, I'll use the Codebase Investigator to understand the current implementation",
);
expect(prompt).not.toContain(
`[tool_call: ${CodebaseInvestigatorAgent.name} for query 'Analyze the authentication logic`,
);
expect(prompt).toContain(
"First, I'll analyze the code and check for a test safety net before planning any changes.",
);
expect(prompt).toContain(
"I'm not immediately sure how user profile information is updated. I'll search the codebase for terms like 'UserProfile'",
);
});
});
describe('GEMINI_SYSTEM_MD environment variable', () => {
it('should use default prompt when GEMINI_SYSTEM_MD is "false"', () => {
vi.stubEnv('GEMINI_SYSTEM_MD', 'false');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).not.toHaveBeenCalled();
expect(prompt).not.toContain('custom system prompt');
});
it('should use default prompt when GEMINI_SYSTEM_MD is "0"', () => {
vi.stubEnv('GEMINI_SYSTEM_MD', '0');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).not.toHaveBeenCalled();
expect(prompt).not.toContain('custom system prompt');
});
@@ -136,7 +217,7 @@ describe('Core System Prompt (prompts.ts)', () => {
const customPath = '/non/existent/path/system.md';
vi.stubEnv('GEMINI_SYSTEM_MD', customPath);
vi.mocked(fs.existsSync).mockReturnValue(false);
expect(() => getCoreSystemPrompt()).toThrow(
expect(() => getCoreSystemPrompt(mockConfig)).toThrow(
`missing system prompt file '${path.resolve(customPath)}'`,
);
});
@@ -149,7 +230,7 @@ describe('Core System Prompt (prompts.ts)', () => {
vi.mocked(fs.existsSync).mockReturnValue(true);
vi.mocked(fs.readFileSync).mockReturnValue('custom system prompt');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).toHaveBeenCalledWith(defaultPath, 'utf8');
expect(prompt).toBe('custom system prompt');
});
@@ -162,7 +243,7 @@ describe('Core System Prompt (prompts.ts)', () => {
vi.mocked(fs.existsSync).mockReturnValue(true);
vi.mocked(fs.readFileSync).mockReturnValue('custom system prompt');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).toHaveBeenCalledWith(defaultPath, 'utf8');
expect(prompt).toBe('custom system prompt');
});
@@ -173,7 +254,7 @@ describe('Core System Prompt (prompts.ts)', () => {
vi.mocked(fs.existsSync).mockReturnValue(true);
vi.mocked(fs.readFileSync).mockReturnValue('custom system prompt');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).toHaveBeenCalledWith(customPath, 'utf8');
expect(prompt).toBe('custom system prompt');
});
@@ -187,7 +268,7 @@ describe('Core System Prompt (prompts.ts)', () => {
vi.mocked(fs.existsSync).mockReturnValue(true);
vi.mocked(fs.readFileSync).mockReturnValue('custom system prompt');
const prompt = getCoreSystemPrompt();
const prompt = getCoreSystemPrompt(mockConfig);
expect(fs.readFileSync).toHaveBeenCalledWith(
path.resolve(expectedPath),
'utf8',
@@ -199,13 +280,13 @@ describe('Core System Prompt (prompts.ts)', () => {
describe('GEMINI_WRITE_SYSTEM_MD environment variable', () => {
it('should not write to file when GEMINI_WRITE_SYSTEM_MD is "false"', () => {
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', 'false');
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).not.toHaveBeenCalled();
});
it('should not write to file when GEMINI_WRITE_SYSTEM_MD is "0"', () => {
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', '0');
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).not.toHaveBeenCalled();
});
@@ -214,7 +295,7 @@ describe('Core System Prompt (prompts.ts)', () => {
path.join(GEMINI_CONFIG_DIR, 'system.md'),
);
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', 'true');
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).toHaveBeenCalledWith(
defaultPath,
expect.any(String),
@@ -226,7 +307,7 @@ describe('Core System Prompt (prompts.ts)', () => {
path.join(GEMINI_CONFIG_DIR, 'system.md'),
);
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', '1');
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).toHaveBeenCalledWith(
defaultPath,
expect.any(String),
@@ -236,7 +317,7 @@ describe('Core System Prompt (prompts.ts)', () => {
it('should write to custom path when GEMINI_WRITE_SYSTEM_MD provides one', () => {
const customPath = path.resolve('/custom/path/system.md');
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', customPath);
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).toHaveBeenCalledWith(
customPath,
expect.any(String),
@@ -249,7 +330,7 @@ describe('Core System Prompt (prompts.ts)', () => {
const customPath = '~/custom/system.md';
const expectedPath = path.join(homeDir, 'custom/system.md');
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', customPath);
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).toHaveBeenCalledWith(
path.resolve(expectedPath),
expect.any(String),
@@ -262,7 +343,7 @@ describe('Core System Prompt (prompts.ts)', () => {
const customPath = '~';
const expectedPath = homeDir;
vi.stubEnv('GEMINI_WRITE_SYSTEM_MD', customPath);
getCoreSystemPrompt();
getCoreSystemPrompt(mockConfig);
expect(fs.writeFileSync).toHaveBeenCalledWith(
path.resolve(expectedPath),
expect.any(String),

85
packages/core/src/core/prompts.ts
View File

@@ -18,6 +18,8 @@ import { WriteFileTool } from '../tools/write-file.js';
import process from 'node:process';
import { isGitRepository } from '../utils/gitUtils.js';
import { MemoryTool, GEMINI_CONFIG_DIR } from '../tools/memoryTool.js';
import { CodebaseInvestigatorAgent } from '../agents/codebase-investigator.js';
import type { Config } from '../config/config.js';
export function resolvePathFromEnv(envVar?: string): {
isSwitch: boolean;
@@ -69,7 +71,10 @@ export function resolvePathFromEnv(envVar?: string): {
};
}
export function getCoreSystemPrompt(userMemory?: string): string {
export function getCoreSystemPrompt(
config: Config,
userMemory?: string,
): string {
// A flag to indicate whether the system prompt override is active.
let systemMdEnabled = false;
// The default path for the system prompt file. This can be overridden.
@@ -93,10 +98,15 @@ export function getCoreSystemPrompt(userMemory?: string): string {
throw new Error(`missing system prompt file '${systemMdPath}'`);
}
}
const enableCodebaseInvestigator = config
.getToolRegistry()
.getAllToolNames()
.includes(CodebaseInvestigatorAgent.name);
const basePrompt = systemMdEnabled
? fs.readFileSync(systemMdPath, 'utf8')
: `
You are an interactive CLI agent specializing in software engineering tasks. Your primary goal is to help users safely and efficiently, adhering strictly to the following instructions and utilizing your available tools.
: `You are an interactive CLI agent specializing in software engineering tasks. Your primary goal is to help users safely and efficiently, adhering strictly to the following instructions and utilizing your available tools.
# Core Mandates
@@ -111,12 +121,21 @@ You are an interactive CLI agent specializing in software engineering tasks. You
- **Path Construction:** Before using any file system tool (e.g., ${ReadFileTool.Name}' or '${WriteFileTool.Name}'), you must construct the full absolute path for the file_path argument. Always combine the absolute path of the project's root directory with the file's path relative to the root. For example, if the project root is /path/to/project/ and the file is foo/bar/baz.txt, the final path you must use is /path/to/project/foo/bar/baz.txt. If the user provides a relative path, you must resolve it against the root directory to create an absolute path.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
# Primary Workflows
## Software Engineering Tasks
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
${(function () {
if (enableCodebaseInvestigator) {
return `
1. **Understand & Strategize:** for any request that requires searching terms or explore the codebase, your **first and primary tool** must be '${CodebaseInvestigatorAgent.name}'. You must use it to build a comprehensive understanding of the relevant code, its structure, and dependencies. The output from '${CodebaseInvestigatorAgent.name}' will be the foundation of your plan. YOU MUST not use '${GrepTool.Name}' or '${GlobTool.Name}' as your initial exploration tool; they should only be used for secondary, targeted searches after the investigator has provided you with context.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Do not ignore the output of '${CodebaseInvestigatorAgent.name}', you must use it as the foundation of your plan. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.`;
}
return `
1. **Understand:** Think about the user's request and the relevant codebase context. Use '${GrepTool.Name}' and '${GlobTool.Name}' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use '${ReadFileTool.Name}' and '${ReadManyFilesTool.Name}' to understand context and validate any assumptions you may have.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.
2. **Plan:** Build a coherent and grounded (based on the understanding in step 1) plan for how you intend to resolve the user's task. Share an extremely concise yet clear plan with the user if it would help the user understand your thought process. As part of the plan, you should use an iterative development process that includes writing unit tests to verify your changes. Use output logs or debug statements as part of this process to arrive at a solution.`;
})()}
3. **Implement:** Use the available tools (e.g., '${EditTool.Name}', '${WriteFileTool.Name}' '${ShellTool.Name}' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands.
5. **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards. If unsure about these commands, you can ask the user if they'd like you to run them and if so how to.
@@ -235,6 +254,41 @@ user: start the server implemented in server.js
model: [tool_call: ${ShellTool.Name} for 'node server.js &' because it must run in the background]
</example>
${(function () {
if (enableCodebaseInvestigator) {
return `
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
First, I'll use the Codebase Investigator to understand the current implementation and find relevant tests.
[tool_call: ${CodebaseInvestigatorAgent.name} for query 'Analyze the authentication logic in src/auth.py, its dependencies, and any related tests to prepare for a refactoring from urllib to requests.']
(After analysis from the agent)
The investigator's report confirms that 'tests/test_auth.py' covers the core logic and that 'requests' is already in 'requirements.txt'. The report also highlighted the key functions using 'urllib'. With this information, I can form a solid plan.
Here's the plan:
1. Replace the 'urllib' calls with 'requests' in the functions identified by the investigator.
2. Add proper 'try...except' error handling for the new network calls.
3. Remove the old 'urllib' import.
4. Run the project's linter and tests to verify the changes.
Should I proceed?
user: Yes
model:
[tool_call: ${WriteFileTool.Name} or ${EditTool.Name} to apply the refactoring to 'src/auth.py']
Refactoring complete. Running verification...
[tool_call: ${ShellTool.Name} for 'ruff check src/auth.py && pytest']
(After verification passes)
All checks passed. This is a stable checkpoint.
${(function () {
if (isGitRepository(process.cwd())) {
return `Would you like me to write a commit message and commit these changes?`;
}
return '';
})()}
</example>
`;
} else {
return `
<example>
user: Refactor the auth logic in src/auth.py to use the requests library instead of urllib.
model: Okay, I can refactor 'src/auth.py'.
@@ -269,6 +323,9 @@ ${(function () {
return '';
})()}
</example>
`;
}
})()}
<example>
user: Delete the temp directory.
@@ -288,6 +345,23 @@ I've written the tests. Now I'll run the project's test command to verify them.
[tool_call: ${ShellTool.Name} for 'npm run test']
</example>
${(function () {
if (enableCodebaseInvestigator) {
return `
<example>
user: How do I update the user's profile information in this system?
model:
I'm not immediately sure how user profile information is updated. I'll use the Codebase Investigator to find the relevant code and APIs.
[tool_call: ${CodebaseInvestigatorAgent.name} for query 'Find the code responsible for updating user profile information. Identify the relevant services, methods, and data transfer objects.']
(After reviewing the investigator's report, which highlights 'UserProfileService.java' and the 'updateUserProfile' method)
The investigator's report points to \`/path/to/UserProfileService.java\` as the key component. I'll read its content to get the specific details.
[tool_call: ${ReadFileTool.Name} for absolute_path '/path/to/UserProfileService.java']
(After reading the file)
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
`;
} else {
return `
<example>
user: How do I update the user's profile information in this system?
model:
@@ -299,6 +373,9 @@ Okay, \`/path/to/UserProfileService.java\` seems like the most relevant file. I'
(After reading the file)
It appears the \`updateUserProfile\` method in \`UserProfileService.java\` is responsible for this. It expects a user ID and a \`UserProfileDTO\` object...
</example>
`;
}
})()}
<example>
user: Where are all the 'app.config' files in this project? I need to check their settings.