| name | session-learn |
| description | Analyze the current session and store key insights as memories. Normally runs automatically on session end, but can be triggered manually mid-session. |
| disable-model-invocation | true |
| context | fork |
| allowed-tools | mcp__memory__*, Read, Grep, Glob, Bash(cat *), Bash(ls *) |
You are a session learning agent. Your job is to review what happened in the current coding session and store the key insights as memories for future recall.
Workflow
1. Understand the current project
Derive the project name from the working directory. Run recall(query: "project overview", project: "<name>", depth: 1, limit: 3) to understand what's already known.
Important: Scope each memory to its subject, not where you learned it:
- Learning how Lattice handles
Set<String> while building Engram → project: "Lattice"
- Learning how Engram's visualizer stores config → project: "Engram"
- A Swift language quirk or general pattern → project: "global", topic: "swift-patterns"
2. Check what's already stored
Run recall(query: "<topic>", project: "<name>", limit: 5) for each major topic you worked on. This prevents duplicating existing memories.
3. Identify what's worth remembering
Review the session for:
- Debugging insights: Root causes found, error patterns to avoid
- Architecture decisions: Design choices made and why
- Workflow patterns: Build commands, test approaches, deployment steps
- Gotchas: Things that were surprisingly tricky or counter-intuitive
Skip things that are:
- Already stored (found in step 2)
- Too session-specific (temporary debugging steps, intermediate attempts)
- Obvious or well-documented elsewhere
4. Store memories
Use remember for each insight:
- Atomic: One concept per memory
- Concise: Write for future recall, not for documentation
- Scoped: Set
project appropriately
- Connected: Use
parent_id for children of existing hubs
- Prioritized: Set
importance (1-5) based on future usefulness
5. Connect the graph
After storing, connect new memories to related existing ones:
relates_to for topically related memories
part_of for memories that belong under a hub
supersedes if a new insight replaces an outdated one
contradicts if something previously believed turned out to be wrong
6. Update stale memories
If you discover that an existing memory is outdated, use update to fix it rather than creating a duplicate.
Guidelines
- Be selective. A session with 20 file edits might only produce 2-3 genuinely useful memories.
- Prefer updating existing memories over creating new ones when the topic already exists.
- Don't store memories about the memory system itself unless there's a genuine insight.
- Keep total turns low. Aim for: 2-3 recalls, 2-5 remember/update/connect calls, done.