M0 Remember

---
name: m0-remember
description: "Use when the user says 'm0 remember', 'record what we did', 'note for next session' or 'write a checkpoint', or after finishing a step worth handing to the next session. Appends one idempotent entry to the M0 thread."
---

# /m0-remember — Write to the Operational Thread

The write path for M0. One call appends one entry to the shared thread for a
project. Writing the same content twice creates one row, so this is safe to call
after every step and safe to retry.

## Quick Reference

```bash
M0="${M0_BASE_URL:-http://127.0.0.1:8787}"
M0S="$HOME/.claude/skills/m0/scripts"

# Over HTTP
curl -s -X POST "$M0/api/brain/checkpoint" \
  -H 'Content-Type: application/json' \
  -d '{"project":"acme-web","kind":"step_done",
       "text":"Fixed the token refresh race in the auth middleware.",
       "next_step":"Add a regression test for two concurrent refreshes.",
       "last_verified":"pytest tests/auth -q: 31 passed",
       "source_tool":"claude-code","meta_json":{"pr":42}}'
# {"id":"9a71de71…","ts":"2026-08-01T13:31:26.536Z","ok":true,"deferred":false}

# Without a server (same store, same guarantees)
python3 "$M0S/m0_server.py" write \
  --project acme-web --kind step_done \
  --text "Fixed the token refresh race in the auth middleware." \
  --next-step "Add a regression test for two concurrent refreshes." \
  --last-verified "pytest tests/auth -q: 31 passed" \
  --source-tool claude-code --meta '{"pr":42}'
```

If the MCP tools are wired (`/m0 mcp`), call `m0_remember` directly instead — same
endpoint, fewer moving parts, and `meta` takes a real JSON object.

## Fields

| Field | Required | What to put in it |
|-------|----------|-------------------|
| `project` | yes | The project key. Use one stable value per project — the repository or directory name is the usual choice. Getting this wrong splits the thread. |
| `text` | yes | What happened, in one or two plain sentences. Written for a reader with no other context. |
| `kind` | no | Defaults to `step_done`. See the table below. |
| `next_step` | no | The single next action. Concrete enough to act on without re-deriving it. |
| `last_verified` | no | What was actually checked, and how. A command and its result, not an impression. |
| `meta_json` | no | Structured metadata as a JSON object, e.g. `{"pr":42,"tests":"green"}`. |
| `session_id` | no | Session identifier, when known. |
| `source_tool` | no | Which tool is writing. Fill it in — it is what makes the thread legible across tools. |
| `branch`, `head_sha` | no | Version-control position. Worth including whenever the entry is about code. |

Kinds:

| `kind` | Use it for |
|--------|-----------|
| `step_done` | A completed step, a fact, or a decision. The default. |
| `compact_checkpoint` | A session handoff — see `/m0-handoff`. |
| `session_end` | A session closing, usually from a hook. |
| `lane_dispatched` | Work handed to a subagent or parallel lane. |
| `lane_result` | The outcome of that work. |
| `ambient_signal` | Context observed rather than reported. |

An unknown `kind` is rejected with HTTP 400, deliberately: a typo would create a
category no reader looks in.

## Procedure

1. **Resolve the project key.** Use `$M0_PROJECT` if set, otherwise the repository
   or directory name. Reuse whatever earlier entries used — check with
   `/m0-recall` if unsure. Do not invent a variant.
2. **Write one entry per meaningful thing.** A step that landed, a decision with
   its reason, a verification result. Not a running commentary.
3. **Include version-control context** when the entry is about code:

   ```bash
   BRANCH="$(git rev-parse --abbrev-ref HEAD 2>/dev/null)"
   SHA="$(git rev-parse --short HEAD 2>/dev/null)"
   ```
4. **Be honest in `last_verified`.** Put the command and its actual result there.
   If nothing was verified, leave it empty. A false verification claim in a
   memory store outlives the session that made it and misleads every later reader.
5. **Check the response.** `{"ok":true,"deferred":false}` means it is durable.
   `"deferred":true` means the store was busy and the entry is spooled to a
   sidecar file — it is not lost and lands on the next drain or server start. Say
   so rather than reporting a clean write.

## Good and bad entries

```
text:          "Fixed the token refresh race in the auth middleware: the retry
                path double-incremented the nonce."
next_step:     "Add a regression test for two concurrent refreshes."
last_verified: "pytest tests/auth -q: 31 passed"
```

```
text:          "Made some progress on auth."          # nothing to act on
next_step:     "Continue."                            # not a next step
last_verified: "Tests should pass now."               # a claim, not a check
```

## Notes

- **Idempotent.** `id` is a SHA-256 of the content fields, `ts` excluded. Re-writing
  identical content returns the identical response and leaves one row. Retry
  freely.
- **Metadata is lenient.** An object, a JSON string, or free text all work: a JSON
  string is parsed and canonicalised, anything else is stored as `{"note": "…"}`.
  It never rejects what it could have kept.
- **Local-only.** SQLite on disk, loopback server, no outbound calls, no telemetry.
- **Reading back:** `/m0-recall`. **Handoffs:** `/m0-handoff`. **Plumbing:** `/m0`.