Persistent Memory
Instruction-only guidance for adopting a cross-session memory backend. No memory service, hook, or database ships with this skill.
The license field records Apache-2.0 for this skill's text. Any backend you choose carries its own license and terms; check them separately.
Procedure
The decision
Adopt a backend only when all three are true:
- The harness loses context that the next session genuinely needs.
- Project docs and a short handoff note cannot carry that context.
- You can name what is captured, where it is stored, and how it is deleted.
If any answer is missing, write a handoff note instead.
What a backend must specify
| Question | Required answer |
|---|---|
| Capture scope | Which events: prompts, tool calls, file paths, outputs? |
| Redaction | Which patterns are removed before storage, and when? |
| Storage | Local file, local database, or remote service? Encryption at rest? |
| Retention | How long, and what triggers deletion? |
| Injection | Maximum characters or tokens added to a future prompt? |
| Failure mode | What happens when the backend is unavailable? |
| Exit | How does a user disable capture and delete existing records? |
Adoption procedure
- Record the answers above in the project's docs, not only in chat.
- Start in a scratch project with a canary secret in the transcript.
- Verify the canary never appears in stored records or injected context.
- Cap injection to the smallest useful window; review what was injected.
- Run one session with the backend disabled to confirm work continues.
- Enable it project-wide only after steps 1-5 pass.
Platform scope
Harness integrations differ and change. This repository does not certify Claude Code, Codex, Cursor, Gemini, Hermes, or OpenCode support. Check the backend's own documentation for the current adapter and test it in your environment before relying on it.
Anti-patterns
- Capturing transcripts before redaction is configured.
- Using memory as a substitute for project docs or design rationale.
- Enabling injection with no size cap or review step.
- Keeping records with no deletion path.
- Assuming a first session has history to inject.
Verification Checklist
- [ ] A canary secret was absent from storage and from injected context.
- [ ] The injection cap is configured and visibly enforced.
- [ ] Deleting records removes them from every configured store.
- [ ] A session with the backend disabled still completes.