| name | memory |
| description | Manage the auto-memory system for this project. Search, audit, prune, and create memories with proper frontmatter. Use when you need to find a past decision, check if memories are stale, clean up duplicates, add a new memory, or understand what context is available. Triggers on: "check memory", "what do we remember about", "find the memory about", "clean up memories", "audit memories", "add to memory", "is there a memory for".
|
Memory Management
Manage the auto-memory system for the Ambient Code Platform project.
Usage
/memory # Show summary of all memories
/memory search <query> # Search for a topic
/memory audit # Check for stale/duplicate memories
/memory prune # Remove stale memories (with confirmation)
/memory add <topic> # Create a new memory
User Input
$ARGUMENTS
Parse the subcommand from $ARGUMENTS. Default to summary if empty.
Memory Location
All memory files live at:
$HOME/.claude/projects/<project-slug>/memory/
Use the active project's slug (the repo path with / replaced by -).
The index file is MEMORY.md in that directory.
Subcommands
/memory — Summary
- Read
MEMORY.md to get the index
- Count total memories by type (user, feedback, project, reference)
- List the most recently modified files
- Report: total count, breakdown by type, last modified dates
/memory search <query>
- Read
MEMORY.md for the index
- Grep through all memory files for the query term
- Read matching files and show relevant excerpts
- Report: matching files with frontmatter (name, type, description)
/memory audit
Check for quality issues:
- Stale memories — project/reference memories older than 3 months may be outdated
- Duplicate memories — similar names or descriptions across files
- Missing frontmatter — files without proper
name, description, type fields
- Orphaned files — memory files not referenced in
MEMORY.md
- Broken links —
MEMORY.md entries pointing to nonexistent files
- Oversized index —
MEMORY.md approaching the 200-line truncation limit
Report each issue with the file path and suggested action.
/memory prune
- Run the audit checks
- Present findings to the user
- For each stale/duplicate/orphaned memory, ask: keep, update, or delete?
- Execute confirmed deletions
- Update
MEMORY.md index accordingly
Never delete without explicit confirmation.
/memory add <topic>
- Ask the user what they want to remember (if not clear from context)
- Determine the memory type (user, feedback, project, reference)
- Create a new file with proper frontmatter:
---
name: <descriptive name>
description: <one-line description for relevance matching>
type: <user|feedback|project|reference>
---
<memory content>
- Add an entry to
MEMORY.md
- Verify the entry was added correctly
Memory Types
| Type | What to store | When to save |
|---|
| user | Role, preferences, knowledge | Learning about the user |
| feedback | Corrections, validated approaches | User corrects or confirms approach |
| project | Decisions, initiatives, deadlines | Learning project context |
| reference | Pointers to external systems | Discovering external resources |
What NOT to Store
- Code patterns derivable from reading current code
- Git history (use
git log)
- Debugging solutions (the fix is in the code)
- Anything in CLAUDE.md
- Ephemeral task details
- Secrets or credentials (API keys, tokens, passwords, private keys, OAuth secrets)
- Sensitive personal data unless explicitly required
Quality Guidelines
- Keep
MEMORY.md under 200 lines (truncation risk)
- Each entry: one line, under 150 characters
- Update existing memories rather than creating duplicates
- Include absolute dates (not "next Thursday")
- For feedback/project types: include Why: and How to apply: lines
