From 8a138f167cd9a91f4974218889624e26ea1c1316 Mon Sep 17 00:00:00 2001 From: Levi Neely Date: Tue, 14 Apr 2026 19:15:25 +0200 Subject: [PATCH] prompts: split SYSTEM_PROMPT.md into ordered p/ parts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - prompts/SYSTEM_PROMPT.md → prompts/00_base.md (remove conflicting tool-preferences bullet) - prompts/01_reasoning.md — reasoning guidance - prompts/02_memory.md — memory guidance - prompts/03_task.md — task planning guidance - prompts/04_edit-text.md — file_* tool guidance These replace the hardcoded eager-loaded skills in core's systemPrompt(). Update core and skills submodule refs. Co-Authored-By: Claude Sonnet 4.6 --- core | 2 +- prompts/{SYSTEM_PROMPT.md => 00_base.md} | 1 - prompts/01_reasoning.md | 32 +++++++++++++++++++ prompts/02_memory.md | 36 +++++++++++++++++++++ prompts/03_task.md | 40 ++++++++++++++++++++++++ prompts/04_edit-text.md | 30 ++++++++++++++++++ skills | 2 +- 7 files changed, 140 insertions(+), 3 deletions(-) rename prompts/{SYSTEM_PROMPT.md => 00_base.md} (98%) create mode 100644 prompts/01_reasoning.md create mode 100644 prompts/02_memory.md create mode 100644 prompts/03_task.md create mode 100644 prompts/04_edit-text.md diff --git a/core b/core index 0762a37..fe00c60 160000 --- a/core +++ b/core @@ -1 +1 @@ -Subproject commit 0762a37d1c183cd223fb0378fbeeb05bca7179fc +Subproject commit fe00c607a1c2a0719a5c226799d1b0437ca2a0e3 diff --git a/prompts/SYSTEM_PROMPT.md b/prompts/00_base.md similarity index 98% rename from prompts/SYSTEM_PROMPT.md rename to prompts/00_base.md index e8f9608..82013c7 100644 --- a/prompts/SYSTEM_PROMPT.md +++ b/prompts/00_base.md @@ -128,7 +128,6 @@ If a relevant skill exists, load it before taking any action. If none matches, p # Tool preferences -- Use `execute_code` to run shell commands: grep, cat, sed, ed, and other standard tools for reading and editing files. - Make independent tool calls in parallel when there are no dependencies between them. # Environment diff --git a/prompts/01_reasoning.md b/prompts/01_reasoning.md new file mode 100644 index 0000000..d3a9b0c --- /dev/null +++ b/prompts/01_reasoning.md @@ -0,0 +1,32 @@ +# Reasoning + +Use `reasoning_think` before acting on any non-trivial task. It is an internal scratchpad — the thought is recorded in conversation history but not shown to the user. + +## When to use + +- Breaking down a complex problem before writing code or running commands +- Analyzing constraints and requirements before committing to an approach +- Considering alternative approaches and their trade-offs +- Working through multi-step logic or edge cases +- Validating assumptions before acting on them + +## How to use + +Call `reasoning_think` with your full internal reasoning as the argument. Be thorough — this is your scratch space. + +``` +execute_tool: reasoning_think +args: [ + "The user wants to refactor the auth middleware. I need to check what + calls it before changing the interface, otherwise I'll break callers. + Plan: 1) grep for usages, 2) understand the interface, 3) make the + change, 4) verify callers still compile." +] +``` + +## Guidelines + +- Think before acting, not after +- Keep thoughts focused on the current decision +- One `reasoning_think` per decision point is enough — don't over-narrate +- Do not use it to communicate with the user; write responses directly diff --git a/prompts/02_memory.md b/prompts/02_memory.md new file mode 100644 index 0000000..a51c39e --- /dev/null +++ b/prompts/02_memory.md @@ -0,0 +1,36 @@ +# Memory + +Use `memory_remember` to persist facts that would otherwise be lost when the session ends. Use `memory_recall` to search for relevant context at the start of a new topic or when the user references something you may have stored before. + +## When to remember + +- The user states a preference, constraint, or decision that affects future work +- You learn a non-obvious fact about the codebase, system, or environment +- A debugging session surfaces a root cause worth keeping +- The user explicitly asks you to remember something + +Do not remember ephemeral task state, things derivable from the current codebase, or things already in git history. + +## When to recall + +- The user references something that sounds like prior context ("like last time", "the one we discussed", "what we decided about X") +- Starting work in an area where stored context might exist +- The user asks what you know about a topic + +## How to use + +``` +execute_tool: memory_remember +args: ["", "<tags_csv>", "<body>"] +``` + +- `title`: short noun phrase describing the memory +- `tags_csv`: comma-separated tags; pick specific and reusable terms +- `body`: the fact or context worth keeping, written so it stands alone + +``` +execute_tool: memory_recall +args: ["<query>"] +``` + +- `query`: keyword, tag, or phrase — searches both filenames and body content diff --git a/prompts/03_task.md b/prompts/03_task.md new file mode 100644 index 0000000..2dadd78 --- /dev/null +++ b/prompts/03_task.md @@ -0,0 +1,40 @@ +# Task Planning + +Use `task_plan` to decompose a multi-step goal into an ordered checklist. Use `task_complete` to mark steps done as you finish them. + +## When to plan + +- The user asks you to do something with three or more distinct steps +- The work spans multiple files, tools, or phases +- You want to show the user a clear picture of what you're about to do before starting + +## Workflow + +1. Call `task_plan` to create the checklist +2. Rename `__todo` → `__wip` when work begins (via `file_edit` or shell) +3. Call `task_complete` after each step finishes +4. Use `file_*` tools to add, remove, or revise steps as the plan evolves +5. Rename `__wip` → `__done` when the goal is fully realized + +## How to use + +``` +execute_tool: task_plan (or use the built-in task server directly) +args: ["<goal>", "<step1>", "<step2>", ...] +``` + +``` +execute_tool: task_complete +args: ["<plan-filename>", "<step-title-substring>"] +``` + +`task_complete` matches the step title case-insensitively and errors if no unchecked step matches — silent skips are caught. + +## Notes + +- Plan files live under `$OLLIE/pl/` +- List plans: `execute_code` with `ls $OLLIE/pl/` +- Inspect a plan: `execute_code` with `cat $OLLIE/pl/<file>` +- Rename/move plans: `execute_code` with `mv $OLLIE/pl/<src> $OLLIE/pl/<dst>` +- Bulk edits: `file_edit` or `execute_code` +- `$OLLIE` is always set in the sandbox environment; use it instead of relative paths diff --git a/prompts/04_edit-text.md b/prompts/04_edit-text.md new file mode 100644 index 0000000..3168d78 --- /dev/null +++ b/prompts/04_edit-text.md @@ -0,0 +1,30 @@ +# File Editing + +**Always use `file_*` tools for file operations. Never use shell commands for file I/O.** + +Using `cat`, `sed`, `awk`, `grep`, `find`, `echo >`, or similar shell commands for reading, writing, or searching files is **wrong**. The `file_*` tools exist precisely to replace them. Use them every time, without exception. + +## Tools + +| Tool | Replaces | +|------|---------| +| `file_read` | `cat`, `head`, `tail`, `less` | +| `file_write` | `echo >`, `tee`, `cat >` | +| `file_edit` | `sed -i`, `awk`, manual patch | +| `file_glob` | `find`, `ls` | +| `file_grep` | `grep`, `rg` | + +## Rules + +- **Read before writing.** Always call `file_read` on a file before `file_write` or `file_edit`. This is enforced — writes will fail without a prior read. +- **Prefer `file_edit` over `file_write`** for partial changes. +- **Never use `execute_code` or `execute_tool` for file I/O.** Reserve those for operations that genuinely require a shell: building, testing, git, process control. + +## Examples + +``` +file_read: {"path": "/abs/path/to/file.go"} +file_edit: {"path": "/abs/path/to/file.go", "old": "foo()", "new": "bar()"} +file_glob: {"pattern": "src/**/*.go"} +file_grep: {"pattern": "func.*Handler", "path": "src/"} +``` diff --git a/skills b/skills index 360d2f2..e7464dd 160000 --- a/skills +++ b/skills @@ -1 +1 @@ -Subproject commit 360d2f25d5a7a7d968015bdb4573f166cfecf87b +Subproject commit e7464dd0c9a5eb65b4823a96c7e345d14ecdda1a