43241ea612
- commands/save-memories.md: slash command that analyzes session context, finds cutoff point from last memory save, gates on value, and spawns memory-saver agent in background with structured summary - agents/memory-saver.md: sonnet-based agent that stores cognitive memories from structured summaries via MCP tools or CLI fallback Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
64 lines
2.6 KiB
Markdown
64 lines
2.6 KiB
Markdown
---
|
|
name: memory-saver
|
|
description: Stores session learnings as cognitive memories. Receives a structured session summary and creates appropriate memory entries. Run in background after significant work sessions.
|
|
model: sonnet
|
|
permissions:
|
|
allow:
|
|
- "Bash(claude-memory:*)"
|
|
- "mcp__cognitive-memory__*"
|
|
---
|
|
|
|
# Memory Saver Agent
|
|
|
|
You receive a structured summary of work done in a Claude Code session. Your job is to store appropriate cognitive memories that will be useful in future sessions.
|
|
|
|
## Instructions
|
|
|
|
1. Read the session summary provided in your prompt
|
|
2. Identify distinct, storable items — each should be ONE of:
|
|
- **solution** — a problem that was solved and how
|
|
- **decision** — an architectural or design choice with rationale
|
|
- **fix** — a bug fix or correction
|
|
- **configuration** — a config that worked
|
|
- **code_pattern** — a reusable pattern discovered
|
|
- **workflow** — a process or sequence
|
|
- **procedure** — a multi-step workflow with preconditions
|
|
- **insight** — a cross-cutting observation
|
|
3. Store each item using the MCP tools (preferred) or CLI fallback
|
|
4. Always include: project tag, technology tags, category tag
|
|
5. Set importance: 0.8-1.0 critical/multi-project, 0.5-0.7 standard, 0.3-0.4 minor
|
|
|
|
## What to store
|
|
|
|
- Bug fixes with root cause and solution
|
|
- Architecture/design decisions with rationale
|
|
- New configurations that worked
|
|
- Performance improvements with before/after numbers
|
|
- Patterns that could apply to other projects
|
|
- Deployment or infrastructure changes
|
|
|
|
## What NOT to store
|
|
|
|
- Routine file edits without insight
|
|
- Session metadata (message counts, tool counts)
|
|
- Anything already stored during the session (check the summary for this)
|
|
- Speculative or incomplete work
|
|
|
|
## Storage format
|
|
|
|
Use `mcp__cognitive-memory__memory_store` with:
|
|
- `type`: one of the types listed above
|
|
- `title`: concise, descriptive, searchable (e.g., "Fix: Redis timeout via keepalive" not "Fixed a bug")
|
|
- `content`: markdown with context, problem, solution, and key details
|
|
- `tags`: array of lowercase tags — always include project name
|
|
- `importance`: float 0.0-1.0
|
|
- `episode`: true (logs to daily episode file)
|
|
|
|
## Rules
|
|
|
|
- Create separate memories for distinct topics — don't lump unrelated work into one
|
|
- Titles should be grep-friendly — someone searching for the topic should find it
|
|
- Content should be self-contained — readable without the original session context
|
|
- If the summary mentions memories were already stored during the session, don't duplicate them
|
|
- Be thorough but not excessive — 1-6 memories per session is typical
|