persistent-memory
SolidPersists context across conversations as plain markdown so every future session can enrich a topic-scoped memory (e.g. `parenting`, `relationship-anna`, `work-history`, `project-acme`). Four operations: `write` (extract candidates, resolve as ADD / UPDATE / DELETE / NOOP per Mem0), `read` (load a ≤ 200-line INDEX; fetch detail entries on demand per Claude Code's MEMORY.md pattern), `consolidate` (sleep-style merge + prune), `forget` (delete or redact with audit). Three storage tiers: home (`~/.agent-memory/<scope>/`, default), project-local (gitignored), project-shared (committed). Strict never-store list (passwords, API keys, JWTs, credit cards, SSNs, private keys); mandatory consent preview before write. Documents scaling from markdown → SQLite FTS → vector DB → managed memory (LoreKit / Mem0 / Letta / Zep). Documents the LoreKit backend the self-improvement loops now run on (`autonomous-workflow`, `fix-bug`, `batch-linear-tickets`, `implement-suggestion`, `ci-auto-fix`, `e2e-pr-stabilizer`, `test-auto-fix`
Install
Quality Score: 84/100
Skill Content
Details
- Author
- mthines
- Repository
- mthines/agent-skills
- Created
- 3 months ago
- Last Updated
- 2 days ago
- Language
- TypeScript
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
persistent-memory
This skill should be used when the user asks the AI to remember information across sessions, keep long-term memory, recall prior context, or distill accumulated notes. Trigger phrases include "记住", "记下来", "长期记忆", "别忘记", "跨会话", "recall", "remember", "memory". It implements a file-based memory system with dated daily logs, a curated MEMORY.md, topic search, and periodic distillation.
bettermemory
Verification-grade memory between sessions. Use bettermemory's MCP tools (memory_search, memory_show, memory_write, memory_verify, memory_record_use, etc.) instead of writing to files when the user asks you to "remember" something or references shared context from a past session. Default is to NOT call memory_search; only retrieve when the user references context you don't have ("my project", "the script we wrote") or a request is ambiguous in a way stored preferences could resolve. Every hit carries a staleness_verdict (calendar + path-drift + commit-drift); when it isn't "fresh", spot-check a claim before relying and call memory_verify to attest. Every use should record a claim_excerpt so retrievals stay auditable.
memory-sync
Persist new context, terms, learnings, and settled lightweight decisions. Use when the user says remember this, save this for later, add to glossary, note this down, or at session end to consolidate what was learned — that goes to the memory layer (CLAUDE.md hot cache, docs/memory/, docs/inbox.md). Also use to record a decision or remember this decision when the call is a lightweight one shipped outside a spec slice: UI strings, visual and CSS choices, copy, or translation fixes. Those go to docs/decisions/lightweight-decisions.md via decisions.py. Also use when revising, updating, or re-pricing an already-recorded decision: judge whether it now warrants an ADR and promote it if so, rather than editing it in place. Also auto-fires at session end. Do not use for updating specs or code comments. For a NEW load-bearing decision, one with rejected alternatives, or any the user wants written up as an ADR, use `/jig:adr-workflow`; an already-recorded entry that outgrew this home is promoted from here.