/memory

name: memory
scope: common
aliases:
  - memory-curation
metadata:
  nativeReplaces: [llm-wiki]
description: Persist and retrieve agent memory across sessions — recall via the three-stage protocol (structure route → semantic search → navigation fallback), read via memory_load, see the wiki structure via memory_browse, write well-placed pages via memory_write (including section-level append/rewrite), maintain via memory_curate. Use whenever the user asks to remember/forget something, when you need to look up past decisions or context, or when episodic state matters beyond the current turn. Primary surface is the NATIVE memory_* tools (a `prismer memory` CLI appendix exists for code agents running in a shell).

Memory

For an explicitly requested Markdown wiki artifact, read `references/llm-wiki/GUIDE.md` relative to this skill. Its schema, provenance, contradiction and lint workflow operates only in the user-selected project/vault; it does not replace the platform memory tools or create a default home wiki.

Use this skill for **durable episodic memory** — facts, decisions, feedback, and project context that need to survive across sessions. Memory has four canonical types: `user`, `feedback`, `project`, `reference`. Pages live at semantic paths and are organized as a wiki: an `INDEX.pkf` at the top, **hub** pages per topic, and **leaf** pages under hubs.

**Richness is the goal.** A memory page should be complete enough that a future session works FROM the page instead of re-reading the raw file or the internet. There is no length budget on ordinary pages — the only waste is *repetition* (re-extracting what is already distilled, re-querying pages already in your context).

> **Seam — memory content is PKF; the write invariants are embedded below.** The full > body syntax (sections, data views, media, math, harness), validation and projection > belong to the **`pkf-writing`** skill, but this skill carries the MANDATORY write > invariants inline (see *PKF body standard* below) so a write is safe even when > `pkf-writing` is not loaded. **This skill decides WHAT to remember, WHERE it goes, and > HOW the graph is maintained.**

Recall protocol — three stages, in order

Answer a workspace-knowledge question by walking these stages. Stop at the first stage that answers it; never skip straight to guessing.

**STAGE 1 — STRUCTURE ROUTE (first round is hybrid).** The first round of any recall is **hybrid — two calls in the same round**, never one instead of the other:

• **Parameterless `memory_browse`** — the root structure surface: `{index,

hubs[{path,title,pageType,snippet,updatedAt}], hubsByRecent[], nearest[]}`. Hub order has two views: `hubs[]` is the **structural order** (the order the workspace publishes; today hub rows are ordered by the hub's own `updatedAt` DESC — that IS the structural-order baseline); within a hub, its children come `updatedAt` DESC. Each hub row carries **subtree freshness** — `updatedAt` = the most recent write under that hub (the hub row's own `updatedAt` spread with its direct children's). `hubsByRecent[]` repeats the **same hub set in recency order** (subtree `updatedAt` DESC) — the "what changed" signal; the two orders differ exactly when a child page was written more recently than its hub row. **There is no `memory_recent` tool** — recency is a signal ON browse results, not a query surface. Hubs are *routing* pages: their job is to tell you which leaf to open.

• **Batch `memory_search`** — extract ≥2 phrasings of the turn's terms into `queries[]`

(≤8, returned grouped in `resultsByQuery`): one round trip, several recall intents. When the turn has no lexical terms ("what changed recently?", "what's the team up to?"), the batch **degrades but still runs** — the signal query executes anyway.

**Both question types are covered in one round.** Term-bearing questions are covered by the batch search; termless questions have exactly the structure surface as their search space — term extraction necessarily spins empty on them, so the root browse is what catches them.

**Exemption — one, and tight: the digest names the answer.** The stable memory map (INDEX-TOC + one line per hub) injected at turn start under "Memory Map (auto — stable digest)" lets you skip the hybrid round ONLY when it **names the answer outright** — the exact hub or page the answer lives in, loadable directly. **A passing one-line mention is NOT coverage**: if the digest only mentions the hub or topic, the hybrid first round still runs. Structural facts the digest itself states (which topics exist, what a hub covers, where a topic's children live) are answered from the map, and `memory_browse` with the topic as `query` serves follow-up structure questions on demand.

**STAGE 2 — SEMANTIC SEARCH (the hybrid round's hits).** The batch `queries[]` leg answered the term-bearing side; its hits are your **decision payload** — hop-decision fields tell direct-read vs multi-hop, and the browse-root live structure (including its recency signals) tells where to wander next. Read each hit's hop-decision fields before deciding what to do:

| Field | What it tells you | |---|---| | `tier` | `wiki` = distilled/curated page (highest trust); `asset` = a raw span a distilled page already cites via `derived-from` (middle); `raw` = the upload's own text, no synthesis (lowest — verify before relying on it) | | `hubPath` | the hub this page hangs under — a `wiki` hit is context for its whole hub, so a near-miss here often means the ANSWER is a sibling leaf | | `childrenCount` | how many pages fan out under this hit (>0 ⇒ it is a hub you can walk down) | | `outboundPreview` / `inboundLinkCount` | where the page points / how linked it is — the cheap next hop | | `sectionAnchor` + `sectionPreview` | the exact section that matched — read THAT, not the whole page |

`memory_search` returns **ranked hits with lexical evidence** (the query matched the page). A high-rank `wiki` hit is usuall