Doc Add Memory

Use this skill when any of these happen:

• The user explicitly says "remember this" / "save a memory" / "don't forget X".
• The user corrects an approach you took, and the correction is durable — it would apply in a future session, not just this one.
• The user confirms a non-obvious approach worked (a quieter signal, but worth catching).
• You learn a fact about the user, the work in flight, or an external system that future sessions can't derive from the code.

If none of these apply, do not write a memory — silence is the correct response.

1. Decide if it belongs here. Read the "What does NOT go here" section of project memory. If the fact is derivable from the current state of the codebase, git log, or CLAUDE.md, push back: tell the user where it actually belongs and offer to capture it there instead.
2. Pick the subtype:
   • feedback — a correction or confirmation from the user.
   • user — a fact about the user (role, expertise, preference).
   • project — a fact about the work in flight or its motivation.
   • reference — a pointer to an external system.

3. Check for an existing memory. Before writing a new one, search the catalogue:

   ./projects/ores.compass/compass.sh list --type memory --regex '<keyword>'
   

   If a memory already covers this point, update it rather than creating a duplicate. Refresh #+updated when you do.

4. Pick the slug. Snake-case, descriptive of the rule rather than the topic. Use the user's framing where possible — do_not_re_export_env_vars, not bash_environment.

5. Scaffold the file with compass — see How do I create a memory? for the full incantation. The essentials:

   ./projects/ores.compass/compass.sh add memory \
     --slug <slug> \
     --parent-dir doc/llm/memory \
     --title "<one-line title>" \
     --description "<one-line description>" \
     --memory-subtype feedback
   

6. Fill in the body — three parts, in order:
   • One short paragraph stating the rule, fact, or insight.
   • *Why:* — the reason or incident. Knowing why lets a future session judge edge cases.
   • *How to apply:* — when this kicks in.
7. Wire into the inventory. Open Project memory and add the id-link under the matching subtype heading.
8. Confirm with the user that the captured memory matches their intent. Read back the title and one-line summary; offer to adjust.

These requests look like "remember X" but are usually misfiles:

• "Remember this architecture decision" → write a knowledge doc in doc/knowledge/ instead. Memory is about how to work together, not about how the system is built.
• "Remember to fix Y next time" → that's a task or a capture, not a memory.
• "Remember that the build command is …" → that belongs in CLAUDE.md or a recipe.
• "Remember what we did this sprint" → that's the sprint's * Decisions section.

In all of these, redirect; do not silently file the wrong shape.

• How do I create a memory? — the operational scaffold flow.
• How do I show a doc by UUID? — inspect an existing memory before updating it.

• Project memory — the catalogue and the inclusion/exclusion rules.
• Document types§=memory= — the contract every memory file satisfies.