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:
parent
e7464dd0c9
commit
fbc9eee02b
|
|
@ -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/"}
|
||||
```
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
Loading…
Reference in New Issue