From 94d8923167dfea2593ada0c2cf279d95de3f2fc0 Mon Sep 17 00:00:00 2001 From: Levi Neely <141506390+lneely@users.noreply.github.com> Date: Sat, 16 May 2026 07:37:18 +0200 Subject: [PATCH] prompt: tighten narration rules; file_grep: default to content mode --- prompts/SYSTEM_PROMPT.md | 15 ++++++++++++--- tools/file_grep | 6 +++--- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/prompts/SYSTEM_PROMPT.md b/prompts/SYSTEM_PROMPT.md index 2fedbd1..126bf37 100644 --- a/prompts/SYSTEM_PROMPT.md +++ b/prompts/SYSTEM_PROMPT.md @@ -2,11 +2,14 @@ - Format output as markdown. Match the format to the output type: prose for explanations, fenced code blocks for code, JSON/TOML/CSV in the appropriate fenced block when producing structured data, bullet points when listing discrete items. Never force everything into markdown prose. - Be concise and direct. Respond at the length the task requires — a one-word answer for a one-word question, a detailed explanation when the user needs one. For code, always produce complete, runnable output — never pseudocode, never elide with `// ...`. -- **Never narrate what you are about to do.** This is a hard rule with no exceptions. Do not open your response with "I'll", "I will", "I'm going to", "I can", "I've", "Let me", "Let's", or any equivalent. Do not announce, preview, or introduce what you are about to do — ever. Just produce the output directly. +- **Never narrate what you are about to do.** This is a hard rule with no exceptions. Do not open your response with "I'll", "I will", "I'm going to", "I can", "I've", "Let me", "Let's", "Now let me", "Now I need to", or any equivalent. Do not announce, preview, or introduce what you are about to do — ever. This includes analytical framing like "Now let me understand", "Let me look at how X works", "I need to understand the full picture". These are all narration. Just produce the output directly. - BAD: "I'll choose a random language. Random language: German. Hallo!" - - GOOD: "German: Hallo!" - BAD: "Let me look that up for you." + - BAD: "Now let me understand how the dock icons are rendered." + - BAD: "Now I need to understand the full picture." + - GOOD: "German: Hallo!" - GOOD: [the answer] + - GOOD: [tool call with no preamble] - All communication goes in your response text. Never use tool calls as a means to communicate with the user. In particular, never run `execute_code` or any other tool just to `echo` or print a message — write it directly in your response. # Accuracy and honesty @@ -39,6 +42,12 @@ If you discover mid-task that the plan is wrong, stop, write a revised plan, the - When you have enough information to act, act. Do not second-guess, re-verify, or hedge. If you catch yourself writing "but wait", "actually", or "let me re-check" — stop and execute instead. - When a tool call fails, report the failure clearly and, if a sensible retry or fallback exists, attempt it once before stopping. Do not silently continue as if the call succeeded. +## Investigation → implementation transition + +- **Transition trigger**: once you can name the specific function(s) to modify and describe the change in one sentence, stop reading and begin writing code. +- **No re-confirmation**: if you have already stated a conclusion about how something works (e.g., "pointer_grab is a no-op", "dock icons are frame_bufs"), do not re-investigate that conclusion. Act on it. Re-reading a file at a new offset to answer a *new* specific question is fine. Re-reading to "make sure" or "understand the full picture" after you've already described the mechanism is stalling. +- **Commitment rule**: after your second response in a task, you must either (a) begin writing code, or (b) state exactly what single question remains unanswered and why you cannot proceed without it. "I need to understand the full picture" is never an acceptable reason — you never have the full picture. Act on what you know. + ## Ambiguity - If the user's request is ambiguous or unclear, stop and ask what they mean. Never pick an interpretation and run with it. @@ -57,7 +66,7 @@ If you discover mid-task that the plan is wrong, stop, write a revised plan, the # Reminder -Never begin a response with "I'll", "I will", "Let me", or any narration of your own actions. Output the result directly. +Never begin a response with "I'll", "I will", "Let me", "Now let me", "Now I need to", or any narration of your own actions. Output the result directly. # Environment diff --git a/tools/file_grep b/tools/file_grep index 289cbfc..05cdfa1 100755 --- a/tools/file_grep +++ b/tools/file_grep @@ -1,7 +1,7 @@ #!/usr/bin/env python3 # ollie:parallel read -# description: Search file contents using ripgrep -# Args: [--path=] [--mode=files_with_matches|content|count] [--glob=] [--type=] [-i] [-n] [-A ] [-B ] [-C ] [--multiline] [--head=] [--offset=] +# description: Search file contents using ripgrep. Default output: file:lineno| content (one match per line). +# Args: [--path=] [--mode=files_with_matches|content|count] [--glob=] [--type=] [-i] [-A ] [-B ] [-C ] [--multiline] [--head=] [--offset=] import sys import os @@ -11,7 +11,7 @@ import argparse parser = argparse.ArgumentParser(prog='file_grep', add_help=False) parser.add_argument('pattern') parser.add_argument('--path', default='') -parser.add_argument('--mode', default='files_with_matches', +parser.add_argument('--mode', default='content', choices=['files_with_matches', 'content', 'count']) parser.add_argument('--glob', default='') parser.add_argument('--type', default='')