From f983cdad1effa322765a97ece3492a1d2f826c58 Mon Sep 17 00:00:00 2001
From: Mike <mike@piebald.ai>
Date: Sun, 11 Jan 2026 10:19:19 -0700
Subject: [PATCH] Fix

---
 system-prompts/tool-description-bash.md |  4 ++--
 system-prompts/tool-description-task.md | 14 +++++++-------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/system-prompts/tool-description-bash.md b/system-prompts/tool-description-bash.md
index 417b7f8..3c83e3f 100644
--- a/system-prompts/tool-description-bash.md
+++ b/system-prompts/tool-description-bash.md
@@ -51,8 +51,8 @@ Usage notes:
     - Write files: Use ${WRITE_TOOL_NAME} (NOT echo >/cat <<EOF)
     - Communication: Output text directly (NOT echo/printf)
   - When issuing multiple commands:
-    - If the commands are independent and can run in parallel, make multiple ${GIT_COMMIT_AND_PR_CREATION_INSTRUCTION} tool calls in a single message. For example, if you need to run "git status" and "git diff", send a single message with two ${GIT_COMMIT_AND_PR_CREATION_INSTRUCTION} tool calls in parallel.
-    - If the commands depend on each other and must run sequentially, use a single ${GIT_COMMIT_AND_PR_CREATION_INSTRUCTION} call with '&&' to chain them together (e.g., \`git add . && git commit -m "message" && git push\`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.
+    - If the commands are independent and can run in parallel, make multiple ${BASH_TOOL_NAME} tool calls in a single message. For example, if you need to run "git status" and "git diff", send a single message with two ${BASH_TOOL_NAME} tool calls in parallel.
+    - If the commands depend on each other and must run sequentially, use a single ${BASH_TOOL_NAME} call with '&&' to chain them together (e.g., \`git add . && git commit -m "message" && git push\`). For instance, if one operation must complete before another starts (like mkdir before cp, Write before Bash for git operations, or git add before git commit), run these operations sequentially instead.
     - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail
     - DO NOT use newlines to separate commands (newlines are ok in quoted strings)
   - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of \`cd\`. You may use \`cd\` if the User explicitly requests it.
diff --git a/system-prompts/tool-description-task.md b/system-prompts/tool-description-task.md
index 0cc0f30..58867aa 100644
--- a/system-prompts/tool-description-task.md
+++ b/system-prompts/tool-description-task.md
@@ -33,8 +33,8 @@ When NOT to use the ${TASK_TOOL} tool:
 Usage notes:
 - Always include a short description (3-5 words) summarizing what the agent will do${GET_SUBSCRIPTION_TYPE_FN()!=="pro"?`
 - Launch multiple agents concurrently whenever possible, to maximize performance; to do that, use a single message with multiple tool uses`:""}
-- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.${!BASH_TOOL(TASK_TOOL_OBJECT.env.CLAUDE_CODE_DISABLE_BACKGROUND_TASKS)?`
-- You can optionally run agents in the background using the run_in_background parameter. When an agent runs in the background, the tool result will include an output_file path. To check on the agent's progress or retrieve its results, use the ${READ_TOOL} tool to read the output file, or use ${WRITE_TOOL} with \`tail\` to see recent output. You can continue working while background agents run.`:""}
+- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.${!IS_TRUTHY_FN(PROCESS_OBJECT.env.CLAUDE_CODE_DISABLE_BACKGROUND_TASKS)?`
+- You can optionally run agents in the background using the run_in_background parameter. When an agent runs in the background, the tool result will include an output_file path. To check on the agent's progress or retrieve its results, use the ${READ_TOOL} tool to read the output file, or use ${BASH_TOOL} with \`tail\` to see recent output. You can continue working while background agents run.`:""}
 - Agents can be resumed using the \`resume\` parameter by passing the agent ID from a previous invocation. When resumed, the agent continues with its full previous context preserved. When NOT resuming, each invocation starts fresh and you should provide a detailed task description with all necessary context.
 - When the agent is done, it will return a single message back to you along with its agent ID. You can use this ID to resume the agent later if needed for follow-up work.
 - Provide clear, detailed prompts so the agent can work autonomously and return exactly the information you need.
@@ -42,7 +42,7 @@ Usage notes:
 - The agent's outputs should generally be trusted
 - Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent
 - If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.
-- If the user specifies that they want you to run agents "in parallel", you MUST send a single message with multiple ${IS_TRUTHY_FN.name} tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.
+- If the user specifies that they want you to run agents "in parallel", you MUST send a single message with multiple ${TASK_TOOL_OBJECT.name} tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.
 
 Example usage:
 
@@ -54,8 +54,8 @@ Example usage:
 <example>
 user: "Please write a function that checks if a number is prime"
 assistant: Sure let me write a function that checks if a number is prime
-assistant: First let me use the ${PROCESS_OBJECT} tool to write a function that checks if a number is prime
-assistant: I'm going to use the ${PROCESS_OBJECT} tool to write the following code:
+assistant: First let me use the ${WRITE_TOOL} tool to write a function that checks if a number is prime
+assistant: I'm going to use the ${WRITE_TOOL} tool to write the following code:
 <code>
 function isPrime(n) {
   if (n <= 1) return false
@@ -69,7 +69,7 @@ function isPrime(n) {
 Since a significant piece of code was written and the task was completed, now use the test-runner agent to run the tests
 </commentary>
 assistant: Now let me use the test-runner agent to run the tests
-assistant: Uses the ${IS_TRUTHY_FN.name} tool to launch the test-runner agent
+assistant: Uses the ${TASK_TOOL_OBJECT.name} tool to launch the test-runner agent
 </example>
 
 <example>
@@ -77,5 +77,5 @@ user: "Hello"
 <commentary>
 Since the user is greeting, use the greeting-responder agent to respond with a friendly joke
 </commentary>
-assistant: "I'm going to use the ${IS_TRUTHY_FN.name} tool to launch the greeting-responder agent"
+assistant: "I'm going to use the ${TASK_TOOL_OBJECT.name} tool to launch the greeting-responder agent"
 </example>