Memory Skill

When the user triggers this skill, extract and persist the key information from the current conversation.

Storage location

Memory files live in the project's auto-memory directory:

.claude/projects/<project-slug>/memory/

The <project-slug> is the project path with separators replaced by - (e.g., C--Users-tjm-Desktop-claude-Software-Dog). Find the exact path by checking ~/.claude/projects/ for directories matching the current project.

Always verify the project slug matches the current working directory before writing.

File structure

Two types of files to manage:

MEMORY.md (index file)

A lightweight index. Each entry one line under 150 chars, like:

- [Title](file.md) — one-line description of what this memory is about

Keep under 200 lines. This file is auto-loaded every session.

Individual memory files (content files)

Each file has YAML frontmatter and markdown body:

---
name: short-name
description: one-line summary used to decide relevance
type: user | feedback | project | reference
---

Memory content. For feedback/project types, structure as:
rule/fact, then **Why:** and **How to apply:** lines.

Types:

• user — user's role, preferences, tech stack, knowledge level
• feedback — corrections to Claude's behavior, validated approaches
• project — project goals, decisions, constraints, deadlines
• reference — pointers to external resources (docs, dashboards, etc.)

What to save

Extract from the conversation:

1. User facts — role, preferences, tech stack, coding style, language preference
2. Project facts — what's being built, current branch, active tasks, constraints
3. Decisions — technical choices made, trade-offs discussed
4. Feedback — user corrections to Claude's approach (both "don't do X" and "exactly, keep doing Y")
5. References — mentioned external links, dashboards, ticket trackers

What NOT to save

• Code patterns derivable from reading the repo
• Git history (use git log instead)
• One-off bug fixes (the commit has the context)
• Ephemeral task details that won't matter next session
• Anything already documented in CLAUDE.md

Procedure

1. Read existing MEMORY.md to understand what's already saved
2. Identify new/updated information from the current conversation
3. Write or update individual memory files — create new ones or edit existing ones if info has changed
4. Update MEMORY.md index — add new entries, remove stale ones, keep under 200 lines
5. Tell the user what was saved and where

Examples

User says: "memory" at the end of a coding session

Claude:

1. Reads existing MEMORY.md
2. Notices: user chose TypeScript over JavaScript, prefers composition over inheritance, project deadline is next Friday
3. Creates/updates user_prefs.md, project_state.md
4. Updates MEMORY.md index
5. Reports: "Saved 3 memories: TypeScript preference, composition pattern, project deadline"

Principles

• Update, don't duplicate. If a memory file already exists on a topic, edit it rather than creating a new one.
• Keep it brief. Memory files should be short and focused. One topic per file.
• Be specific. "User prefers TypeScript" is better than "User has language preferences."
• Decay gracefully. Include dates for time-sensitive info so future Claude can judge relevance.