Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
aiskillstore avatar

Memory Management

aiskillstore/marketplace

  • 1 installs
  • 404 repo stars
  • Updated August 5, 2026
  • aiskillstore/marketplace

memory-management is a Claude Code skill that provides patterns for an agent to capture and reuse preferences, decisions, and context across sessions.

About

memory-management is a Claude Code skill that defines patterns for intentionally capturing and reusing context, decisions, and user preferences across sessions. A developer uses it to decide what an agent should persist (preferences, architectural decisions, correction patterns, project knowledge), where to store it, and when to refresh it. It stresses transparency and never storing sensitive data.

  • Guides when and how an agent captures preferences, decisions, and corrections across sessions
  • Stores context as human-readable JSON under .claude/memory/
  • Enforces selectivity and never persisting secrets like API keys or tokens

Memory Management by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #14,102 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

memory-management capabilities & compatibility

Capabilities
agent memory · context tracking · decision logging
Use cases
memory · planning
Pricing
Free
From the docs

What memory-management says it does

Context tracking and decision logging patterns for intentional memory management in Claude Code Waypoint Plugin.
SKILL.md
**Never store sensitive data**:
SKILL.md
npx skills add https://github.com/aiskillstore/marketplace --skill memory-management

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars★ 404
Last updatedAugust 5, 2026
Repositoryaiskillstore/marketplace ↗

What it does

Decide what agent context, preferences, and decisions to persist across sessions and how to store them.

Who is it for?

Developers designing how a coding agent should remember preferences and decisions across sessions.

Skip if: Storing secrets, credentials, or transient one-off experiments.

When should I use this skill?

You need rules for when and how an agent should persist user preferences or decisions.

What you get

Preferences, decisions, and correction patterns captured selectively and applied automatically.

  • Preferences JSON
  • Decisions log
  • Corrections log

By the numbers

  • 4 core principles: Be Selective, Be Transparent, Be Intentional, Be Respectful
  • Three persistence timings: immediate, deferred, and never

Files

SKILL.mdMarkdownGitHub ↗

Memory Management Skill

Purpose

Guide Claude Code to intentionally capture, store, and use context, decisions, and preferences across sessions, enabling true "memory" that survives context resets and improves over time.

When to Use This Skill

Automatically activates when you mention:

  • Remembering user preferences or choices
  • Tracking decisions made during development
  • Capturing important context
  • Learning from user corrections
  • Persisting project-specific knowledge
  • Memory that survives session resets

The Problem: Context Loss

Without intentional memory:

  • ❌ Same mistakes repeated across sessions
  • ❌ User has to re-explain preferences every time
  • ❌ Important decisions forgotten after context reset
  • ❌ No learning from corrections
  • ❌ Starting from scratch each session

With intentional memory:

  • ✅ Preferences remembered and auto-applied
  • ✅ Decisions documented and retrievable
  • ✅ Context persists across sessions
  • ✅ Learn and adapt from corrections
  • ✅ Continuous improvement over time

---

Core Principles

1. Be Selective

Track signal, not noise:

  • ✅ User explicitly states preference ("always use X")
  • ✅ User corrects same pattern 2+ times
  • ✅ Important architectural decisions
  • ✅ Project-specific conventions
  • ❌ One-time experiments
  • ❌ Formatting preferences (use linter config)
  • ❌ Temporary changes
  • ❌ Information already in codebase

2. Be Transparent

User should always know what's stored:

  • Store in visible location (.claude/memory/)
  • Use human-readable format (JSON with comments)
  • Provide commands to view memory (/show-memory)
  • Log when memory is created/updated
  • Allow user to clear memory anytime

3. Be Intentional

Only capture what adds value:

  • Preferences that save time
  • Decisions that provide context
  • Patterns that prevent mistakes
  • Knowledge that's hard to rediscover

4. Be Respectful

Never store sensitive data:

  • ❌ API keys, tokens, credentials
  • ❌ Personal information (unless necessary)
  • ❌ Private repository URLs with tokens
  • ❌ Business-sensitive logic
  • ✅ Preferences, patterns, conventions
  • ✅ Architecture decisions, rationale

---

What to Remember

User Preferences

Examples:

  • Naming conventions (camelCase vs. snake_case)
  • Import style (named vs. default)
  • Error handling approach (try/catch vs. error boundaries)
  • State management choice (Context vs. Zustand vs. TanStack Query)
  • Component structure preferences

Storage location: .claude/memory/{skill-name}/preferences.json

Example:

{
  "naming": {
    "convention": "camelCase",
    "learned_from": "user_correction",
    "correction_count": 2,
    "examples": [
      "userId (not user_id)",
      "createdAt (not created_at)"
    ],
    "confidence": "high",
    "last_updated": "2025-01-15T10:30:00Z"
  }
}

Architectural Decisions

Examples:

  • Why a specific pattern was chosen
  • Alternatives considered and rejected
  • Trade-offs and constraints
  • Future considerations

Storage location: .claude/memory/project/decisions.json

Example:

{
  "decisions": [
    {
      "id": "auth-jwt-2025-01-15",
      "date": "2025-01-15",
      "decision": "Use JWT authentication instead of sessions",
      "rationale": "Need stateless auth for mobile apps",
      "alternatives_considered": [
        "Session-based auth (rejected: not stateless)",
        "OAuth only (rejected: need custom auth flow)"
      ],
      "impact": "Requires database migration for refresh tokens",
      "files_affected": [
        "lib/supabase/auth.ts",
        "app/api/auth/**/*.ts"
      ]
    }
  ]
}

Correction Patterns

Examples:

  • User repeatedly corrects same mistake
  • User provides specific guidance
  • User rejects suggested approach

Storage location: .claude/memory/{skill-name}/corrections.json

Example:

{
  "corrections": [
    {
      "pattern": "Import style",
      "count": 3,
      "first_seen": "2025-01-10T09:00:00Z",
      "last_seen": "2025-01-15T14:30:00Z",
      "examples": [
        "import { Component } from 'lib' ✓",
        "import Component from 'lib' ✗"
      ],
      "action": "Always use named imports",
      "confidence": "high"
    }
  ]
}

Project Knowledge

Examples:

  • Tech stack and versions
  • Project structure and organization
  • Integration points (APIs, databases)
  • Deployment patterns

Storage location: .claude/memory/project/knowledge.json

Example:

{
  "tech_stack": {
    "frontend": "Next.js 14, React 19, shadcn/ui, Tailwind",
    "backend": "Supabase Edge Functions, PostgreSQL",
    "deployment": "Vercel (frontend), Supabase (backend)",
    "last_verified": "2025-01-15"
  },
  "structure": {
    "components": "app/components/",
    "pages": "app/(routes)/",
    "api": "app/api/",
    "supabase_functions": "supabase/functions/"
  }
}

---

When to Persist

Immediate Persistence

Capture immediately when:

  • ✅ User explicitly says "always" or "never"
  • ✅ User provides architectural decision with rationale
  • ✅ User corrects same pattern for the 2nd time
  • ✅ User defines project-specific convention

Deferred Persistence

Capture after confirmation when:

  • User provides preference once (wait for second instance)
  • Pattern seems emerging but not confirmed
  • Decision has significant impact (confirm first)

Never Persist

Don't capture:

  • ❌ Experimental or temporary changes
  • ❌ Information already in code/config
  • ❌ Generic best practices (not project-specific)
  • ❌ Sensitive data of any kind

---

Storage Patterns

Directory Structure

.claude/memory/
├── project/
│   ├── knowledge.json          # Tech stack, structure
│   ├── decisions.json          # Architectural decisions
│   └── context.json            # Current feature context
├── {skill-name}/
│   ├── preferences.json        # User preferences for this skill
│   ├── corrections.json        # User corrections tracked
│   └── learned_patterns.json  # Patterns learned over time
└── .gitignore                  # Don't commit sensitive memory

File Format

Use JSON with clear structure:

{
  "version": "1.0",
  "created": "2025-01-15T10:00:00Z",
  "last_updated": "2025-01-15T14:30:00Z",
  "data": {
    // Actual content
  }
}

Schema Example

interface MemoryEntry {
  version: string;
  created: string;           // ISO timestamp
  last_updated: string;      // ISO timestamp
  expires?: string;          // Optional expiry
  confidence: 'low' | 'medium' | 'high';
  source: 'user_stated' | 'user_correction' | 'inferred';
  data: Record<string, any>;
}

---

Decision Tracking

What Makes a Good Decision Log

Include: 1. What: What was decided 2. Why: Rationale and reasoning 3. When: Date/time 4. Alternatives: What else was considered 5. Impact: Files affected, breaking changes 6. Context: Current constraints/requirements

Example Template:

## Decision: [Short Title]

**Date**: 2025-01-15
**Context**: [What problem were we solving?]

**Decision**: [What we decided to do]

**Rationale**:
- [Key reason 1]
- [Key reason 2]

**Alternatives Considered**:
- **Option A**: [Why rejected]
- **Option B**: [Why rejected]

**Impact**:
- Files: [List of affected files]
- Breaking: [Yes/No - details]
- Migration: [What needs to change]

**Trade-offs**:
- ✅ Pro: [Benefit]
- ❌ Con: [Drawback]

When to Log Decisions

Always log:

  • ✅ Architecture changes (auth, state management, routing)
  • ✅ Technology choices (new library, framework change)
  • ✅ Breaking changes to APIs or database
  • ✅ Deviation from established patterns

Optional logging:

  • Component structure choices
  • File organization changes
  • Refactoring approaches

Don't log:

  • Bug fixes (unless revealing design issue)
  • Minor implementation details
  • Routine tasks

---

Correction Tracking

Detecting Corrections

User corrections happen when: 1. User explicitly corrects Claude's output 2. User provides same feedback multiple times 3. User rejects suggested approach and provides alternative

Tracking Pattern

interface Correction {
  pattern: string;                    // What's being corrected
  count: number;                      // How many times
  first_seen: string;                 // ISO timestamp
  last_seen: string;                  // ISO timestamp
  examples: string[];                 // Examples of correct/incorrect
  action: string;                     // What to do instead
  threshold: number;                  // Apply after N corrections
  confidence: 'low' | 'medium' | 'high';
}

Auto-Application

After threshold corrections (typically 2-3): 1. Store preference as "high confidence" 2. Auto-apply in future 3. Notify user: "📚 Learned preference from your corrections" 4. Provide way to reset if incorrect

Example Workflow

## First Correction
User: "Use named imports, not default"
Action: Note correction, don't apply yet

## Second Correction (same pattern)
User: "Again, please use named imports"
Action: Log pattern, apply going forward
Notify: "📚 Learned: Always use named imports"

## Future Usage
Claude automatically uses named imports
User can reset with: /clear-memory import-style

---

Context Boundaries

What Belongs in Memory vs. Code

In Memory (.claude/memory/):

  • Preferences not in code/config
  • Decision rationale (the "why")
  • Correction patterns
  • Temporary feature context

In Code/Config:

  • Linting rules (ESLint, Prettier)
  • Type definitions
  • Constants and configuration
  • Architecture (visible in structure)

Rule of Thumb: If it can be in code, put it in code. Memory is for what code can't capture.

---

Memory Refresh

When to Invalidate

Memory should refresh when:

  • ✅ Dependencies change (package.json updated)
  • ✅ Tech stack changes (new framework adopted)
  • ✅ Project structure refactored significantly
  • ✅ User explicitly requests reset
  • ✅ Memory is stale (> 30 days old, configurable)

Staleness Detection

function isStale(memory: MemoryEntry, maxAge: string): boolean {
  const age = Date.now() - new Date(memory.last_updated).getTime();
  const maxAgeMs = parseAge(maxAge); // "7 days", "30 days"
  return age > maxAgeMs;
}

Refresh Strategies

Automatic Refresh:

  • Watch critical files (package.json, tsconfig.json)
  • Invalidate related memory on change
  • Re-scan and update

Manual Refresh:

/refresh-memory              # Refresh all
/refresh-memory [skill]      # Refresh specific skill
/clear-memory [skill]        # Clear and start fresh

---

Best Practices

DO ✅

1. Log important decisions with rationale 2. Track user corrections (2+ times = pattern) 3. Store in human-readable format (JSON) 4. Provide user control (view/clear commands) 5. Include timestamps and confidence levels 6. Refresh memory when dependencies change 7. Notify user when learning from corrections

DON'T ❌

1. Don't store sensitive data 2. Don't persist everything (be selective) 3. Don't assume memory is always valid (check staleness) 4. Don't make memory opaque (user should understand) 5. Don't persist what belongs in code 6. Don't keep stale memory indefinitely

---

Commands for Memory Management

Provide these commands to users:

# View memory
/show-memory                  # Show all memory
/show-memory [skill]          # Show specific skill memory

# Clear memory
/clear-memory [skill]         # Clear specific skill
/clear-all-memory             # Clear everything (confirm first)

# Refresh memory
/refresh-memory               # Refresh all memory
/refresh-memory [skill]       # Refresh specific skill

# Export/backup
/export-memory                # Export for backup
/import-memory [file]         # Restore from backup

---

Integration with Other Skills

With context-persistence Skill

Memory management stores preferences and patterns. Context persistence stores current task state.

Example:

  • Memory: "User prefers named imports" (permanent)
  • Context: "Currently implementing auth feature" (temporary)

With plan-approval Skill

Memory management stores approved decisions. Plan approval handles future decisions requiring approval.

Example:

  • Memory: "JWT auth was approved on 2025-01-15"
  • Plan: "Proposing addition of OAuth - needs approval"

---

Example: Complete Memory Management Workflow

Scenario: User Corrects Import Style Twice

First Correction:

User: "Please use named imports instead of default"
Claude: ✓ Fixed import style
Action: Log correction in memory (count: 1)

Second Correction (same pattern):

User: "Again, use named imports"
Claude: ✓ Fixed import style
Action: Mark as learned pattern (count: 2)
Notify: "📚 Learned preference: Always use named imports"
Storage: .claude/memory/project/preferences.json

Future Usage:

Claude automatically uses named imports
User sees: "✓ Using your preferred import style (named imports)"

User Can Reset:

User: /clear-memory import-style
Claude: ✓ Cleared import style preference

---

Privacy & Security

What to Store

✅ Safe:

  • Code preferences (naming, structure)
  • Architecture decisions (patterns, approaches)
  • Correction patterns
  • Project knowledge (tech stack, structure)

❌ Never Store:

  • API keys, tokens, credentials
  • Personal information
  • Sensitive business logic
  • Private URLs with tokens

User Control

Transparency:

  • Memory files in visible location
  • Human-readable format
  • Clear documentation of what's stored

Control:

  • View memory anytime
  • Clear memory anytime
  • Export/backup memory
  • Memory not committed to git (add to .gitignore)

---

Summary

Memory management enables Claude Code to: 1. ✅ Remember user preferences across sessions 2. ✅ Learn from corrections and adapt 3. ✅ Document decisions with rationale 4. ✅ Provide continuity across context resets 5. ✅ Improve over time without user repetition

Key principle: Be selective, transparent, intentional, and respectful of user privacy.

Storage: .claude/memory/ directory with JSON files

Commands: /show-memory, /clear-memory, /refresh-memory

Use this skill to make Claude Code feel like it truly "remembers" your project!

Related skills

mattpocockSetup Matt Pocock SkillsScaffold the per-repo configuration that Matt Pocock’s engineering agent skills rely on so they understand the issue tracker, triage labels, and domain documentation la495k196kopen.feishu.cnLark AppsConnect Claude, Cursor or custom agents directly to Lark (Feishu) for messaging, document automation, approval workflows and enterprise data access.402kjuliusbrusseeCavemanSlash token usage by roughly 75% while keeping every technical detail intact when working with Claude Code, Cursor or similar agents.391k94.7klarksuiteLark Skill MakerQuickly turn any Lark/Feishu OpenAPI call or multi-step workflow into a reusable agent skill with its own SKILL.md.386k16kxixu-meRunning Claude Code Via Litellm CopilotRun Claude Code at a fraction of the cost by routing requests through LiteLLM to the GitHub Copilot Chat API.270k72runcomfy-comCodex PetGenerate a complete Codex Pet spritesheet and metadata from one reference image without needing an OpenAI key or Codex Pro.246k10

FAQ

What should the agent persist?

User preferences, architectural decisions with rationale, repeated correction patterns, and project knowledge like tech stack and structure.

What must never be stored?

Sensitive data such as API keys, tokens, credentials, and business-sensitive logic; only preferences, patterns, and decisions are stored.

AI & Agent Buildingagentsautomation
Browse by category
AI & AgentsFrontend & DesignBackend & DataDev ToolsAutomationTesting & ReviewSecurityMonitoring & CloudDocs & Planning
Design & frontend
Design systemsAnimation & motionAccessibility (a11y)CSS & TailwindUI designUXDesign to codeshadcn/uiLanding pagesBest design skills
Most searched skills
find-skillscavemanfrontend-designbrainstormingsystematic-debuggingstop-slopemil-design-engui-ux-pro-maxkarpathy-guidelinesweb-design-guidelinesreact-best-practicesgrill-meimprovemicrosoft-foundryagent-browser
Browse all listings
All agent skillsAll MCP serversAll marketplacesAll plugins

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.