memory

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.