memory-management

Memory Management Skill

Use AutoMem to maintain persistent context across Claude Code sessions. This skill teaches the 3-Phase Memory Pattern: Recall → Store → Summarize.

Phase 1: SESSION START (Recall)

Always Recall For

• Project context questions (architecture, tooling, deployment)
• Architecture discussions or decisions
• User preferences and code style
• Debugging issues (search for similar past problems)
• Refactoring (understand why current structure exists)
• Integration or API work (check past implementations)
• Performance optimization discussions

Adaptive Recall Based on Context

• Files open → Recall memories tagged with those components
• Error messages → Search for similar error patterns
• Multiple files → Recall architectural decisions
• PR/commit context → Recall related feature implementations

Skip Recall For

• Pure syntax questions ("How does Array.map work?")
• Trivial edits (typos, formatting, simple renames)
• Direct factual queries about current code
• File content requests that can be answered by reading

Recall Examples

// Basic project recall
mcp__memory__recall_memory({
  query: "project architecture decisions",
  tags: ["project-name"],
  limit: 5
})

// Debug similar errors
mcp__memory__recall_memory({
  query: "TypeError authentication timeout",
  tags: ["bug-fix"],
  time_query: "last 30 days",
  limit: 5
})

// Multi-hop reasoning (find related context)
mcp__memory__recall_memory({
  query: "Who worked on the auth system?",
  expand_entities: true,
  limit: 10
})

// Context-aware coding recall
mcp__memory__recall_memory({
  query: "error handling patterns",
  language: "typescript",
  context: "coding-style",
  context_types: ["Style", "Pattern"]
})

Phase 2: DURING WORK (Store)

What to Store with Importance Levels

Type	Importance	When to Store
Decision	0.9	Architecture, library choices, pattern decisions
Insight	0.8	Root cause discoveries, key learnings, bug fixes
Pattern	0.7	Reusable approaches, best practices
Preference	0.6-0.8	User config choices, style preferences
Context	0.5-0.7	Feature summaries, refactoring notes

Storage Format

Content: "Brief title. Context and details. Impact/outcome."
Tags: [project-name, component, YYYY-MM, type]
Type: Decision | Pattern | Insight | Preference | Style | Habit | Context

Storage Examples

Decision:

mcp__memory__store_memory({
  content: "Chose PostgreSQL over MongoDB. Need ACID guarantees for transactions. Impact: Ensures data consistency.",
  type: "Decision",
  tags: ["myapp", "database", "decision", "2025-12"],
  importance: 0.9,
  metadata: {
    alternatives_considered: ["MongoDB", "DynamoDB"],
    deciding_factors: ["ACID", "relationships", "team_expertise"]
  }
})

Bug Fix:

mcp__memory__store_memory({
  content: "Auth timeout on slow connections. Root: Missing retry logic. Solution: Added exponential backoff with 3 retries.",
  type: "Insight",
  tags: ["myapp", "auth", "bug-fix", "2025-12"],
  importance: 0.8,
  metadata: {
    error_signature: "TimeoutError: Authentication request timed out",
    solution_pattern: "exponential-backoff-retry",
    files_modified: ["src/auth/client.ts"]
  }
})

User Preference:

mcp__memory__store_memory({
  content: "User prefers early returns over nested conditionals in validation code.",
  type: "Preference",
  tags: ["preferences", "code-style", "2025-12"],
  importance: 0.8
})

After Storing: Create Associations

Link related memories to build a knowledge graph:

mcp__memory__associate_memories({
  memory1_id: "new-memory-id",
  memory2_id: "related-memory-id",
  type: "DERIVED_FROM",  // or LEADS_TO, EVOLVED_INTO, RELATES_TO
  strength: 0.9
})

Relationship Types:

• LEADS_TO - Bug → Solution, Problem → Fix
• EVOLVED_INTO - Updated approaches or decisions
• DERIVED_FROM - Implementation from planning
• EXEMPLIFIES - Concrete examples of patterns
• CONTRADICTS - Conflicting approaches
• REINFORCES - Supporting evidence
• INVALIDATED_BY - Obsoleted solutions
• RELATES_TO - General connections
• OCCURRED_BEFORE - Temporal ordering
• PREFERS_OVER - Chosen alternative
• PART_OF - Component of a larger effort

System/internal relations such as SIMILAR_TO, PRECEDED_BY, EXPLAINS, SHARES_THEME, PARALLEL_CONTEXT, and DISCOVERED may appear in recall results, but they are not valid associate_memories inputs.

Phase 3: SESSION END (Summarize)

Store a session summary when:

• Multiple files modified
• Significant refactoring completed
• New features implemented
• Important decisions made

mcp__memory__store_memory({
  content: "Added authentication system with JWT. Supports login, logout, and token refresh. Impact: Users can now login securely.",
  type: "Context",
  tags: ["myapp", "auth", "feature", "2025-12"],
  importance: 0.9,
  metadata: {
    files_modified: ["src/auth/UserAuth.ts", "src/middleware/auth.ts"],
    feature: "authentication"
  }
})

Best Practices

Do

• Load context automatically at session start
• Store high-signal events (decisions, bugs, patterns)
• Create specific relationship types (not just RELATES_TO)
• Include rich metadata in every memory
• Present recalled information naturally
• Tag consistently: project, component, type, YYYY-MM

Don't

• Store secrets, API keys, or sensitive data
• Store trivial changes (typos, formatting)
• Create associations without verifying relevance
• Skip tagging or use inconsistent formats
• Announce "I'm searching my memory" constantly
• Store large code blocks (store patterns/decisions instead)

Natural Integration

When recalling memories, weave context seamlessly into responses. Avoid robotic phrases like "searching my memory database" - present memories as if you've always known them.

Bad: "Let me search my memory... I found that you previously decided to use PostgreSQL."

Good: "Since you chose PostgreSQL for its ACID guarantees, we should use transactions here."