Loading
Teaches when to recall from long-term memory before acting and when to save durable decisions, corrections and failures afterwards. Use when a memory tool or MCP memory server is connected but the age
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add davepoon/buildwithclaude --skill agent-memory-discipline -a cursor -y
Teaches when to recall from long-term memory before acting and when to save durable decisions, corrections and failures afterwards. Use when a memory tool or MCP memory server is connected but the agent is not using it consistently, when the user complains that the assistant forgets preferences, conventions or past decisions between sessions, or when setting up persistent memory for a project. Works with any memory backend: a folder of Markdown files, a local MCP server, or a managed service.
Teaches when to recall from long-term memory before acting and when to save durable decisions, corrections and failures afterwards. Use when a memory tool or MCP memory server is connected but the agent is not using it consistently, when the user complains that the assistant forgets preferences, conventions or past decisions between sessions, or when setting up persistent memory for a project. Works with any memory backend: a folder of Markdown files, a local MCP server, or a managed service.
Connecting a memory tool does not make an agent use it. Tools register, the session runs, and nothing gets recalled or saved. This skill supplies the missing part: standing rules for when to read memory and when to write it.
It is backend-agnostic. Everything below works the same whether memory is a folder of Markdown files, a local MCP server, or a hosted service.
Read memory before doing any of these, not after:
Do not recall for one-off factual questions, arithmetic, or anything fully specified in the current message. Recall costs a tool call and context; spending it on a self-contained question is waste.
Search with the words the user actually used, plus the project or repository name. If the first search returns nothing useful, try one broader query, then stop and proceed without memory rather than looping.
Write to memory when one of these has just happened:
Do not save: the contents of files you can read again, restatements of the current task, transient state, anything the user marked as temporary, and anything containing secrets, tokens, or personal data.
One memory, one fact. A paragraph containing four decisions cannot be superseded cleanly when one of them changes.
A memory that is useless in three weeks was written wrong. Each entry should carry, in the text if the backend has no fields for it:
Prefer the user's own words over your paraphrase. Paraphrase drifts.
When something changes, the old memory is not wrong. It is closed.
If the project moved from Redux to Zustand, "we use Redux" was true from January to June. Deleting it destroys the explanation for every component written in that window. Mark it superseded, keep its validity window, and write the new one alongside.
This is the single most destructive habit in agent memory, and it is invisible until someone asks a question about old code.
If recall returns two entries that disagree, do not pick the closer match and proceed. Surface both, with their dates, and ask or flag.
A convention that a recent failure contradicts is exactly the situation where the user needs to be told, not smoothed over.
An observation becomes policy when a human confirms it, when it lands in a merged decision record, or when it has worked repeatedly. Never promote a single observation to a rule on your own.
The user says: "stop using npm here, we're on pnpm."
Project uses pnpm, not npm. Stated by the user on 2026-08-11 after a lockfile conflict. Applies to all packages in this repo.Before acting on project-specific work: did I recall? After a decision, correction, or failure: did I save it, in one sentence, with its reason? When something changed: did I close the old entry instead of deleting it?
This skill assumes a memory tool exists. Any of these work:
memory/ folder of Markdown notes, one fact per file. No dependencies, fully greppable, versionable in git.Written and maintained by the team behind Mnemoverse, which is one hosted implementation. The rules above are deliberately backend-neutral and were written to be useful without it.