How to write effective session memos. Use when: - User invokes /memex:save - User says "save this for later" or "remember this" - User asks to "create a memo" or "document this session" - Manually capturing important decisions or learnings - The [memex] activity nudge appears in context <example> Context: User asks to save current context User: "Can you save what we discussed about the retry pattern?" Assistant: "I'll create a memo capturing the retry pattern discussion." <commentary> Use memo-writing skill to ensure proper format with future context, decisions, tensions, and open threads. </commentary> </example> <example> Context: Activity nudge appears System: "[memex] Substantial session activity detected. Consider /memex:save" Assistant: "We've done substantial work. Let me save a memo before context gets too long." <commentary> When the nudge appears, proactively suggest saving. You have the best context right now. </commentary> </example>
From memexnpx claudepluginhub linxule/memex-plugin --plugin memexThis skill is limited to using the following tools:
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Date: !date +%Y-%m-%d
Project: !basename $(git remote get-url origin 2>/dev/null | sed 's/\.git$//' | xargs basename 2>/dev/null) 2>/dev/null || basename $(pwd)
Topics available for [[wikilinks]]: !ls $(memex path 2>/dev/null)/topics/*.md 2>/dev/null | xargs -I{} basename {} .md | sort | tr '\n' ' ' || echo "(no topics found)"
You were there. A subagent reading the transcript later wasn't. Your memo from full context will always be better than a reconstructed one. Write from experience, not summary.
Capture the journey, not just the destination. Future-Claude needs to understand:
---
type: memo
title: [Specific, searchable title]
project: [project-name] # detected from cwd git root; set explicitly if writing from outside the project
date: [ISO date]
topics:
- topic-name-kebab-case
- another-topic
manual: true # distinguishes manually-written memos from auto-extracted ones
---
# [Title]
## For Future Context
[1-2 sentences: the single most important thing for someone continuing this work]
## Summary
[2-4 sentences: what was the actual work, not "we discussed X" but "we tried Y, discovered Z"]
## What Happened
### Key Decisions
- **[Decision]**: [Why this over alternatives. Note tradeoffs.]
### What Worked / What Didn't
- **Tried**: [Approach that failed or was abandoned] → **Why**: [Reason it failed]
- **Solution**: [What actually worked] → **Insight**: [Why it worked]
### Surprises & Difficulties
- [Unexpectedly hard things, multiple attempts, friction]
- [Surprisingly easy things, or things that solved bigger problems]
### Insights
- [Patterns, gotchas, or principles that transfer to other contexts]
- [Non-obvious discoveries — not "X is complex" but "X fails silently when Y"]
## Perspectives & Tensions
[When user and AI had different takes, or user expressed uncertainty/frustration/changed direction. Preserve quotes when they reveal thinking:]
- **User's priority**: [What the user emphasized or pushed for]
- **AI's approach**: [Where Claude offered alternatives or raised concerns]
- **Resolution**: [How it was decided, or if still open]
[Omit this section entirely if the session was straightforward]
## Open Threads
- [ ] [Concrete next step with enough context to act on]
- [ ] [Unresolved question with why it matters]
- [ ] [Blocked item with what's blocking it]
## Related
- [[existing-topic]]
- [[?suggested-new-concept]]
## Context Signals
- **Difficulty**: [Easy / Moderate / Complex / Grinding]
- **Session character**: [Exploration / Debugging / Implementation / Planning / Discussion]
Always search the vault before writing to find related memos. Run from the vault directory:
memex search "<keywords>" --limit=5
Use results to:
Specific and searchable:
| Bad | Good |
|---|---|
| "Session Notes" | "JWT Token Refresh Bug — Race Condition in Middleware" |
| "Debugging" | "Rate Limiting Fix — Exponential Backoff with Jitter" |
| "Planning" | "Memex Memo Architecture — From API Hooks to Subagents" |
| Session type | Target length |
|---|---|
| Quick fix / simple task | 200-300 words |
| Standard session | 400-800 words |
| Complex multi-thread | 800-1200 words |
| Deep exploration / design session | 1000+ words |
The measure isn't word count — it's "can future-Claude pick up where we left off?"
Specific and actionable:
## Open Threads
- [ ] Test retry logic with network timeout > 30s (currently untested)
- [ ] Decide: RRF k=60 vs k=30 — lower k favors keyword matches
- [ ] Blocked: need LM Studio running to test vector search changes
Not:
- [ ] Think about edge cases
- [ ] Maybe add tests
- [ ] Consider performance
[[topic-name]] — link to existing topic[[projects/myproject/memos/memo-name]] — link to specific memo[[?new-concept]] — suggest concept that doesn't exist yet (prefixed with ?)Use sparingly in memos — the memo format already structures information well. Reserve for critical gotchas or warnings that need to visually stand out:
> [!warning] Token refresh silently fails under load
> The JWT refresh endpoint returns 200 with an expired token when Redis is saturated.
> [!tip] Use `--incremental` not `--full`
> Full rebuild re-embeds everything (~$2). Incremental only processes new/changed docs.
Common types: warning (gotchas), tip (best practices), bug (known issues), question (unresolved). Full reference in skills/garden-tending/references/obsidian-formatting.md.
Before finalizing, ask: