prompts: split SYSTEM_PROMPT.md into ordered p/ parts

- 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 <noreply@anthropic.com>

core

@@ -1 +1 @@
-Subproject commit 0762a37d1c183cd223fb0378fbeeb05bca7179fc
+Subproject commit fe00c607a1c2a0719a5c226799d1b0437ca2a0e3

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

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

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: ["<title>", "<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

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

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/"}
+```

skills

@@ -1 +1 @@
-Subproject commit 360d2f25d5a7a7d968015bdb4573f166cfecf87b
+Subproject commit e7464dd0c9a5eb65b4823a96c7e345d14ecdda1a