---
{
  "name": "memory_ops",
  "description": "Use on-device long-term memory tools to remember, recall, list, update, and forget structured memories.",
  "metadata": {
    "cap_groups": [
      "claw_memory"
    ],
    "manage_mode": "readonly"
  }
}
---

# Long-term Memory

Use on-device long-term memory tools to remember, recall, list, update, and forget structured memories.

## When to use
Use this skill when the user explicitly asks to remember, save, keep, or not forget something, asks what is remembered, asks to update or delete a remembered item, or asks for an answer that should be based on prior long-term memory.

## Hard Rules
1. If the user clearly asks to remember, save, keep, or not forget something, call `memory_store`.
2. Write `memory_store.content` as a concise normalized memory fact, not the user's raw quote.
3. Do not write raw user quotes into memory content.
4. Do not exceed the maximum number of retrieval terms.
5. Keep retrieval terms in the same language as the memory fact unless the memory itself is primarily in another language.
6. If the user asks what you remember, asks to verify a remembered fact, or asks for a personalized answer based on prior memory, inspect the injected summary labels first and call `memory_recall` when relevant labels are present.
7. Do not place natural-language questions into `summary_labels`.
8. `memory_recall` requires exact `summary_labels` chosen from the injected catalog.
9. Use `query` only to narrow the search within the selected summary labels.
10. Use `memory_list` when the user wants to inspect stored memories.
11. Use `memory_update` only when one existing memory should be modified.
12. Use `memory_forget` only when one existing memory should be removed.
13. Use `memory_recall` plus exact `memory_id` only when you are already doing an explicit memory-inspection or memory-editing flow and need to inspect the recalled memory bodies yourself.
14. Do not use non-whitelisted or free-text values as summary labels.
15. Do not read or write `memory_records.jsonl`, `memory_index.json`, `memory_digest.log`, or `MEMORY.md` to make decisions directly.
16. Summary labels are not the memory body. Use `memory_recall` to obtain detailed stored content.
17. Do not call `memory_store` for ordinary self-introductions or casual preference statements unless the user explicitly asks to save them. Let automatic extraction handle durable facts after the reply silently.
18. Do not make the whole reply an operation log such as “I have remembered” or “deleted” unless the user explicitly asked only for a memory operation.
19. Do not explain internal memory policy, auto-extraction behavior, or whether you will proactively remember something unless the user explicitly asks about memory behavior.
20. Do not ask whether the user wants you to remember ordinary profile or preference statements when automatic extraction can handle them. Do not offer memory-save help unless the user explicitly asks about memory management.
21. Do not answer long-term memory recall questions from session history alone when long-term memory may contain additional relevant items.
22. Do not claim that a memory was updated or forgotten unless the corresponding tool call succeeded.

## Soft Rules
1. Prefer stable summary labels that group a reusable topic.
2. Good labels include `schedule`, `dietary_preferences`, `daily_routine`, `hydration_habits`, `commute`.
3. When a stable category label clearly fits the memory, prefer it over one-off fact-instance words.
4. Avoid using one-off detail words as the only summary label when a broader reusable category exists.
5. Avoid using one-off detail words as summary labels when a stable topic label already fits.
6. For example, prefer `daily_routine` over `nap`, and `hydration_habits` over `8_glasses_of_water`.
7. Avoid replacing a clearly supported stable topic label with a broader or vaguer abstraction.
8. Avoid labels such as `development`, `coding`, `healthy_lifestyle`, or `daily_arrangement` when a more precise stable label already fits better.
9. If you use memory tools during a conversation, prefer keeping the main reply focused on the user's request first.
10. If the user combines a memory request with another conversational request, prefer answering the conversational request in the main reply and keeping the memory operation secondary.

## Typical flow
- Explicit save request: call `memory_store`, then continue the main conversation naturally.
- Recall or verification request: inspect summary labels, call `memory_recall` if relevant labels exist, then answer from recalled content.
- Update or delete request: use `memory_recall` or `memory_list` to inspect the target memory and obtain its exact `memory_id`, then call `memory_update` or `memory_forget`.

## Examples
- A good summary label is `daily_routine`.
- A good summary label is `hydration_habits`.
- Save a profile fact explicitly: if the user says “Remember my profession is a programmer”, store `content="The user's profession is a programmer"` and use the summary label `profession`.
- Save a preference explicitly: if the user says “Remember I like lettuce”, store `content="The user likes lettuce"` and use the summary label `dietary_preferences`.
- Save a routine fact explicitly: if the user says “Remember I wake up at 7 and drink milk before going to work”, use summary labels such as `daily_routine`, `dietary_preferences`, and `commute`.
- Save a midday habit explicitly: if the user says “Remember I must take a nap at noon”, a suitable summary label is `daily_routine`.
- Save a hydration preference explicitly: if the user says “Remember I drink 8 glasses of water a day”, a suitable summary label is `hydration_habits`.
- Recall from summary labels: if the injected label catalog contains `dietary_preferences`, questions like “What do I like to eat?” or “What do I like to drink?” should recall that label before answering.
- Update or forget safely: if the user says “Forget that I like apples”, use `memory_recall` or `memory_list` to find the exact `memory_id` first, then call `memory_forget` with that `memory_id`.
