Update system instructions for optimizing shell tool commands (#10651)

docs/get-started/configuration.md

@@ -256,6 +256,10 @@ their corresponding top-level category object in your `settings.json` file.
   - **Description:** Skip the next speaker check.
   - **Default:** `false`
 
+- **`model.enableShellOutputEfficiency`** (boolean):
+  - **Description:** Optimizes shell tool commands for token efficiency.
+  - **Default:** `true`
+
 #### `context`
 
 - **`context.fileName`** (string or array of strings):

packages/core/src/config/config.ts

@@ -278,6 +278,7 @@ export interface ConfigParameters {
   enableMessageBusIntegration?: boolean;
   codebaseInvestigatorSettings?: CodebaseInvestigatorSettings;
   continueOnFailedApiCall?: boolean;
+  enableShellOutputEfficiency?: boolean;
 }
 
 export class Config {
@@ -371,6 +372,7 @@ export class Config {
   private readonly enableMessageBusIntegration: boolean;
   private readonly codebaseInvestigatorSettings?: CodebaseInvestigatorSettings;
   private readonly continueOnFailedApiCall: boolean;
+  private readonly enableShellOutputEfficiency: boolean;
 
   constructor(params: ConfigParameters) {
     this.sessionId = params.sessionId;
@@ -465,6 +467,8 @@ export class Config {
       params.enableMessageBusIntegration ?? false;
     this.codebaseInvestigatorSettings = params.codebaseInvestigatorSettings;
     this.continueOnFailedApiCall = params.continueOnFailedApiCall ?? true;
+    this.enableShellOutputEfficiency =
+      params.enableShellOutputEfficiency ?? true;
     this.extensionManagement = params.extensionManagement ?? true;
     this.storage = new Storage(this.targetDir);
     this.enablePromptCompletion = params.enablePromptCompletion ?? false;
@@ -966,6 +970,10 @@ export class Config {
     return this.continueOnFailedApiCall;
   }
 
+  getEnableShellOutputEfficiency(): boolean {
+    return this.enableShellOutputEfficiency;
+  }
+
   getShellExecutionConfig(): ShellExecutionConfig {
     return this.shellExecutionConfig;
   }

packages/core/src/core/__snapshots__/prompts.test.ts.snap

@@ -50,6 +50,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -238,6 +250,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -436,6 +460,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -619,6 +655,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -802,6 +850,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -985,6 +1045,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -1168,6 +1240,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -1351,6 +1435,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.
@@ -1534,6 +1630,18 @@ When requested to perform tasks like fixing bugs, adding features, refactoring,
 
 # 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: /tmp/project-temp. For example: 'command > /tmp/project-temp/out.log 2> /tmp/project-temp/err.log'.
+- After the command runs, inspect the temp files (e.g. '/tmp/project-temp/out.log' and '/tmp/project-temp/err.log') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+
+
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.
 - **Minimal Output:** Aim for fewer than 3 lines of text output (excluding tool use/code generation) per response whenever practical. Focus strictly on the user's query.

packages/core/src/core/prompts.test.ts

@@ -47,6 +47,10 @@ describe('Core System Prompt (prompts.ts)', () => {
       getToolRegistry: vi.fn().mockReturnValue({
         getAllToolNames: vi.fn().mockReturnValue([]),
       }),
+      getEnableShellOutputEfficiency: vi.fn().mockReturnValue(true),
+      storage: {
+        getProjectTempDir: vi.fn().mockReturnValue('/tmp/project-temp'),
+      },
     } as unknown as Config;
   });
 
@@ -136,6 +140,10 @@ describe('Core System Prompt (prompts.ts)', () => {
             .fn()
             .mockReturnValue([CodebaseInvestigatorAgent.name]),
         }),
+        getEnableShellOutputEfficiency: vi.fn().mockReturnValue(true),
+        storage: {
+          getProjectTempDir: vi.fn().mockReturnValue('/tmp/project-temp'),
+        },
       } as unknown as Config;
     });
 

packages/core/src/core/prompts.ts

@@ -162,6 +162,33 @@ ${(function () {
 6. **Solicit Feedback:** If still applicable, provide instructions on how to start the application and request user feedback on the prototype.
 
 # Operational Guidelines
+${(function () {
+  if (config.getEnableShellOutputEfficiency()) {
+    const tempDir = config.storage.getProjectTempDir();
+    return `
+## 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 '${ShellTool.Name}'.
+- 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: ${tempDir}. For example: 'command > ${path.posix.join(
+      tempDir,
+      'out.log',
+    )} 2> ${path.posix.join(tempDir, 'err.log')}'.
+- After the command runs, inspect the temp files (e.g. '${path.posix.join(
+      tempDir,
+      'out.log',
+    )}' and '${path.posix.join(
+      tempDir,
+      'err.log',
+    )}') using commands like 'grep', 'tail', 'head', ... (or platform equivalents). Remove the temp files when done.
+`;
+  }
+  return '';
+})()}
 
 ## Tone and Style (CLI Interaction)
 - **Concise & Direct:** Adopt a professional, direct, and concise tone suitable for a CLI environment.

packages/core/src/core/subagent.test.ts

@@ -53,6 +53,7 @@ async function createMockConfig(
     targetDir: '.',
     debugMode: false,
     cwd: process.cwd(),
+    enableShellOutputEfficiency: false,
     ...configParameters,
   };
   const config = new Config(configParams);