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

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