structured-memorylisted

Defines how an agent should manage its own structured, persistent memory across whatever memory backends are configured in this environment — durable cross-session stores, project- or workspace-scoped notes, and short-lived task-tracking state. Use this whenever memory itself is the subject of the task — the user asks to remember, save, recall, forget, or reinforce something explicitly; asks to audit, clean up, consolidate, deduplicate, or curate existing memory; asks what belongs in long-term memory vs. task state vs. project-scoped notes, or what counts as durable "cross-project" knowledge; reports that a stored memory is wrong, stale, or contradicts something else; or whenever about to write any memory longer than one short, single-fact sentence — some memory backends silently corrupt or truncate multi-clause writes with no error signal, and the write-format rules here prevent that class of data loss. Also consult this before treating a subagent's or web research's claims as settled fact worth persisting.
tkolleh/skills · ★ 1 · Data & Documents · score 75

Install: claude install-skill tkolleh/skills

# Structured Memory Up to three memory roles are available in this environment — local file-based memory, a long-term memory service, and a task-tracking store — each with its own scope and reliability profile (see `references/memory-backends.md` for the full mechanics of each). This skill is the decision layer on top of them: what's actually worth persisting, which type it is, which store it belongs in, how to write it so it survives intact, and when to prune or reinforce what's already there. The recommendations below are grounded in current research on LLM agent memory — see `references/research-summary.md` for the full citation trail. That file exists so this one doesn't have to carry citations inline; read it when you want the "why" behind a rule here, or when deciding how much weight to give a judgment call that isn't clear-cut. ## The core loop For any candidate memory, work through these in order. Don't skip straight to "where do I write this" — most low-value memories get caught at step 1. ### 1. Is this actually worth persisting? Apply the test that already governs project-scoped memory, and hold cross-store additions to the same bar: **if the user starts a genuinely different, unrelated project next month, would this fact still save them time?** If the value is purely in retracing one ticket's or one incident's specific history, it belongs in project-scoped memory at most, not a durable store. Never persist what's cheaply re-derivable from the current state