MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-06-12 20:37:08 -07:00
Code Issues Packages Projects Releases Wiki Activity

feat(tools): implement tactful extraction rework for token efficiency

Browse Source 
This PR optimizes how the agent explores and reads code by providing precision extraction tools and mandating token frugality.

Key Changes:
- Restore precision to read_file with 1-based start_line and end_line for Gemini 3.
- Update tool descriptions to establish extraction hierarchy (rg > shell/sed > read_file).
- Codify 'Be Token-Frugal' mandate in system prompt snippets.
- Refine research workflow to allow context-based validation via search tools.
- Merge latest main improvements including Search Frugality parameters.
- Update unit tests and verified build integrity.
This commit is contained in:
Adam Weidman
2026-02-12 11:32:32 -05:00
parent e3a9f16579
commit 59bdc064d1
6 changed files with 337 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files
package-lock.json
Generated
+24 -1
View File
@@ -2232,6 +2232,7 @@
"integrity": "sha512-t54CUOsFMappY1Jbzb7fetWeO0n6K0k/4+/ZpkS+3Joz8I4VcvY9OiEBFRYISqaI2fq5sCiPtAjRDOzVYG8m+Q==",
"dev": true,
"license": "MIT",
"peer": true,
"dependencies": {
"@octokit/auth-token": "^6.0.0",
"@octokit/graphql": "^9.0.2",
@@ -2412,6 +2413,7 @@
"resolved": "https://registry.npmjs.org/@opentelemetry/api/-/api-1.9.0.tgz",
"integrity": "sha512-3giAOQvZiH5F9bMlMiv8+GSPMeqg0dbaeo58/0SlA9sxSqZhnUtxzX9/2FzyhS9sWQf5S0GJE0AKBrFqjpeYcg==",
"license": "Apache-2.0",
"peer": true,
"engines": {
"node": ">=8.0.0"
}
@@ -2461,6 +2463,7 @@
"resolved": "https://registry.npmjs.org/@opentelemetry/core/-/core-2.5.0.tgz",
"integrity": "sha512-ka4H8OM6+DlUhSAZpONu0cPBtPPTQKxbxVzC4CzVx5+K4JnroJVBtDzLAMx4/3CDTJXRvVFhpFjtl4SaiTNoyQ==",
"license": "Apache-2.0",
"peer": true,
"dependencies": {
"@opentelemetry/semantic-conventions": "^1.29.0"
},
@@ -2835,6 +2838,7 @@
"resolved": "https://registry.npmjs.org/@opentelemetry/resources/-/resources-2.5.0.tgz",
"integrity": "sha512-F8W52ApePshpoSrfsSk1H2yJn9aKjCrbpQF1M9Qii0GHzbfVeFUB+rc3X4aggyZD8x9Gu3Slua+s6krmq6Dt8g==",
"license": "Apache-2.0",
"peer": true,
"dependencies": {
"@opentelemetry/core": "2.5.0",
"@opentelemetry/semantic-conventions": "^1.29.0"
@@ -2868,6 +2872,7 @@
"resolved": "https://registry.npmjs.org/@opentelemetry/sdk-metrics/-/sdk-metrics-2.5.0.tgz",
"integrity": "sha512-BeJLtU+f5Gf905cJX9vXFQorAr6TAfK3SPvTFqP+scfIpDQEJfRaGJWta7sJgP+m4dNtBf9y3yvBKVAZZtJQVA==",
"license": "Apache-2.0",
"peer": true,
"dependencies": {
"@opentelemetry/core": "2.5.0",
"@opentelemetry/resources": "2.5.0"
@@ -2922,6 +2927,7 @@
"resolved": "https://registry.npmjs.org/@opentelemetry/sdk-trace-base/-/sdk-trace-base-2.5.0.tgz",
"integrity": "sha512-VzRf8LzotASEyNDUxTdaJ9IRJ1/h692WyArDBInf5puLCjxbICD6XkHgpuudis56EndyS7LYFmtTMny6UABNdQ==",
"license": "Apache-2.0",
"peer": true,
"dependencies": {
"@opentelemetry/core": "2.5.0",
"@opentelemetry/resources": "2.5.0",
@@ -4095,6 +4101,7 @@
"integrity": "sha512-6mDvHUFSjyT2B2yeNx2nUgMxh9LtOWvkhIU3uePn2I2oyNymUAX1NIsdgviM4CH+JSrp2D2hsMvJOkxY+0wNRA==",
"devOptional": true,
"license": "MIT",
"peer": true,
"dependencies": {
"csstype": "^3.0.2"
}
@@ -4369,6 +4376,7 @@
"integrity": "sha512-6sMvZePQrnZH2/cJkwRpkT7DxoAWh+g6+GFRK6bV3YQo7ogi3SX5rgF6099r5Q53Ma5qeT7LGmOmuIutF4t3lA==",
"dev": true,
"license": "MIT",
"peer": true,
"dependencies": {
"@typescript-eslint/scope-manager": "8.35.0",
"@typescript-eslint/types": "8.35.0",
@@ -5361,6 +5369,7 @@
"resolved": "https://registry.npmjs.org/acorn/-/acorn-8.15.0.tgz",
"integrity": "sha512-NZyJarBfL7nWwIq+FDL6Zp/yHEhePMNnnJ0y3qfieCrmNvYct8uvtiV41UvlSe6apAfk0fY1FbWx+NwfmpvtTg==",
"license": "MIT",
"peer": true,
"bin": {
"acorn": "bin/acorn"
},
@@ -7900,6 +7909,7 @@
"integrity": "sha512-GsGizj2Y1rCWDu6XoEekL3RLilp0voSePurjZIkxL3wlm5o5EC9VpgaP7lrCvjnkuLvzFBQWB3vWB3K5KQTveQ==",
"dev": true,
"license": "MIT",
"peer": true,
"dependencies": {
"@eslint-community/eslint-utils": "^4.2.0",
"@eslint-community/regexpp": "^4.12.1",
@@ -8420,6 +8430,7 @@
"resolved": "https://registry.npmjs.org/express/-/express-5.2.1.tgz",
"integrity": "sha512-hIS4idWWai69NezIdRt2xFVofaF4j+6INOpJlVOLDO8zXGpUVEVzIYk12UUi2JzjEzWL3IOAxcTubgz9Po0yXw==",
"license": "MIT",
"peer": true,
"dependencies": {
"accepts": "^2.0.0",
"body-parser": "^2.2.1",
@@ -10026,6 +10037,7 @@
"resolved": "https://registry.npmjs.org/@jrichman/ink/-/ink-6.4.10.tgz",
"integrity": "sha512-kjJqZFkGVm0QyJmga/L02rsFJroF1aP2bhXEGkpuuT7clB6/W+gxAbLNw7ZaJrG6T30DgqOT92Pu6C9mK1FWyg==",
"license": "MIT",
"peer": true,
"dependencies": {
"@alcalzone/ansi-tokenize": "^0.2.1",
"ansi-escapes": "^7.0.0",
@@ -13697,6 +13709,7 @@
"resolved": "https://registry.npmjs.org/react/-/react-19.2.0.tgz",
"integrity": "sha512-tmbWg6W31tQLeB5cdIBOicJDJRR2KzXsV7uSK9iNfLWQ5bIZfxuPEHp7M8wiHyHnn0DD1i7w3Zmin0FtkrwoCQ==",
"license": "MIT",
"peer": true,
"engines": {
"node": ">=0.10.0"
}
@@ -13707,6 +13720,7 @@
"integrity": "sha512-ePrwPfxAnB+7hgnEr8vpKxL9cmnp7F322t8oqcPshbIQQhDKgFDW4tjhF2wjVbdXF9O/nyuy3sQWd9JGpiLPvA==",
"devOptional": true,
"license": "MIT",
"peer": true,
"dependencies": {
"shell-quote": "^1.6.1",
"ws": "^7"
@@ -15869,6 +15883,7 @@
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.3.tgz",
"integrity": "sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==",
"license": "MIT",
"peer": true,
"engines": {
"node": ">=12"
},
@@ -16092,7 +16107,8 @@
"resolved": "https://registry.npmjs.org/tslib/-/tslib-2.8.1.tgz",
"integrity": "sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==",
"dev": true,
"license": "0BSD"
"license": "0BSD",
"peer": true
},
"node_modules/tsx": {
"version": "4.20.3",
@@ -16100,6 +16116,7 @@
"integrity": "sha512-qjbnuR9Tr+FJOMBqJCW5ehvIo/buZq7vH7qD7JziU98h6l3qGy0a/yPFjwO+y0/T7GFpNgNAvEcPPVfyT8rrPQ==",
"devOptional": true,
"license": "MIT",
"peer": true,
"dependencies": {
"esbuild": "~0.25.0",
"get-tsconfig": "^4.7.5"
@@ -16260,6 +16277,7 @@
"integrity": "sha512-p1diW6TqL9L07nNxvRMM7hMMw4c5XOo/1ibL4aAIGmSAt9slTE1Xgw5KWuof2uTOvCg9BY7ZRi+GaF+7sfgPeQ==",
"devOptional": true,
"license": "Apache-2.0",
"peer": true,
"bin": {
"tsc": "bin/tsc",
"tsserver": "bin/tsserver"
@@ -16467,6 +16485,7 @@
"resolved": "https://registry.npmjs.org/vite/-/vite-7.2.2.tgz",
"integrity": "sha512-BxAKBWmIbrDgrokdGZH1IgkIk/5mMHDreLDmCJ0qpyJaAteP8NvMhkwr/ZCQNqNH97bw/dANTE9PDzqwJghfMQ==",
"license": "MIT",
"peer": true,
"dependencies": {
"esbuild": "^0.25.0",
"fdir": "^6.5.0",
@@ -16580,6 +16599,7 @@
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.3.tgz",
"integrity": "sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==",
"license": "MIT",
"peer": true,
"engines": {
"node": ">=12"
},
@@ -16592,6 +16612,7 @@
"resolved": "https://registry.npmjs.org/vitest/-/vitest-3.2.4.tgz",
"integrity": "sha512-LUCP5ev3GURDysTWiP47wRRUpLKMOfPh+yKTx3kVIEiu5KOMeqzpnYNsKyOoVrULivR8tLcks4+lga33Whn90A==",
"license": "MIT",
"peer": true,
"dependencies": {
"@types/chai": "^5.2.2",
"@vitest/expect": "3.2.4",
@@ -17223,6 +17244,7 @@
"resolved": "https://registry.npmjs.org/zod/-/zod-3.25.76.tgz",
"integrity": "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ==",
"license": "MIT",
"peer": true,
"funding": {
"url": "https://github.com/sponsors/colinhacks"
}
@@ -17535,6 +17557,7 @@
"resolved": "https://registry.npmjs.org/picomatch/-/picomatch-4.0.3.tgz",
"integrity": "sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==",
"license": "MIT",
"peer": true,
"engines": {
"node": ">=12"
},
packages/core/src/core/__snapshots__/prompts.test.ts.snap
+215 -37
View File
@@ -128,7 +128,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > ApprovalMode in System Prompt > Approved Plan in Plan Mode > should include approved plan path when set in config 1`] = `
@@ -264,7 +264,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > ApprovalMode in System Prompt > should NOT include approval mode instructions for DEFAULT mode 1`] = `
@@ -308,7 +308,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -376,7 +376,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > ApprovalMode in System Prompt > should include PLAN mode instructions 1`] = `
@@ -507,7 +507,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should append userMemory with separator when provided 1`] = `
@@ -566,7 +566,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -595,6 +595,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -681,7 +695,7 @@ exports[`Core System Prompt (prompts.ts) > should handle CodebaseInvestigator wi
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use \`grep_search\` or \`glob\` directly in parallel. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use \`grep_search\` or \`glob\` directly in parallel. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -708,6 +722,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -777,7 +805,7 @@ exports[`Core System Prompt (prompts.ts) > should handle CodebaseInvestigator wi
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -804,6 +832,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -874,7 +916,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -942,7 +984,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should handle git instructions when isGitRepository=true 1`] = `
@@ -986,7 +1028,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -1072,7 +1114,7 @@ You are running outside of a sandbox container, directly on the user's system. F
- Never push changes to a remote repository without being asked explicitly by the user.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should include approved plan instructions when approvedPlanPath is set 1`] = `
@@ -1116,7 +1158,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
2. **Plan:** An approved plan is available for this task. Use this file as a guide for your implementation. You MUST read this file before proceeding. If you discover new requirements or need to change the approach, confirm with the user and update this plan file to reflect the updated design decisions or discovered requirements.
3. **Implement:** Use the available tools (e.g., 'replace', 'write_file' 'run_shell_command' ...) to act on the plan. Strictly adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -1174,7 +1216,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should include available_skills when provided in config 1`] = `
@@ -1231,7 +1273,7 @@ You have access to the following specialized skills. To activate a skill and rec
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -1299,7 +1341,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should include available_skills with updated verbiage for preview models 1`] = `
@@ -1371,7 +1413,7 @@ You have access to the following specialized skills. To activate a skill and rec
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -1400,6 +1442,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -1485,7 +1541,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -1514,6 +1570,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -1603,7 +1673,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -1632,6 +1702,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -1721,7 +1805,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -1750,6 +1834,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -1788,10 +1886,6 @@ exports[`Core System Prompt (prompts.ts) > should include planning phase suggest
- **Credential Protection:** Never log, print, or commit secrets, API keys, or sensitive credentials. Rigorously protect \`.env\` files, \`.git\`, and system configuration folders.
- **Source Control:** Do not stage or commit changes unless specifically requested by the user.
## Context Efficiency:
- Always scope and limit your searches to avoid context window exhaustion and ensure high-signal results. Use include to target relevant files and strictly limit results using total_max_matches and max_matches_per_file, especially during the research phase.
- For broad discovery, use names_only=true or max_matches_per_file=1 to identify files without retrieving their context.
## Engineering Standards
- **Contextual Precedence:** Instructions found in \`GEMINI.md\` files are foundational mandates. They take absolute precedence over the general workflows and tool defaults described in this system prompt.
- **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
@@ -1864,6 +1958,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -1949,7 +2057,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -1978,6 +2086,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -2048,7 +2170,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -2116,7 +2238,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should render hierarchical memory with XML tags 1`] = `
@@ -2161,7 +2283,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -2229,7 +2351,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved.
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved.
---
@@ -2302,7 +2424,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -2331,6 +2453,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -2416,7 +2552,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -2445,6 +2581,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -2516,7 +2666,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -2582,7 +2732,7 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
exports[`Core System Prompt (prompts.ts) > should use chatty system prompt for preview flash model 1`] = `
@@ -2641,7 +2791,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -2670,6 +2820,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -2755,7 +2919,7 @@ For example:
## Development Lifecycle
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
1. **Research:** Systematically map the codebase and validate assumptions. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`grep_search\` with context or \`read_file\` with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
3. **Execution:** For each sub-task:
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
@@ -2784,6 +2948,20 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
# Operational Guidelines
## Shell tool output token efficiency:
IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
- Always prefer command flags that reduce output verbosity when using \`run_shell_command\`.
- Aim to minimize tool output tokens while still capturing necessary information.
- If a command is expected to produce a lot of output, use quiet or silent flags where available and appropriate.
- Always consider the trade-off between output verbosity and the need for information. If a command's full output is essential for understanding the result, avoid overly aggressive quieting that might obscure important details.
- If a command does not have quiet/silent flags or for commands with potentially long output that may not be useful, redirect stdout and stderr to temp files in the project's temporary directory. For example: 'command > <temp_dir>/out.log 2> <temp_dir>/err.log'.
- After the command runs, inspect the temp files (e.g. '<temp_dir>/out.log' and '<temp_dir>/err.log') using commands like 'grep', 'tail', 'head'. Remove the temp files when done.
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
## Tone and Style
- **Role:** A senior software engineer and collaborative peer programmer.
@@ -2854,7 +3032,7 @@ For example:
## 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 'grep_search' and 'glob' search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.
Use 'read_file' to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to 'read_file'.
Use 'grep_search' with context or 'read_file' with precise ranges to understand context and validate any assumptions you may have. If you need to read multiple files, you should make multiple parallel calls to these tools.
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. If the user's request implies a change but does not explicitly state it, **YOU MUST ASK** for confirmation before modifying code. 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 adhere to the project's established conventions (detailed under 'Core Mandates'). Before making manual code changes, check if an ecosystem tool (like 'eslint --fix', 'prettier --write', 'go fmt', 'cargo fmt') is available in the project to perform the task automatically.
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. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
@@ -2922,5 +3100,5 @@ IT IS CRITICAL TO FOLLOW THESE GUIDELINES TO AVOID EXCESSIVE TOKEN CONSUMPTION.
You are running outside of a sandbox container, directly on the user's system. For critical commands that are particularly likely to modify the user's system outside of the project directory or system temp directory, as you explain the command to the user (per the Explain Critical Commands rule above), also remind the user to consider enabling sandboxing.
# Final Reminder
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use 'read_file' to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
Your core function is efficient and safe assistance. Balance extreme conciseness with the crucial need for clarity, especially regarding safety and potential system modifications. Always prioritize user control and project conventions. Never make assumptions about the contents of files; instead use appropriate search and extraction tools to ensure you aren't making broad assumptions. Finally, you are an agent - please keep going until the user's query is completely resolved."
`;
packages/core/src/prompts/promptProvider.ts
-1
View File
@@ -205,7 +205,6 @@ export class PromptProvider {
})),
} as snippets.SystemPromptOptions;
const getCoreSystemPrompt = activeSnippets.getCoreSystemPrompt as (
options: snippets.SystemPromptOptions,
) => string;
packages/core/src/prompts/snippets.ts
+40 -14
View File
@@ -99,7 +99,7 @@ export function getCoreSystemPrompt(options: SystemPromptOptions): string {
return `
${renderPreamble(options.preamble)}
${renderCoreMandates(options.coreMandates)}
${renderCoreMandates(options.coreMandates, options.primaryWorkflows)}
${renderSubAgents(options.subAgents)}
@@ -113,7 +113,10 @@ ${
: renderPrimaryWorkflows(options.primaryWorkflows)
}
${renderOperationalGuidelines(options.operationalGuidelines)}
${renderOperationalGuidelines(
options.operationalGuidelines,
options.primaryWorkflows,
)}
${renderInteractiveYoloMode(options.interactiveYoloMode)}
@@ -147,7 +150,10 @@ export function renderPreamble(options?: PreambleOptions): string {
: 'You are Gemini CLI, an autonomous CLI agent specializing in software engineering tasks. Your primary goal is to help users safely and effectively.';
}
export function renderCoreMandates(options?: CoreMandatesOptions): string {
function renderCoreMandates(
options?: CoreMandatesOptions,
primaryWorkflowsOptions?: PrimaryWorkflowsOptions,
): string {
if (!options) return '';
const filenames = options.contextFilenames ?? [DEFAULT_CONTEXT_FILENAME];
const formattedFilenames =
@@ -158,17 +164,22 @@ export function renderCoreMandates(options?: CoreMandatesOptions): string {
.join(', ') + ` or \`${filenames[filenames.length - 1]}\``
: `\`${filenames[0]}\``;
let contextEfficiency = '';
if (primaryWorkflowsOptions?.enableGrep) {
contextEfficiency = `
## Context Efficiency:
- Always scope and limit your searches to avoid context window exhaustion and ensure high-signal results. Use include to target relevant files and strictly limit results using total_max_matches and max_matches_per_file, especially during the research phase.
- For broad discovery, use names_only=true or max_matches_per_file=1 to identify files without retrieving their context.
`;
}
return `
# Core Mandates
## Security & System Integrity
- **Credential Protection:** Never log, print, or commit secrets, API keys, or sensitive credentials. Rigorously protect \`.env\` files, \`.git\`, and system configuration folders.
- **Source Control:** Do not stage or commit changes unless specifically requested by the user.
## Context Efficiency:
- Always scope and limit your searches to avoid context window exhaustion and ensure high-signal results. Use include to target relevant files and strictly limit results using total_max_matches and max_matches_per_file, especially during the research phase.
- For broad discovery, use names_only=true or max_matches_per_file=1 to identify files without retrieving their context.
${contextEfficiency}
## Engineering Standards
- **Contextual Precedence:** Instructions found in ${formattedFilenames} files are foundational mandates. They take absolute precedence over the general workflows and tool defaults described in this system prompt.
- **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
@@ -271,17 +282,23 @@ ${newApplicationSteps(options)}
`.trim();
}
export function renderOperationalGuidelines(
function renderOperationalGuidelines(
options?: OperationalGuidelinesOptions,
primaryWorkflowsOptions?: PrimaryWorkflowsOptions,
): string {
if (!options) return '';
const grepContext = primaryWorkflowsOptions?.enableGrep
? `\`${GREP_TOOL_NAME}\` with context or `
: '';
return `
# Operational Guidelines
${shellEfficiencyGuidelines(options.enableShellEfficiency)}
## Token Efficiency
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like \`grep_search\` with context or \`sed\`) over broad file reads.
- **Be Token-Frugal:** Every line of code or long tool output you pull into the conversation history increases the complexity and cost of the entire session. **Context persists.** Prefer surgical extraction tools (like ${grepContext}\`sed\`) over broad file reads.
## Tone and Style
@@ -534,11 +551,16 @@ function mandateContinueWork(interactive: boolean): string {
function workflowStepResearch(options: PrimaryWorkflowsOptions): string {
let suggestion = '';
if (options.enableEnterPlanModeTool) {
suggestion = ` For complex tasks, consider using the ${formatToolName(ENTER_PLAN_MODE_TOOL_NAME)} tool to enter a dedicated planning phase before starting implementation.`;
suggestion = ` For complex tasks, consider using the ${formatToolName(
ENTER_PLAN_MODE_TOOL_NAME,
)} tool to enter a dedicated planning phase before starting implementation.`;
}
const grepName = formatToolName(GREP_TOOL_NAME);
const readFileName = formatToolName(READ_FILE_TOOL_NAME);
const searchTools: string[] = [];
if (options.enableGrep) searchTools.push(formatToolName(GREP_TOOL_NAME));
if (options.enableGrep) searchTools.push(grepName);
if (options.enableGlob) searchTools.push(formatToolName(GLOB_TOOL_NAME));
let searchSentence =
@@ -549,6 +571,10 @@ function workflowStepResearch(options: PrimaryWorkflowsOptions): string {
searchSentence = ` Use ${toolsStr} search ${toolOrTools} extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions.`;
}
const validationClause = options.enableGrep
? ` Use ${grepName} with context or ${readFileName} with precise ranges to validate all assumptions.`
: ` Use ${readFileName} to validate all assumptions.`;
if (options.enableCodebaseInvestigator) {
let subAgentSearch = '';
if (searchTools.length > 0) {
@@ -556,10 +582,10 @@ function workflowStepResearch(options: PrimaryWorkflowsOptions): string {
subAgentSearch = ` For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use ${toolsStr} directly in parallel.`;
}
return `1. **Research:** Systematically map the codebase and validate assumptions. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**.${subAgentSearch} Use ${formatToolName(GREP_TOOL_NAME)} with context or ${formatToolName(READ_FILE_TOOL_NAME)} with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
return `1. **Research:** Systematically map the codebase and validate assumptions. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**.${subAgentSearch}${validationClause} **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
}
return `1. **Research:** Systematically map the codebase and validate assumptions.${searchSentence} Use ${formatToolName(GREP_TOOL_NAME)} with context or ${formatToolName(READ_FILE_TOOL_NAME)} with precise ranges to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
return `1. **Research:** Systematically map the codebase and validate assumptions.${searchSentence}${validationClause} **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
}
function workflowStepStrategy(options: PrimaryWorkflowsOptions): string {
packages/core/src/tools/__snapshots__/shell.test.ts.snap
+24 -20
View File
@@ -3,10 +3,6 @@
exports[`ShellTool > getDescription > should return the non-windows description when not on windows 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -14,16 +10,17 @@ exports[`ShellTool > getDescription > should return the non-windows description
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`)."
`;
exports[`ShellTool > getDescription > should return the windows description when on windows 1`] = `
"This tool executes a given shell command as \`powershell.exe -NoProfile -Command <command>\`. Command can start background processes using PowerShell constructs such as \`Start-Process -NoNewWindow\` or \`Start-Job\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -31,16 +28,17 @@ exports[`ShellTool > getDescription > should return the windows description when
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`)."
`;
exports[`ShellTool > getSchema > should return the base schema when no modelId is provided 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -48,16 +46,17 @@ exports[`ShellTool > getSchema > should return the base schema when no modelId i
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`)."
`;
exports[`ShellTool > getSchema > should return the schema from the resolver when modelId is provided 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -65,5 +64,10 @@ exports[`ShellTool > getSchema > should return the schema from the resolver when
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`)."
`;
packages/core/src/tools/definitions/__snapshots__/coreToolsModelSnapshots.test.ts.snap
+34 -16
View File
@@ -2,7 +2,7 @@
exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snapshot for tool: glob 1`] = `
{
"description": "Efficiently finds files matching specific glob patterns (e.g., \`src/**/*.ts\`, \`**/*.md\`), returning absolute paths sorted by modification time (newest first). Ideal for quickly locating files based on their name or path structure, especially in large codebases.",
"description": "Finds files matching glob patterns (e.g., \`src/**/*.ts\`). Results are sorted by modification time (newest first). Ideal for structural discovery and identifying recent changes. **Avoid using this tool just to list files before reading them;** if you know the symbols you need, use \`grep_search\` directly.",
"name": "glob",
"parametersJsonSchema": {
"properties": {
@@ -37,7 +37,7 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snapshot for tool: grep_search 1`] = `
{
"description": "Searches for a regular expression pattern within file contents. Max 100 matches.",
"description": "FAST regular expression search. This is the **primary discovery tool** for locating code. Use context parameters (\`context\`, \`after\`, \`before\`) to read code surrounding matches in a single turn, often eliminating the need for a separate \`read_file\` call. (max 100 matches).",
"name": "grep_search",
"parametersJsonSchema": {
"properties": {
@@ -122,10 +122,14 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snapshot for tool: read_file 1`] = `
{
"description": "Reads and returns the content of a specified file. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), audio files (MP3, WAV, AIFF, AAC, OGG, FLAC), and PDF files. For text files, it can read specific line ranges.",
"description": "Reads and returns the content of a specified file. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. For Gemini 3 models, use 'start_line' and 'end_line' for precise extraction. **Important:** For high token efficiency, avoid reading large files in their entirety. Use 'grep_search' to find symbols or 'run_shell_command' with 'sed' for surgical block extraction instead of broad file reads. Handles text, images, audio, and PDF files.",
"name": "read_file",
"parametersJsonSchema": {
"properties": {
"end_line": {
"description": "Optional: The 1-based line number to end reading at (inclusive). (Gemini 3+)",
"type": "number",
},
"file_path": {
"description": "The path to the file to read.",
"type": "string",
@@ -138,6 +142,10 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
"description": "Optional: For text files, the 0-based line number to start reading from. Requires 'limit' to be set. Use for paginating through large files.",
"type": "number",
},
"start_line": {
"description": "Optional: The 1-based line number to start reading from. (Gemini 3+)",
"type": "number",
},
},
"required": [
"file_path",
@@ -151,10 +159,6 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
{
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -162,7 +166,12 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available.",
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).",
"name": "run_shell_command",
"parametersJsonSchema": {
"properties": {
@@ -219,7 +228,7 @@ exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snaps
exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview > snapshot for tool: glob 1`] = `
{
"description": "Efficiently finds files matching specific glob patterns (e.g., \`src/**/*.ts\`, \`**/*.md\`), returning absolute paths sorted by modification time (newest first). Ideal for quickly locating files based on their name or path structure, especially in large codebases.",
"description": "Finds files matching glob patterns (e.g., \`src/**/*.ts\`). Results are sorted by modification time (newest first). Ideal for structural discovery and identifying recent changes. **Avoid using this tool just to list files before reading them;** if you know the symbols you need, use \`grep_search\` directly.",
"name": "glob",
"parametersJsonSchema": {
"properties": {
@@ -254,7 +263,7 @@ exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview >
exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview > snapshot for tool: grep_search 1`] = `
{
"description": "Searches for a regular expression pattern within file contents. Max 100 matches.",
"description": "FAST regular expression search. This is the **primary discovery tool** for locating code. Use context parameters (\`context\`, \`after\`, \`before\`) to read code surrounding matches in a single turn, often eliminating the need for a separate \`read_file\` call. (max 100 matches).",
"name": "grep_search",
"parametersJsonSchema": {
"properties": {
@@ -339,10 +348,14 @@ exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview >
exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview > snapshot for tool: read_file 1`] = `
{
"description": "Reads and returns the content of a specified file. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. Handles text, images (PNG, JPG, GIF, WEBP, SVG, BMP), audio files (MP3, WAV, AIFF, AAC, OGG, FLAC), and PDF files. For text files, it can read specific line ranges.",
"description": "Reads and returns the content of a specified file. If the file is large, the content will be truncated. The tool's response will clearly indicate if truncation has occurred and will provide details on how to read more of the file using the 'offset' and 'limit' parameters. For Gemini 3 models, use 'start_line' and 'end_line' for precise extraction. **Important:** For high token efficiency, avoid reading large files in their entirety. Use 'grep_search' to find symbols or 'run_shell_command' with 'sed' for surgical block extraction instead of broad file reads. Handles text, images, audio, and PDF files.",
"name": "read_file",
"parametersJsonSchema": {
"properties": {
"end_line": {
"description": "Optional: The 1-based line number to end reading at (inclusive). (Gemini 3+)",
"type": "number",
},
"file_path": {
"description": "The path to the file to read.",
"type": "string",
@@ -355,6 +368,10 @@ exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview >
"description": "Optional: For text files, the 0-based line number to start reading from. Requires 'limit' to be set. Use for paginating through large files.",
"type": "number",
},
"start_line": {
"description": "Optional: The 1-based line number to start reading from. (Gemini 3+)",
"type": "number",
},
},
"required": [
"file_path",
@@ -368,10 +385,6 @@ exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview >
{
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
@@ -379,7 +392,12 @@ exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview >
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available.",
Process Group PGID: Only included if available.
**This is the preferred tool for surgical extraction of code blocks.** Use \`sed -n '50,100p' file\` for ranges, or \`sed -n '/class X/,/^}/p' file\` for semantic blocks. Avoid 'cat' on large files to prevent context bloat. Output is limited to the last 2,000 lines.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).",
"name": "run_shell_command",
"parametersJsonSchema": {
"properties": {