Optimize GDB prompt in CrashAnalyzer

prompts/tool/gdb_tool.txt

@@ -1,42 +1,47 @@
 <tool>
 **GDB tool Guide**
-You can leverage GDB by iteractively sending me a GDB command, and I will provide you with the output of the command. The path of fuzz driver binary is '/out/{TARGET_NAME}'. The testcase that triggers runtime crash is stored at '{AFTIFACT_PATH}'.
+You can issue GDB commands one at a time and I’ll return each command’s output. The fuzz driver binary is located at '/out/{TARGET_NAME}'. The crash-triggering testcase is located at '{AFTIFACT_PATH}'.
 
 <interaction protocols>
-1. I have executed 'gdb /out/{TARGET_NAME}'. You are now in GDB session, NOT in shell session. DO NOT run 'gdb /out/{TARGET_NAME}' again! DO NOT run shell commands!
-2. Strictly ONE GDB command at a time!
-3. Each message you send should first explain the reason why you want to run the command wrapped by <reason></reason>, then provide the command to run wrapped in <gdb></gdb> in this format:
-<reason>
-Reasons here.
-</reason>
-<gdb>
-One gdb command here.
-</gdb>
-4. Each reponse I send will repeat the command you sent wrapped in <gdb command></gdb command> for you to double-check, followed by the command standard output wrapped in <gdb output></gdb output> and stderr wrapped in <stderr></stderr> in this format:
-<gdb command>
-The command I executed, copied from the command you sent.
-</gdb command>
-<gdb output>
-The standard output of the command.
-</gdb output>
-<stderr>
-The standard error of the command.
-</stderr>
-5. The final goal is to answer questions about runtime crash, executed fuzz driver and project under test: a) ‘False’(if the crash is caused by bug in fuzz driver) or ‘True'(if the crash is caused by bug in project)? b) If the crash is caused by bug in fuzz driver, provide analyses, and are there any suggestions for modifying the fuzz driver? c) If the crash is caused by bug in project, provide analyses, and are there any suggestions for patching the project?
-6. If you have a conclusion on above questions, output the conclusion wrapped by <conclusion></conclusion> followed by the analysis and suggestion wrapped in <analysis and suggestion></analysis and suggestion>:
-<conclusion>
-‘False’ or ‘True’
-</conclusion>
-<analysis and suggestion>
-Analysis and suggestion
-</analysis and suggestion>
+1. The binary is already loaded with 'gdb /out/{TARGET_NAME}'. You are **inside the GDB session**, not a shell.
+2. **One** GDB command per message.
+3. Each message you send must follow the format below:
+    <reason>
+    A short explanation of why you are issuing this GDB command.
+    </reason>
+    <gdb>
+    A single GDB command to execute.
+    </gdb>
+4. For every response I send, the format will be:
+    <gdb command>
+    The exact command you issued.
+    </gdb command>
+    <gdb output>
+    Standard output from the GDB command.
+    </gdb output>
+    <stderr>
+    Standard error (if any).
+    </stderr>
+5. The ultimate goal is to determine the root cause of the crash based on the fuzz driver and project under test:
+    a) Is the crash caused by a **bug in the project**? → Output **‘True’**
+    b) Or is it caused by a **bug in the fuzz driver**? → Output **‘False’**
+    c) In either case, provide a brief analysis and suggestions for fixing the issue.
+6. Once you reach a conclusion, reply using this format:
+   <conclusion>
+   True  (if crash is caused by the project)
+   or
+   False (if crash is caused by the fuzz driver)
+   </conclusion>
+   <analysis and suggestion>
+   • 1–2 lines summarizing the root cause.
+   • Practical suggestions to fix the fuzz driver or patch the project.
+   </analysis and suggestion>
 </interaction protocols>
 
 <general rules>
-1. DO NOT wrap code snippets with ```, using the XML-style tags above will suffice.
-2. DO NOT Compile or Run Code!
-3. Strictly ONE GDB command at a time!
-4. DO NOT run 'gdb /out/{TARGET_NAME}' again!
-5. DO NOT run shell commands!
+1. Do **NOT** run `gdb /out/{TARGET_NAME}` again or issue any shell commands.
+2. Do **NOT** compile or run code outside of GDB.
+3. Do **NOT** use `run < {AFTIFACT_PATH}` or `run -- {AFTIFACT_PATH}`. Instead, use `run -runs=1 {AFTIFACT_PATH}` to execute the crash input exactly once.
+4. No Markdown code fences (```), only the XML tags defined above.
 </general rules>
 </tool>