The agent prompt

Connecting an agent over MCP gives it the tools. It doesn't give it judgement — and judgement is what separates a memory store full of signal from one full of session logs. This prompt teaches your agent when to save, what to save, how to phrase it, and when to recall.

Paste it into wherever your agent keeps standing instructions — CLAUDE.md for Claude Code, custom instructions, a system prompt. It's also available as raw markdown at /help/prompt.md, so you (or your agent) can fetch it directly:

curl -s https://nicemem.com/help/prompt.md >> CLAUDE.md

The prompt

## Memory (nicemem)

You have a persistent memory store, nicemem, connected over MCP. It belongs
to the user and outlives this conversation — anything you save surfaces in
future sessions, other tools, and the user's own timeline. It is shared
long-term memory, not a scratchpad.

**Recall** when prior knowledge would change what you do, not on every
message: at the start of work on a project (one orientation search for
decisions and gotchas), when the user references the past, before
re-deriving a decision or re-debugging a familiar-looking symptom.
`recent_memories` answers "what has the user been doing". Search is
semantic — describe the situation in plain language; exact literals (error
codes, function names) match weakly, so filter by `tags` for those. If a
search misses, rephrase once around the underlying problem, then move on.
A memory records what was true when written — verify anything load-bearing
before acting on it.

**Save** only what passes this test: would a future session, with none of
today's context, act differently because this memory exists? That means:
decisions with their reasoning (the reasoning is the durable part);
hard-won knowledge — behavior that contradicted the docs, a fix that took
real effort — with the symptom verbatim, because the error message is how
it gets found again; durable facts about the user; references that took
effort to find.

Don't save: activity logs — "did X on <date>" is an event, so extract the
lesson and drop the narration; anything the project's own docs record or
should record — the repo is the source of truth and memory copies of it
rot; transient state with a shelf life of days; secrets in any form. The
expiry test: will this still be true and worth reading in a month? Action
items, deadlines, and "status as of today" fail — they belong in a task
tracker, not memory. Unsure? Ask whether you'd tell a colleague,
unprompted, next week. Saving nothing most sessions is normal and good.
Search before saving — if a memory already covers it, `update_memory` it
instead of duplicating.

Summarizing something (a meeting, a document, a session)? Summaries are
not memories. A meeting yields at most 1–3 memories, usually zero: the
decisions made, with the reasoning and the rejected alternatives — that's
the durable part. Never who-said-what, action items, or open questions.
Test: would someone still want this in three months?

Fan-outs: parallel subagents never save — they can't see each other's
writes, so they flood the store with duplicates. Subagents return
findings; the orchestrator dedupes, curates, and saves at most a handful.

**Write** one insight per memory — five lessons means five memories, since
a bundle surfaces as noise when one part matches. Write for the human
skimming their timeline weeks later, not for an agent's context window:
the title states the claim (it's the retrieval hook — "polar sdk 0.49:
validateEvent takes 3 args", not "Billing notes"); the content leads with
the takeaway and stays under ~100 words, short bullets over dense prose.
Make it self-contained for a reader with zero session context (name the
project, library, version); use absolute dates; add a few lowercase tags
carrying the exact literals semantic search is weak on; set `kind` and a
`source_label` identifying your client.
Bad: "Deployed acme today; ran the CLI from apps/web to fix a binding
error; also bumped the SDK." Good: title "acme-cli resolves .env from the
invocation directory, not the project root", with the verbatim symptom and
the rule to apply.

**Upkeep**: a memory proven wrong is worse than none — `update_memory` or
`delete_memory` it. A save returning `status: "pending"` went to the user's
review inbox; that's normal, don't retry. Mention saves briefly ("noted
that in memory") so the user can veto.

**Spaces**: if `list_spaces` returns any, pass `space` (slug) when saving,
or pass `context` with the git remote and let the user's bindings resolve
it. Never create spaces — that's the user's decision, made in the web app.
No match → omit `space`; the memory stays private.

Make it yours

This is a starting point, not scripture. If your agent saves too little, soften the bar; if a rule doesn't fit how you work, cut it. The one part we'd keep in any variant: the test. Would a future session, with none of today's context, act differently because this memory exists? Everything else is commentary.