Mem Search
Search claude-mem’s cross-session memory to recall past fixes, decisions, and how work was done before.
Overview
mem-search is an agent skill most often used in Build (also Ship, Operate) that searches claude-mem’s cross-session memory with a filter-first workflow before fetching details.
Install
npx skills add https://github.com/thedotmack/claude-mem --skill mem-searchWhat is this skill?
- Mandatory 3-layer workflow: search index, filter by ID, then fetch details
- Documented ~10x token savings by never fetching full records before filtering
- MCP search with query, limit (default 20, max 100), project, type, obs_type, and date filters
- Index table returns IDs, timestamps, types, and titles before deep reads
- Tuned for previous-session questions, not the current chat transcript
- 3-layer workflow: search, filter, fetch
- Search limit default 20, maximum 100 results per call
- Documented ~10x token savings vs fetching full details without filtering
Adoption & trust: 3.9k installs on skills.sh; 81.2k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You cannot remember how a problem was solved or what was decided in an earlier agent session across days or projects.
Who is it for?
Builders running claude-mem who need fast recall of prior bugfixes, features, and decisions across projects and dates.
Skip if: Questions answerable from the current conversation only, or teams without claude-mem MCP search wired up.
When should I use this skill?
User asks did we already solve this, how did we do X last time, what happened last week, or needs work from previous sessions—not the current conversation.
What do I get? / Deliverables
You get a filtered index of past observations and sessions, then load only the matching memory records instead of dumping full history into context.
- Filtered memory index table with IDs and titles
- Fetched observation or session detail for selected IDs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Persistent memory retrieval is core agent tooling during implementation, but the same workflow applies whenever you need prior session context. mem-search is the MCP-facing search layer for the claude-mem stack, not a product feature or deploy step.
Where it fits
Before re-adding JWT middleware, search claude-mem for prior auth observations in the same repo.
During review, confirm whether a reported defect already has a documented bugfix observation from last week.
When production behavior regresses, pull the last change-type memory entries for the affected module.
Recall how a data migration or API contract decision was recorded before extending the same service.
How it compares
Use structured memory search with ID filtering instead of re-prompting or pasting old chat logs into context.
Common Questions / FAQ
Who is mem-search for?
Claude users with claude-mem installed who want cross-session recall for bugs, features, and decisions without reloading entire past chats.
When should I use mem-search?
Use during Build when re-implementing a pattern, during Ship review when checking if a fix already landed, or during Operate iterate when diagnosing regressions—whenever the question is about previous sessions, not the live thread.
Is mem-search safe to install?
It reads your local or project-scoped memory store via MCP; review the Security Audits panel on this page and scope project filters so sensitive observations are not over-shared in shared repos.
SKILL.md
READMESKILL.md - Mem Search
# Memory Search Search past work across all sessions. Simple workflow: search -> filter -> fetch. ## When to Use Use when users ask about PREVIOUS sessions (not current conversation): - "Did we already fix this?" - "How did we solve X last time?" - "What happened last week?" ## 3-Layer Workflow (ALWAYS Follow) **NEVER fetch full details without filtering first. 10x token savings.** ### Step 1: Search - Get Index with IDs Use the `search` MCP tool: ``` search(query="authentication", limit=20, project="my-project") ``` **Returns:** Table with IDs, timestamps, types, titles (~50-100 tokens/result) ``` | ID | Time | T | Title | Read | |----|------|---|-------|------| | #11131 | 3:48 PM | 🟣 | Added JWT authentication | ~75 | | #10942 | 2:15 PM | 🔴 | Fixed auth token expiration | ~50 | ``` **Parameters:** - `query` (string) - Search term - `limit` (number) - Max results, default 20, max 100 - `project` (string) - Project name filter - `type` (string, optional) - "observations", "sessions", or "prompts" - `obs_type` (string, optional) - Comma-separated: bugfix, feature, decision, discovery, change - `dateStart` (string, optional) - YYYY-MM-DD or epoch ms - `dateEnd` (string, optional) - YYYY-MM-DD or epoch ms - `offset` (number, optional) - Skip N results - `orderBy` (string, optional) - "date_desc" (default), "date_asc", "relevance" ### Step 2: Timeline - Get Context Around Interesting Results Use the `timeline` MCP tool: ``` timeline(anchor=11131, depth_before=3, depth_after=3, project="my-project") ``` Or find anchor automatically from query: ``` timeline(query="authentication", depth_before=3, depth_after=3, project="my-project") ``` **Returns:** `depth_before + 1 + depth_after` items in chronological order with observations, sessions, and prompts interleaved around the anchor. **Parameters:** - `anchor` (number, optional) - Observation ID to center around - `query` (string, optional) - Find anchor automatically if anchor not provided - `depth_before` (number, optional) - Items before anchor, default 5, max 20 - `depth_after` (number, optional) - Items after anchor, default 5, max 20 - `project` (string) - Project name filter ### Step 3: Fetch - Get Full Details ONLY for Filtered IDs Review titles from Step 1 and context from Step 2. Pick relevant IDs. Discard the rest. Use the `get_observations` MCP tool: ``` get_observations(ids=[11131, 10942]) ``` **ALWAYS use `get_observations` for 2+ observations - single request vs N requests.** **Parameters:** - `ids` (array of numbers, required) - Observation IDs to fetch - `orderBy` (string, optional) - "date_desc" (default), "date_asc" - `limit` (number, optional) - Max observations to return - `project` (string, optional) - Project name filter **Returns:** Complete observation objects with title, subtitle, narrative, facts, concepts, files (~500-1000 tokens each) ## Examples **Find recent bug fixes:** ``` search(query="bug", type="observations", obs_type="bugfix", limit=20, project="my-project") ``` **Find what happened last week:** ``` search(type="observations", dateStart="2025-11-11", limit=20, project="my-project") ``` **Understand context around a discovery:** ``` timeline(anchor=11131, depth_before=5, depth_after=5, project="my-project") ``` **Batch fetch details:** ``` get_observations(ids=[11131, 10942, 10855], orderBy="date_desc") ``` ## Why This Workflow? - **Search index:** ~50-100 tokens per result - **Full observation:** ~500-1000 tokens each - **Batch fetch:** 1 HTTP request vs N individual requests - **10x token savings** by filtering before fetching ## Knowledge Agents Want synthesized answers instead of raw records? Use `/knowledge-agent` to build a queryable corpus from your observation history. The knowledge a