EXAMPLES.md
# recap worked examples
## 1. This week
User: "Recap this week."
Window: last 7 days. Invocation:
```json
memory_sessions { "project": "app", "limit": 30 }
```
Response (after filtering to cwd and the 7-day window):
```json
{
"sessions": [
{ "id": "7f3a9c21", "cwd": "/Users/dev/app", "title": "Auth refresh rework",
"startedAt": "2026-06-07T09:00:00Z", "observationCount": 14, "status": "completed",
"concepts": ["jwt-refresh-rotation", "auth-flow"] },
{ "id": "b21d004e", "cwd": "/Users/dev/app", "title": "Rate limiter audit",
"startedAt": "2026-06-05T14:00:00Z", "observationCount": 9, "status": "completed",
"concepts": ["rate-limiter", "per-ip-bug"] }
]
}
```
Per session, pull highlights:
```json
memory_recall { "query": "jwt-refresh-rotation auth-flow", "project": "app", "limit": 3 }
```
Present:
> **2026-06-07**
> - `7f3a9c2` Auth refresh rework, 14 obs, completed
> - [8] Rotate refresh tokens on every use
>
> **2026-06-05**
> - `b21d004e` Rate limiter audit, 9 obs, completed
> - [7] limit.ts counts per-IP, not per-user
>
> 2 sessions across 2 days, 23 observations.
## 2. Bare number
User: "recap 3"
Treat as `last 3`. Call `memory_sessions { "project": "app", "limit": 3 }`
using the recorded project identifier, then group by date. If the identifier is
unknown, page through results and filter by directory before selecting three.
## 3. Empty window
User: "Recap today."
If `memory_sessions` returns no session whose `startedAt` is today and whose
`cwd` matches:
> No sessions today for this project. The most recent was yesterday, `7f3a9c2`
> Auth refresh rework. Want a recap of that instead?
SKILL.md
---
name: recap
description: Summarize the last N agent sessions for the current project, grouped by date, with highlight observations per session. Use when the user asks "recap", "what have we been doing", "today", "this week", or wants a rollup of recent work.
argument-hint: "[last N | today | this week]"
user-invocable: true
---
The user wants a recap. Time window args: $ARGUMENTS
## Quick start
```json
memory_sessions { "project": "<current-project-id>", "limit": 30 }
```
Then per surviving session: `memory_recall { "query": "<top concepts>", "project": "<current-project-id>", "limit": 3 }`.
When an agent is requested, pass the same `agentId` to both calls.
Expected output:
```text
2026-06-07
7f3a9c2 · "Auth refresh rework" · 14 obs · completed
- [8] Rotate refresh tokens on every use
3 sessions across 2 days, 41 observations.
```
## Why
Only summarize sessions and observations the tools returned. An empty window is
a real answer, not a prompt to invent activity.
## Workflow
1. Parse `$ARGUMENTS`: `today` = current local date; `this week` = last 7 days;
`last <n>` or bare numeric = most recent N; empty = `last 10`.
2. Call `memory_sessions` with the exact recorded project identifier when known
and the requested `agentId`. Follow `nextCursor` with the same filters until
the requested window is covered or pages end. When the project identifier is
unknown, match normalized `cwd` by directory boundary across pages before
applying the time/count window. Sort by `startedAt` descending.
3. Group survivors by local calendar date (YYYY-MM-DD).
4. Per session list id (first 8), title or first prompt, observation count,
status. Obtain highlights with `memory_recall`, retaining project/agent scope,
and verify each result belongs to that session before including it.
5. End with "N sessions across M days, K observations."
## Anti-patterns
WRONG: window is empty, so you summarize "a productive week of auth work" from
memory of the conversation.
RIGHT: "No sessions in the last 7 days for this project."
## Checklist
- Window parsed correctly from the argument.
- Sessions filtered to the current project's cwd.
- Highlights come from `memory_recall`, not paraphrase.
- Totals line reflects the actual counts shown.
## See also
- `handoff`, `session-history`, `recall`: same session data, different lens.
## Troubleshooting
See [TROUBLESHOOTING.md](TROUBLESHOOTING.md) if `memory_sessions` or `memory_recall` is not available.
TROUBLESHOOTING.md
<!-- AUTOGEN:troubleshooting START - generated by scripts/skills/generate.ts, do not edit by hand -->
# Troubleshooting agentmemory skills
Recovery steps for separately installed skills. This document is generated into
each skill directory so native skill readers can open it without parent traversal.
## "MCP tool not available"
Missing tools can mean a stopped MCP process, a disconnected daemon, or an
explicitly reduced tool surface. Walk these in order:
1. Identify the host. In Claude Code, inspect `/plugin list` and `/mcp`.
In Hermes, inspect the configured memory provider and `mcp_servers` separately.
In OpenClaw, validate the host configuration and inspect its MCP servers and
native plugins separately. In Pi or OMP, inspect `/agentmemory-status` and the
MCP inventory separately; native save/search does not prove the broader tools
are connected. Do not run another host's setup commands.
2. Restart or reload the affected host connection after configuration changes.
3. Inspect the connected tool inventory. Hermes may namespace MCP tools; invoke
the actual advertised names and schemas. A native memory provider is not
proof that every MCP tool or shared skill is available.
4. Check `agentmemory status` and the daemon's `AGENTMEMORY_TOOLS` setting.
Codex's bundled bridge lists the daemon's enabled tools. The standalone shim
used by other hosts can fall back to seven basic tools with a separate store.
Do not claim full daemon functionality based on those seven tools.
5. If `agentmemory connect codex` and the Codex plugin are both enabled, choose
one MCP connection. Check `/hooks` before adding global hook fallbacks.
Hermes, OpenClaw, Pi and OMP connector installations bundle skills; other hosts
may install them separately. Check the host's skill inventory and open this file
from the installed skill directory. Test automatic capture with a real turn and
a recorded observation; tool connectivity alone does not establish lifecycle
capture.
An outage or timeout is not an empty search result. Report the failure. A write
may have committed before the response was lost; inspect state before retrying.
## REST fallback
When the MCP tools stay unavailable but the daemon is running, call the REST
API directly:
1. Set `AGENTMEMORY_URL` to the daemon base URL (default `http://localhost:3111`).
2. The REST API requires a bearer credential by default. Use the host's explicit
`AGENTMEMORY_SECRET`; for loopback URLs only, fall back to the secret in
`~/.agentmemory/.env` and then `~/.agentmemory/secret`. Load the value locally
without displaying it. Never send a local-file secret to a remote URL.
If `AGENTMEMORY_CREDENTIAL_MODE=explicit`, require the explicit host credential
and do not read local credential files.
Authenticated REST fallback requests require HTTPS for non-loopback
URLs; HTTP is allowed for loopback URLs (`localhost`, `127.0.0.0/8`, or `[::1]`).
Reject redirects on authenticated requests. Do not print or save the secret.
Endpoint map by skill:
| Skill | REST call |
| --------------- | --------------------------------------------------------------- |
| remember | `POST /agentmemory/remember` |
| recall | `POST /agentmemory/smart-search` |
| recap | `GET /agentmemory/sessions` + `POST /agentmemory/smart-search` |
| handoff | `GET /agentmemory/sessions` + `POST /agentmemory/smart-search` |
| session-history | `GET /agentmemory/sessions` |
| commit-context | `GET /agentmemory/session/by-commit?sha=<sha>` |
| commit-history | `GET /agentmemory/commits` (URL-encode every query param) |
The MCP host reads the plugin MCP configuration. Restart the daemon after
changing its configuration, then restart or reconnect the host MCP process after
changing its URL or explicit secret. The local bridge reads the credential files
for each request; it does not inherit other daemon `.env` settings.
<!-- AUTOGEN:troubleshooting END -->