chore: remove reasoning, memory, edit-text skills

All three are superseded by the ollie system prompt (prompts/03-07).
Keeping them risks contradicting system prompt rules.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Levi Neely 2026-04-14 23:10:25 +02:00
parent e7464dd0c9
commit fbc9eee02b
3 changed files with 0 additions and 116 deletions

View File

@ -1,36 +0,0 @@
---
name: edit-text
intent: read, write, edit, search, grep, glob, find, cat, sed, awk, file
description: Guidance on using file_* tools for all file read/write/edit/search operations instead of shell commands.
---
# 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/"}
```

View File

@ -1,42 +0,0 @@
---
name: memory
intent: remember, recall, memory, persist, forget
description: Guidance on using memory_remember and memory_recall to persist and retrieve information across sessions.
---
# 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

View File

@ -1,38 +0,0 @@
---
name: reasoning
intent: think, reasoning, scratchpad, planning, problem-solving
description: Guidance on using reasoning_think for internal scratchpad reasoning before acting.
---
# 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