Show HN: Memory-Catalog – Claude memory protocol to manage A developer released Memory-Catalog, an open-source plain-Markdown protocol for organizing an AI assistant's long-term memory, built on Claude's memory and Projects features. The spec defines five principles — one fact, one home; user adoption of assistant proposals; provenance checkpoints such as ⟨a1b2c3d4 t13→t20⟩ recording the chat turn where an entry was proposed and accepted; an "already considered" register for rejected ideas; and proof-before-removal with a byte-verified backup — plus five safety rules (S1–S5) and an optional Project board. The structure is designed to carry over to any assistant with file-based memory, with Claude-specific parts labeled as such in the spec. A protocol for organising an AI assistant's long-term memory so it stays useful as it grows: an index of your work streams, a backlog of what's next, a dated log of what happened, a register of ideas already considered , and links from every entry back to the exact chat turn it came from. If you find it useful, a ⭐ helps others discover it. It was built on Claude's memory and Projects. Everything is plain Markdown, so the structure carries over to any assistant with file-based memory; Claude-specific parts are named as such in the spec. Assistant memory tends to turn into a pile. Status is repeated in several places and drifts apart. You can't tell which decisions you made and which the assistant suggested. Ideas you rejected come back as new. Cleaning up risks deleting the one fact that wasn't recorded anywhere else. The catalog is built on five principles: - One fact, one home. Status lives only in the backlog, history only in the log. Detail that a repository already holds stays there, with a pointer to it. SPEC §3 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 3-what-belongs-in-an-area-file-and-what-does-not , §11 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 11-keeping-memory-small - You adopt, the assistant proposes. Anything from the assistant's analysis is filed only after you confirm it. SPEC §5 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 5-catalog-this-chat-step-by-step , the adoption gate - Provenance. Every entry carries a checkpoint such as ⟨a1b2c3d4 t13→t20⟩ : proposed at turn 13 of that chat, accepted at turn 20. Verbatim anchor phrases let the link be verified or repaired if the chat is edited. SPEC §6 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 6-checkpoints-and-quotes - Nothing is lost silently. Ideas you declined, and ideas raised but never discussed, go into an "already considered" register so they don't come back as if new. SPEC §5a https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 5a-the-already-considered-register - Proof before removal. A cleanup removes nothing that can't be proven to exist elsewhere, and you get a byte-verified backup first. Safety rule S2, SPEC §13 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 13-safety-rules and §16 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 16-formats-backup-cut-list-unverified-marker The five safety rules S1–S5 that protect your data are in SPEC §13 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 13-safety-rules . New to the vocabulary? See Terms, SPEC §0 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 0-terms . Requirements, checking the installation, updating and removal are in INSTALL.md https://github.com/donalddominko/Memory-Catalog/blob/main/INSTALL.md . The short version: The catalog. Open a new chat outside any Project , attach SPEC.md https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md and send: Set up the catalog system from this spec. Show me what you'll create before writing anything. The assistant proposes the catalog files and how your existing memory is sorted into them, asks a few questions, and writes only after you approve. Check it worked with status digest . A Project board optional . Open a chat inside the Project and send: set up the board Until the nightly sync exists, a board shares status only between chats of that Project. To bring a Project's news into your main catalog, say "read the Project name board and update the catalog" in a main chat. SPEC §7 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 7-project-boards Say these in plain words; exact wording doesn't matter. Where: MAIN = a chat outside any Project · PROJECT = a chat inside a Project · ANY = either. This table is copied from SPEC §12 https://github.com/donalddominko/Memory-Catalog/blob/main/SPEC.md 12-commands , which is the source of truth. | Say | Where | What happens | You get back | |---|---|---|---| | Set up the catalog system from this spec. Show me what you'll create before writing anything. attach SPEC.md | MAIN | Stores the spec as /catalog/protocol.md , proposes the catalog files and how your existing memory is sorted into them, asks questions | A proposal, then the list of files created after you approve | | Update the catalog protocol to this version. Show me what changes before writing. attach the new SPEC.md | MAIN | Compares with /catalog/protocol.md | The differences, then the update after you approve | | Delete the catalog files. | MAIN | Whole-file deletion on explicit request rule S2 ; a backup is offered first | Confirmation of what was deleted | | set up the board | PROJECT | Creates board.md , feed.md , inbox.md , considered.md in that Project section 7 | The list of files created | | export the catalog spec | MAIN | Generates this document from the protocol rule S1 | The file | | clean up file / slim area file | MAIN | The rule S2 procedure section 16 | A backup file and a cut list; nothing removed until you approve | | catalog this chat | ANY | Section 5 inside a Project it writes only that Project's files | Candidates and questions, then the three-part report | | catalog my past chats / catalog chats about topic | ANY | Section 5, one chat at a time for many chats, section 18 ; only reaches chats in the same scope | The same, per chat | | what's next / backlog for stream | ANY | Reads the backlog | The matching task lines | | park task / task is done / drop task | ANY | Status change + log line; "done" needs evidence section 4 | Confirmation of the change | | status digest | ANY | Reads the index and backlog | A plain text summary | | was idea considered? / what was left undiscussed about stream | ANY | Reads the register | Matching lines with status and checkpoint | | verify checkpoints | ANY | Section 6 | Each anchor's result | | read the Project name board and update the catalog | MAIN | Brings a Project's news into main memory until the nightly sync exists section 7 | Candidates, then the usual report | | File | Holds | |---|---| | index.md | Every work stream, its status, where its detail lives | | backlog.md | Open tasks by stream: the only place task status lives | | log.md | Dated history, older months rolled up | | principles.md | Rules of thumb you've adopted, with checkpoints | | considered.md | Ideas declined with your reason or raised but not discussed | | checkpoints.md | Chat keys, turns and anchor phrases for provenance | | quotes.md | Planned. Exact key sentences, append-only | Alongside the catalog, each work stream has an area file /areas/