Project memory

Table of Contents

Project-scope persistent memory for LLM sessions. This is where any LLM working on ORE Studio should write things that future sessions need to remember — feedback from the user, durable project facts, references to external systems, anything that would otherwise be lost between conversations. Each memory lives as a single .org file in this folder; this page is the catalogue. See How do I create a memory? for the operational flow and the ores-memory skill for the LLM-side procedure. Return to Knowledge.

What goes here

Memories are short, atomic, and durable. Use the same four subtypes as Claude Code's auto-memory:

  • feedback — what the user has corrected or confirmed. Lead with the rule, then *Why:* and *How to apply:* lines.
  • user — facts about the user's role, expertise, working style.
  • project — facts about the work in flight or its motivation that aren't otherwise derivable from the code or git history.
  • reference — pointers to external systems (where a thing is tracked, which dashboard is canonical).

Every memory carries #+type: memory and #+memory_subtype: <one of the four>. The :memory: filetag makes the whole set greppable in one shot.

What does NOT go here

  • Code patterns, conventions, architecture — derivable from the current state of the codebase; live in Knowledge instead.
  • Git historygit log / git blame are authoritative.
  • Debugging recipes — the fix is in the code; the commit message has the context.
  • Anything already documented in CLAUDE.md.
  • Ephemeral task state — current sprint work belongs in the sprint/story/task docs, not here.

If the user explicitly asks you to remember something that fits any of these exclusions, push back: the right home is somewhere else.

Catalogue

Feedback

User

(none yet)

Project

Reference

See also

Emacs 29.1 (Org mode 9.6.6)