Memory & knowledge

Memory entry point

One route into the long-term memory libraries, with a reading budget that stops context bloat.

Free Free to read and free to ask for by email.

Background

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.

Why it is built this way

The retrieval order narrows one layer at a time. Step 0 reads 记忆总览.md, capped at one page. Step 1 greps INDEX.md and keeps only the keys on matching lines. Step 2 opens one work-line page. Step 3 opens one volume of the requirement library. Steps 4 and 5 grep lessons and decisions, reading twenty lines around the hit. The budget of three files and 8k characters turns that order into a number. A task that spends its context on library pages has nothing left for the work.

The four libraries are split by who the knowledge belongs to: memory library for the person and the rules, requirement library for the standard of the work, experience library for the craft, knowledge base for what was done. The test is whether someone else doing this work would still need to know it. Libraries are snapshots, so the current instruction and AGENTS.md outrank them, and a conflict gets reported. Writing stays out of scope, except the memory library, which takes one or two entries on a correction, each with source, date and a P0/P1/P2 level.

Where it bites

• The whole library lands in context A task opens with four library files read in full. The 8k budget is gone before any work starts and the reply turns into a recital of old projects. The ban on whole-file reads and step 1 keeping only keys on matching lines exist for this, and INDEX.md is 477 lines.
• A stale snapshot read as current Cards carry dates. A spec gets revised or a key stops working, the old conclusion stays in the library, and following it redoes work that was already overturned. Quoting one line of source with the snapshot date is what lets the user answer that the page is out of date.
• Filling a grep miss with common sense The keyword returns nothing, so a plausible date or decision gets stated anyway, and the user cannot tell library content from invention. The rule is one line: if grep finds nothing, say the library has no record of this. A missing read costs time, an invented one changes later decisions.
• Daily logs written into the knowledge base Progress notes written straight into the library are not in the card queue when kb-builder reruns, so INDEX and the directory stop matching and nothing can be traced back. Writing is kept outside: additions and merges go through the kb-builder incremental flow, and only when the user says organize the knowledge base.

Inside this skill

1. When to use it
2. Where the libraries are
3. Retrieval order (narrow down layer by layer, stop on a hit)
4. Hard rules
5. Output habit

The outline is the skill file's own headings, in the order it uses them.

When to use it

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.

How to use it

1. Ask for the file by email — it is a single SKILL.md.
2. Put it in the skills folder your agent reads, in a directory named memory-vault.
3. Start a message with the trigger from the description, or name the skill directly.