/memex-retro

name: memex-retro
description: Save insights from completed tasks to Zettelkasten memory.
whenToUse: After completing any task involving code changes, architectural decisions, debugging, or non-trivial problem solving. Distill what you learned into atomic memory cards so future sessions can benefit. Invoke proactively at task end — do not wait for the user to ask.

Memory Retro

You have access to a Zettelkasten memory system via the `memex` CLI. After completing this task, reflect on what you learned and save valuable insights.

Tools Available

Three equivalent interfaces — use whichever your environment supports:

| CLI (memex in PATH) | Plugin CLI fallback (Claude Code) | MCP tool (VSCode / Cursor) | |----------------------|-----------------------------------|----------------------------| | `memex search <q>` | `node ~/.claude/plugins/cache/cc-plugins/memex/*/dist/cli.js search <q>` | `memex_search` with query arg | | `memex read <slug>` | `node ~/.claude/plugins/cache/cc-plugins/memex/*/dist/cli.js read <slug>` | `memex_read` with slug arg | | `memex write <slug>` | `node ~/.claude/plugins/cache/cc-plugins/memex/*/dist/cli.js write <slug>` | `memex_write` with slug arg and body |

**Resolution order:** Try `memex` in PATH first. If not found, define a shell function and use it:

# Define once per session — DO NOT use variable assignment ($VAR won't expand correctly in zsh)
memex() { node $HOME/.claude/plugins/cache/cc-plugins/memex/*/dist/cli.js "$@"; }

# Then use normally
memex search "some query"
memex read some-slug
memex write some-slug << 'EOF'
card content here
EOF

If both CLI approaches fail, use MCP tools (`memex_search`, `memex_read`, `memex_write`).

The rest of this skill uses `memex` CLI syntax for brevity.

Process

digraph retro {
    "Task completed" -> "Distill: what insights came from this task?";
    "Distill: what insights came from this task?" -> "Any insights worth keeping?" [shape=diamond];
    "Any insights worth keeping?" -> "Done, no card written" [label="no"];
    "Any insights worth keeping?" -> "For each insight: draft atomic card" [label="yes"];
    "For each insight: draft atomic card" -> "Fact Hygiene Check (WHO/WHAT-WHEN/RELATIONSHIP)";
    "Fact Hygiene Check (WHO/WHAT-WHEN/RELATIONSHIP)" -> "Ambiguity found?" [shape=diamond];
    "Ambiguity found?" -> "Fix draft: make implicit context explicit" [label="yes"];
    "Fix draft: make implicit context explicit" -> "Fact Hygiene Check (WHO/WHAT-WHEN/RELATIONSHIP)";
    "Ambiguity found?" -> "memex search for related existing cards" [label="no"];
    "memex search for related existing cards" -> "memex read candidates";
    "memex read candidates" -> "Existing card covers same insight?" [shape=diamond];
    "Existing card covers same insight?" -> "Update existing card (append new info)" [label="yes"];
    "Existing card covers same insight?" -> "Write new card with [[links]]" [label="no"];
    "Update existing card (append new info)" -> "memex write <existing-card>";
    "Write new card with [[links]]" -> "memex write <new-card>";
    "memex write <existing-card>" -> "More insights?" [shape=diamond];
    "memex write <new-card>" -> "More insights?" [shape=diamond];
    "More insights?" -> "For each insight: draft atomic card" [label="yes"];
    "More insights?" -> "Done" [label="no"];
}

1. Ask yourself: what did I learn from this task that would be useful in the future? 2. If nothing worth remembering, skip — not every task produces insights 3. For each insight, draft an **atomic card** (one insight per card) 4. **Fact Hygiene Check** — before writing, scan the draft for implicit context that a stranger (or future AI) couldn't decode. Ask three questions:

• **WHO**: Every project/product/team mentioned — is it the user's own work or external? Would a reader with zero context know?
• **WHAT-WHEN**: Every number (days, tokens, cost) — is it bound to a specific project name and time period?
• **RELATIONSHIP**: Words like "对标/参照/基于/借鉴/reference" — spell out the actual relationship (authored, benchmarked against, forked from, inspired by, etc.)
• If any answer is "a stranger couldn't tell", **fix the draft before writing**. One sentence of context prevents hallucinated narratives downstream.

5. Before writing, `memex search` for related existing cards 6. **Dedup check**: If an existing card already covers this insight, `memex read` it, then update it by appending new information (use `memex write` with the full updated content) 7. If it's genuinely new, write a new card with `[[links]]` to related cards in the prose

Card Format

---
title: <descriptive title>
created: <today's date YYYY-MM-DD>
source: <auto-filled by client>
category: <optional category>
---

<One atomic insight, written in your own words.>

<Natural language sentences with [[links]] to related cards, explaining WHY they're related.>

Note: You do NOT need to include `modified` — the CLI auto-sets it on write.

Rules

• **Atomic**: One insight per card. If you have 3 insights, write 3 cards.
• **Own words**: Don't copy-paste. Distill and rephrase — this is the Feynman method.
• **Link in context**: `[[links]]` must be embedded in sentences that explain the relationship.
• Good: "This contradicts what we found in [[jwt-migration]] — stateless tokens can't be revoked."
• Bad: "Related: [[jwt-migration]]"
• **Slug**: English kebab-case, descriptive. e.g., `jwt-revocation-blacklist-pattern`
• **Don't over-record**: Only save insights that would change how you approach a similar task in the future.
• **Preserve frontmatter on update**: When updating an existing card, preserve its original frontmatter fields (title, created). Only append to the body. `source` is auto-managed by the MCP server.
• **No raw secrets**: Never write actual secrets, credentials, tokens, or exact secret file contents into memory. Use redacted examples and abstract descriptions instead.

Exte