memory

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

1. Read MEMORY.md to get the index
2. Count total memories by type (user, feedback, project, reference)
3. List the most recently modified files
4. Report: total count, breakdown by type, last modified dates

/memory search <query>

1. Read MEMORY.md for the index
2. Grep through all memory files for the query term
3. Read matching files and show relevant excerpts
4. Report: matching files with frontmatter (name, type, description)

/memory audit

Check for quality issues:

1. Stale memories — project/reference memories older than 3 months may be outdated
2. Duplicate memories — similar names or descriptions across files
3. Missing frontmatter — files without proper name, description, type fields
4. Orphaned files — memory files not referenced in MEMORY.md
5. Broken links — MEMORY.md entries pointing to nonexistent files
6. Oversized index — MEMORY.md approaching the 200-line truncation limit

Report each issue with the file path and suggested action.

/memory prune

1. Run the audit checks
2. Present findings to the user
3. For each stale/duplicate/orphaned memory, ask: keep, update, or delete?
4. Execute confirmed deletions
5. Update MEMORY.md index accordingly

Never delete without explicit confirmation.

/memory add <topic>

1. Ask the user what they want to remember (if not clear from context)
2. Determine the memory type (user, feedback, project, reference)
3. Create a new file with proper frontmatter:

---
name: <descriptive name>
description: <one-line description for relevance matching>
type: <user|feedback|project|reference>
---

<memory content>

4. Add an entry to MEMORY.md
5. 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