Fix posting invalid response to a comment (#26266)

tools/gemini-cli-bot/brain/common.md

@@ -93,15 +93,15 @@ advanced triage, or semantic labeling).
 If the `ENABLE_PRS` environment variable is `true` and you are proposing script
 or configuration changes:
 
-1.  **Generate `pr-description.md`**: Create this file in the root directory.
-    Include:
+1.  **Generate `pr-description.md`**: Use the `write_file` tool to create this
+    file in the root directory. Include:
     - What the change is.
     - Why it is recommended.
     - Expected impact on metrics or productivity.
 2.  **Surgical Changes**: Only propose a **single improvement or fix per PR**.
     Prioritize highest impact, lowest risk.
-3.  **Acknowledgment**: If invoked by a comment, write a brief acknowledgement
-    to `issue-comment.md`.
+3.  **Acknowledgment**: If invoked by a comment, use the `write_file` tool to
+    save a brief acknowledgement to `issue-comment.md`.
 4.  **Stage Files**: Use `git add <file>` to stage files for the PR. **DO NOT**
     stage internal bot files like `pr-description.md`, `lessons-learned.md`,
     branch-name.txt, pr-comment.md, pr-number.txt, issue-comment.md, or anything
@@ -112,10 +112,10 @@ or configuration changes:
 If you are continuing work on an existing Task (e.g., status is `SUBMITTED`,
 `FAILED`, or `STUCK`):
 
-1.  **Update Existing PR**: Generate `branch-name.txt` with the branch name
-    (format: `bot/task-{ID}`).
-2.  **Respond to Maintainers**: Generate `pr-comment.md` (content) and
-    `pr-number.txt` (ID).
+1.  **Update Existing PR**: Use `write_file` to generate `branch-name.txt` with
+    the branch name (format: `bot/task-{ID}`).
+2.  **Respond to Maintainers**: Use `write_file` to generate `pr-comment.md`
+    (content) and `pr-number.txt` (ID).
 3.  **Handle CI Failures**: Diagnose failing checks using `gh run view` and
     priority must be generating a new patch to fix the failure.
 

tools/gemini-cli-bot/brain/interactive.md

@@ -30,7 +30,8 @@ Before beginning your analysis, you MUST perform the following research:
     Your ONLY goal is to address the user's specific comment.
 3.  **Verify Request Context**: Use the GitHub CLI to verify the current state
     of the issue/PR you were mentioned in. If the user's request is already
-    addressed or obsolete, inform them via `issue-comment.md`.
+    addressed or obsolete, inform them by using the `write_file` tool to save a
+    message to `issue-comment.md`.
 
 ### 1. Root-Cause Analysis & Hypothesis Testing
 
@@ -54,9 +55,9 @@ If your investigation confirms that a code or configuration change is required:
   user's specific request. You are STRICTLY FORBIDDEN from including any
   unrelated updates (such as metrics updates, backlog triage changes, or
   background housekeeping) when operating in interactive mode.
-- **Acknowledgment**: Write a brief acknowledgement to `issue-comment.md` (e.g.,
-  "I've investigated the request and implemented a fix. A PR will be created
-  shortly.").
+- **Acknowledgment**: Use the `write_file` tool to write a brief acknowledgement
+  to `issue-comment.md` (e.g., "I've investigated the request and implemented a
+  fix. A PR will be created shortly.").
 - **Follow Protocol**: Use the Memory Preservation and PR Preparation protocols
   provided in the common rules.
 
@@ -66,4 +67,7 @@ If the user's request is purely informational:
 
 - **Evidence-Based Answers**: Use your research tools to verify facts before
   answering.
-- **Output**: Write your response to `issue-comment.md`.
+- **Output**: You MUST use the `write_file` tool to save your response to
+  `issue-comment.md`. DO NOT simply output your response to the console. The
+  workflow relies on `issue-comment.md` being created in the workspace to post
+  the comment.