Every codebase has a layer of HACK, WARNING and TODO comments left by people who knew something the code does not say. Treating those as a retrievable memory store, rather than as decoration a linter ignores, gets value out of work that has already been done — no adoption cost, no discipline required from the team. The rest of the surface is a familiar shape done thoughtfully: history search for intent, context before a write, lessons after one. Note that ask_history's own description tells you it needs short specific keywords, which is an admission that the search is keyword matching and not semantic — worth knowing before an agent asks it a sentence-shaped question and reads the empty result as an absence of history.
A code-memory server in two halves: forensics over the repository's own history, and a store of lessons an agent writes for its successors. Six tools covering file analysis, history search, context retrieval, lesson capture, comment extraction and search.
- analyze_file returns forensic history, hidden dependencies and a risk assessment, and its description places it before modifying a file rather than after.
- ask_history searches git history for why code was written, with the tool itself warning that short specific keywords work and long queries do not.
- get_context returns the memories and code-graph relationships relevant to a file before it is touched.
- save_lesson stores a decision or a discovery for future sessions — the write side of the same loop.
- extract_memories harvests what is already in the code: IMPORTANT, WARNING, HACK and TODO comments that were written as notes to a human and never read as data.
- search_memories retrieves them with BM25 keyword matching.
Nothing to supply for the local path. Some behaviour changes when a cloud backend is configured, which extract_memories notes in its own description.
One command — npm install -g @byronwade/memoria