/slm-remember

name: slm-remember
description: Capture durable facts, decisions, constraints, and gotchas into SuperLocalMemory. Use when the user says "remember that", "save this decision", "note this constraint", or when a session produces a conclusion worth persisting across sessions. Always recall first to avoid duplicates.
when_to_use: |
  - "Remember that we use JWT with 1h expiry"
  - "Save this architectural decision"
  - "Store the constraint that X must not Y"
  - "Note this as a gotcha / blocker / convention"
  - After making a non-obvious decision during a coding session
  - After resolving a bug whose root cause should be persisted
allowed-tools: remember, recall, update_memory, set_memory_kind, review_memory_kinds, confirm_memory_kinds, list_corrections, review_correction, delete_memory, Bash(slm:*)

slm-remember — Capture Durable Facts

Store atomic, durable facts into SuperLocalMemory for retrieval in future sessions. One fact per call. Recall before you remember.

---

What to store (and what not to)

**Store:**

• Architectural decisions ("Decided to use Postgres not MySQL — reason: JSONB support")
• Project conventions ("All API routes follow /api/v1/resource/{id} pattern")
• Hard constraints ("Never expose raw SQL errors to the HTTP response")
• Resolved gotchas ("Ollama needs keep_alive=-1 or it unloads the model between calls")
• Security rules ("Rate limit all public endpoints at 100 req/min")

**Do not store:**

• Pictures or PDFs through `remember`. It stores text. A screenshot, photo or

PDF goes through `remember_media` or `remember_document`; see `slm-media`. Add the reason it matters in the text of a normal memory if you also want a fact about it.

• Transient context that is only relevant within this conversation
• Large blobs of code or full file contents (those belong in the project, not memory)
• Facts the project README already captures

---

Recall-before-remember (mandatory discipline)

Before calling `remember`, always call `recall` first with the core terms of what you are about to store. If a near-duplicate exists:

• If the new text **replaces** the old one (a status that moved on, a decision

that changed, a rule that was reworded), save it with `remember(..., replaces="<fact_id>")`. It takes effect at once and can be undone.

• If you are **correcting** the old memory and want a person to approve the

change, use `update_memory(fact_id, content)`. This opens a correction for review; it does not overwrite anything (see "Updating a memory" below).

• Only call `remember` with neither when no sufficiently similar fact is found.

Duplicates degrade retrieval quality for every future session.

---

MCP-first workflow

1. Check for duplicates first

recall(query="JWT token expiry auth", limit=5, session_id="<sid>")

If a near-duplicate is returned:

remember(
  content="JWT tokens use 1h expiry for API access tokens; refresh tokens 30d",
  tags="auth,security,decision",
  project="superlocalmemory",
  kind="decision",
  replaces="f8a2bc91",
)

The old memory is retired, not deleted: recall stops returning it and it is no longer loaded at session start. The response's `replaced` says what was retired, or why nothing was (the new memory is saved either way). An unknown id, or an id from another profile, is refused before anything is saved.

2. Store a new fact

remember(
  content="Decided to use JWT with 1h expiry for API auth; refresh tokens persist 30 days",
  tags="auth,security,decision",
  project="superlocalmemory",
  importance=8,
  session_id="<sid>",
)

Real response shape:

{
  "success": true,
  "fact_ids": ["c9d4e112"],
  "count": 1,
  "pending": false,
  "pending_id": null,
  "operation_id": "op-7c21",
  "materialization_state": "complete",
  "message": "Stored through canonical daemon ingestion."
}

`pending: true` with `materialization_state` `queryable` or `enriching` means the memory is already stored and findable by its words while enrichment finishes; do not re-save. A reply with `materialization_state: "accepted"` and `count: 0` means the memory is durable but the writer was busy; it becomes searchable within seconds, and resending the same `idempotency_key` returns the final receipt. When the call used `replaces` the reply carries `replaced`; when the same words were already saved under another confirmed kind it carries `kind_conflict` and keeps that kind.

Failures come back as `success: false` with a `code` and `retryable`: `DAEMON_UNAVAILABLE` (`retryable: true`), `INVALID_KIND`, `NOT_AUTHORIZED`, or an unknown-profile / unknown-`replaces` refusal (`retryable: false`).

**Never claim "saved" unless `success: true` is in the response.**

3. Parameter reference

remember(
  content: str,       # required — the atomic fact to store
  tags: str = "",     # comma-separated tags, e.g. "auth,security,gotcha"
  project: str = "",  # project scope, e.g. "superlocalmemory"
  importance: int = 5,# 1–10; see scale below
  session_id: str = "",# from session_init; attributes the write to this session
  session_date: str = "",# when the memory is ABOUT, if not today
  scope: str = None,   # "personal" (default) | "shared" | "global"
  shared_with: str = "",# comma-separated profile_ids for scope="shared"
  idempotency_key: str = "",# replaying the same key will not store a second copy
  kind: str = "",      # what sort of memory this is; see "Say what kind it is"
  replaces: str = None,# fact_id (or memory_id) of the earlier memory this one replaces
  profile_id: str = "",# write to another existing profile; "" = the active one
  agent_id: str = "mcp_client", # attribution; resolved from the connection when left alone
)

> **Multi-scope (opt-in):** leave `scope` unset for `personal` (private to > this profile — the default, the same as a single-profile install). `"global"` is visible to every > profile on the machine; `"shared"` is visible to the profiles in `shared_with`. > Se