--- name: memory-vault description: "The read entry point for cross-project permanent memory. Use before starting any non-trivial task, or when the user asks how something was decided before, what their preferences are, or how far a project got; it defines layered, on-demand reading of the memory library (about the user), the Obsidian knowledge base and the requirement library, and forbids dumping a whole library into context." --- > Original skill · commissioned by the user · English edition, 2026-11-12 # Permanent memory read entry point The user's historical preferences, decisions and project details are already sedimented on disk (session cards, work lines, multi-volume requirements). **This skill does one thing only: make that content get read when it is needed, and read only the few pages that should be read.** ## When to use it - Before starting any non-trivial task (producing assets, writing code, configuring an environment, making a plan) — spend one grep's worth of time first confirming "has this been done before". - When the user mentions "before", "last time", "per what I set up originally", "didn't I say this already". - When the user asks "how far has this project got", "what are my preferences". - When you are not sure whether a spec or red line is something you invented yourself. **Not for**: one-off factual questions (what date is it, what does this code mean), pure small talk, or cases where the user has already given you the full context in this conversation. ## Where the libraries are | Purpose | Path | |---|---| | **About the user themselves** (form of address / habits / red lines / taste / repeated rework points) | ``, entry `overview.md` (one page) | | Sessions / projects / lessons / decisions | `` (open this directory directly as the Obsidian vault, do not create another) | | Requirements the user keeps repeating (multi-volume) | ``, entry `requirements-overview.md` | | Not in the libraries, needs a rebuild or a new session added | The `kb-builder` skill | **Division of labour across the four libraries**: the memory library records "the person and the rules", the requirement library records "the standard of the work", the experience library records "the craft of the work", the knowledge base records "what has been done". The test: if someone else did this work, would they still need to know this? Yes (it is about the user) → memory library; no → requirement library / experience library. ## Retrieval order (narrow down layer by layer, stop on a hit) 0. **Who the user is**: read `/overview.md` first (≤1 page). If a P0 hits, follow it; if you need detail, open **one** sub-page (`20-communication-and-replies` / `30-delivery-and-files` / `40-red-lines-and-authorization`, etc.), do not open three at once. 1. **Locate**: `grep` the keyword across `/INDEX.md` and `20-projects/INDEX.md`, and take only the keys from the matching lines. **Do not** `read` the whole INDEX.md. 2. **Project state**: on a work-line hit → read `20-projects/.md` (one page, enough). 3. **User requirements**: read `/requirements-overview.md` to locate the domain → open only that **one volume**. 4. **Methods / pitfalls**: `30-topics/.md` and `40-lessons/lessons.md` (grep the hit paragraph and read ±20 lines around it, not the whole file). 5. **Why a decision was made**: `50-decisions/decisions.md`, grep the same way. 6. **Need the original text / an absolute path**: go into `10-session-cards///.md`; the "original file" field in the card has the session location. ## Hard rules - **Budget**: library content entering the context for a single task ≤ 3 files, ≤ 8k characters. Going over means you are being lazy about reading the library, not that you are using memory. - **No whole-file reads**: `INDEX.md`, `lessons.md`, `decisions.md`, `*_full.md` are always grep-then-read-locally. - **Not a second authority**: the libraries are historical snapshots. When they conflict with **the user's current instruction** or the global `AGENTS.md` instructions, those two win; when you find a conflict, point it out in your reply and suggest changing the library (do not change it yourself). - **Do not guess**: if grep finds nothing, say plainly "the library has no record of this"; do not fill the gap with common sense. - **Check freshness yourself**: pay attention to the card dates of what you read; things that happened after the library snapshot may already have overturned it (for example a revised spec, a key that stopped working). - **Writing is not in this skill**: additions and merges in the knowledge base / requirement library go only through the `kb-builder` incremental flow, and **only when the user says "organize the knowledge base"**. Do not casually write daily logs into the libraries, or you will fight with the generated output. - **The memory library is the exception (casual writing is allowed)**: when the user corrects you on the spot, or when the same requirement shows up ≥2 times, append 1–2 entries to the matching sub-page under the trigger conditions in `/90-sources-and-maintenance.md`, always with source + date + level (P0/P1/P2). This library was commissioned precisely so the rules need to be repeated less and less often. ## Output habit When quoting library content, include one line of source, for example "per `20-projects/.md` (snapshot: )". This lets the user reply "that page is out of date" instead of thinking you are making it up.