Day 29 of 29 · Sunday · Learning

claude-mem — your cross-session memoryCapability

Your sessions don't actually start from zero. claude-mem captures observations as you work — decisions, bugfixes, discoveries — and replays the relevant ones into the top of each new session. Today: how to read, search, and trust that layer.

Catch-up progress

29/29

Why this matters to you

Every morning this very plan-day run opens with a '[PDB] recent context' block — that's claude-mem injecting what happened last session. It's also the layer the Sunday weekly-review reads from to summarize your week. If it's silently empty or stale, your reviews summarize nothing — which matters today, with a wall of 🚨 automation failures that the memory layer should be helping you reconstruct.

claude-mem watches your sessions and writes atomic 'observations' — small tagged facts like 🎯 a session start, ✓ a change you made, ● a bugfix, ○ a discovery, ⚖ a decision. Each gets an ID, a timestamp, and a one-line title. Think of it as a flight recorder that runs in the background while you and Claude work.

The value isn't the writing — it's the replay. At the start of a new session it pulls the most relevant recent observations back into context, so Claude knows 'we fixed the relay alert spam yesterday' without you re-explaining. The failure mode is trusting it blindly: it surfaces what it judges relevant, not everything, so for an exhaustive answer you still search explicitly rather than assuming the injected slice is complete.

In your workspace it shows up two ways: the recent-context header at session start (the ID list you saw this morning), and the /mem-search skill for on-demand lookups. The weekly-review SOP leans on it to digest the week — which is why a healthy memory layer is load-bearing, not a novelty.

Worked example

Two ways to pull from memory — the targeted fetch and the semantic search:

# 1. You saw IDs in this morning's context header. Fetch the detail of specific ones:
get_observations(["<id1>", "<id2>"])

# 2. Don't have IDs? Search by meaning, not exact words:
#    invoke the mem-search skill with a question like:
"How did we fix the relay failure-alert spam?"

get_observations takes the short IDs from the recent-context block and returns the full title, type, and body for each — use it when the one-line title isn't enough.
mem-search is semantic: 'relay alert spam' will surface the commit 'gate failure alerts to one 🚨 per outage' even though the words don't match exactly. This is how you answer 'did we already solve this?' before re-solving it.

▶ Do it now

Invoke the mem-search skill and ask it about one real thing from last week — e.g. 'the Cloudflare DO churn fix' or 'TTR design-language lock'.
Confirm it surfaces with a plausible date and the right one-line summary. Note whether the date matches your memory of when it actually happened.
Now the meta-move: search 'automation failures' or 'plan-day failed'. See whether the memory layer has been recording the 🚨 outages clogging your Things list today — if it hasn't, that's itself a signal the capture pipeline is part of what's broken.

Gotchas

Injected context is a relevance-ranked slice, not the full log. For a complete picture, search — don't assume the header showed you everything.
Stale-but-present is the dangerous state: an observation from three weeks ago can read as current if you don't check its timestamp. Always glance at the date.
The memory layer is downstream of the capture process running. If your automation stack is failing (as it is today), don't assume memory is faithfully recording — verify the side-effect, the same rule you apply to every cron job.

Go deeper: claude-mem how-it-works skill

One-card takeaway

Memory is a search index, not an oracle: it makes 'did we already do this?' a 10-second query instead of a re-do — but only if you check the date and search rather than trust the slice.

← Prev Index