Capture the current state of a working thread or conversation into a single coherent Basic Memory note — synthesize where it landed, don't append a log. On re-capture, rewrite the same note in place instead of duplicating. Use mid-thread or end-of-thread when decisions, insights, or context are wort

Memory Capture Capture the gist of a working thread — the decisions made, insights surfaced, and context built — into a single coherent Basic Memory note that reflects where the thread has landed. Purpose A thread has a beginning, middle, and end. Things change as the conversation progresses: an early decision gets revised, a problem looks different in light of new information, a trade off is settled differently than it first seemed. When this skill is invoked, capture the current state of understanding , not the history of how it got there. If the skill is invoked more than once in the same thread, the same note is rewritten so it stays coherent — not appended to. The result should read top to bottom as a single document about the thread's outcome, with brief prose where a meaningful change is worth acknowledging. When to Use Typical timing is mid thread or end of thread , after enough has been settled to be worth preserving. Use this skill when: Key decisions have been made and shouldn't evaporate when the thread closes A design, debugging, or planning discussion has produced something concrete The user explicitly asks to capture, save, or remember what's been discussed Toward the end of a session, to summarize the outcome It is fine — and expected — to invoke this skill multiple times in the same thread as the conversation evolves. Same Thread Detection To rewrite the same note on re capture instead of duplicating, key the note to a stable thread id in its frontmatter. If your agent exposes a stable session or thread id , store it as thread id so subsequent captures within the same thread find and rewrite the same note. Any value that stays constant for the duration of the thread works — a session UUID, a conversation id, a ticket number the work is scoped to. Example (hosts with a JSONL transcript): some agents write a per session transcript whose filename is a stable session UUID. If yours does, you can derive the id from the most recently modified transcript file and use it as thread id . This is optional — only do it if your host actually exposes such a transcript. If no stable id is available , match the existing note by title/topic instead: search for a note covering the same thread ( search notes(query="<topic ") ), and if you find the one this thread already produced, rewrite it. Omit thread id and rely on a consistent title. Decision Flow 1. Determine the thread key. Use a stable session/thread id if your agent exposes one; otherwise plan to match by title/topic. 2. Search Basic Memory for the existing thread note. With a thread id, use metadata filters (not query ) — full text query doesn't reliably match YAML frontmatter custom fields: Without one, search by topic and identify the note this thread already produced: 3. If a match is found: Read the existing note (use the full permalink returned by search) Synthesize a new version that integrates the latest understanding from the conversation Overwrite via write note with overwrite=True (same title, same thread id if used, same directory) 4. If no match is found: Synthesize the note from the conversation If you have a thread id, pass metadata={"thread id": "<thread id "} to write note (it surfaces as a custom frontmatter field) Save it Synthesis Rules When updating an existing thread note, synthesize, don't append : Decisions that are still current → keep, possibly refined Decisions that have been superseded → replaced inline (the new one goes where the old one was) Significant revisions that deserve explanation → a sentence woven into the relevant section, not an appended changelog Outdated context → removed Goal: the note reads top to bottom as a single coherent document. A reader who never saw the conversation should still understand the outcome from the note alone. There is no Changes section at the bottom; revisions live in the prose where they're relevant. Escape Hatch If the user explicitly asks for a separate note (e.g., "capture this as a new note, don't merge with the existing thread note"), skip the same thread lookup and create a fresh note without setting thread id . This is rare; the default is to update. Note Structure Common Observation Categories [decision] — choices made [insight] — understanding gained [pattern] — reusable approaches [learning] — lessons learned [tradeoff] — options weighed [problem] — issues identified [solution] — fixes applied Title The title should reflect the thread's topic. On update, the title can be refined if the topic has clarified — but it should still describe the same thread. Don't drift to a wholly new topic; if that's needed, use the escape hatch and create a new note. MCP Tools Used Examples Example 1 — First capture during a brand design conversation Preceding conversation: The user has been working through visual identity decisions for a new product. They settled on a deep navy primary ( 2B3651 ), explored accent options and chose orange ( F26B3A ) for warmth, and picked Inter as the body font with Helvetica Neue as the display font. User asks to capture. Result — note created: Example 2 — Update capture later in the same thread Preceding conversation (continued): After the initial decisions above, the conversation continued. The orange accent felt too aggressive in mock ups, so we tested a coral ( E89B7A ) which read warmer and more refined. The body font also shifted: Geist felt slightly tighter and more modern than Inter. Helvetica Neue for display stayed. User asks to capture again — same thread. Result — same note rewritten (note the same thread id ): Notice that: The orange and Inter decisions are no longer the primary content — they're acknowledged in prose ("which we tried first," "originally chosen orange") and in tradeoff observations There is no "Changes" section at the bottom — revisions are integrated where they belong The note still reads top to bottom as a single coherent document The thread id is unchanged, so the note was updated in place rather than duplicated Best Practices 1. Capture the current state, not the history. The note represents where the thread has landed. 2. Synthesize, don't log. Each invocation produces a coherent document, not an accumulating record. 3. Brief prose for revisions. A sentence in the section that changed is enough — don't add a changelog. 4. Always run the same thread lookup before deciding to create or update. 5. Use observations for the structured layer. Decisions, insights, tradeoffs go in Observations so they're searchable. 6. Link relations liberally. Notes the user might want to reach from this one.

memory-capture