{"skill":{"slug":"claude-code-memory-skill","displayName":"Claude Code Memory Skill","summary":"Use when you want to set up, maintain, or review a Claude Code style layered memory workflow, including `CLAUDE.md` rules, session memory, durable memory, an...","description":"---\nname: \"claude-code-memory\"\ndescription: \"Use when you want to set up, maintain, or review a Claude Code style layered memory workflow, including `CLAUDE.md` rules, session memory, durable memory, and promotion of stable learnings into instruction files.\"\n---\n\n## Overview\n\nUse this skill when the task involves memory design or memory hygiene for Claude Code or a similar coding agent.\n\nThis skill organizes memory into three layers:\n\n1. Instruction memory\n2. Session memory\n3. Durable memory\n\nThe intent is to keep each layer narrow, useful, and easy to trust.\n\n## Before you start\n\n- Identify the host tool's instruction file. For Claude Code this is usually `CLAUDE.md` or `CLAUDE.local.md`. Other common examples are `AGENTS.md` and `.github/copilot-instructions.md`.\n- Identify or create a repo-local durable memory directory. The default layout in this skill uses `.agent-memory/`.\n- Identify or create the session summary file at `.agent-memory/session/summary.md`.\n\n## Layer 1: Instruction memory\n\nTreat the host instruction file as the rule layer. In Claude Code, this is the `CLAUDE.md` layer.\n\nPut information here only if it is:\n\n- stable\n- normative\n- broadly applicable across future work\n- costly for the agent to rediscover incorrectly\n\nGood candidates:\n\n- test commands\n- review expectations\n- approval boundaries\n- release process rules\n- communication style preferences that consistently apply\n\nDo not place transient task state here.\n\n## Layer 2: Session memory\n\nMaintain `.agent-memory/session/summary.md` as the short-lived working notebook for the current thread.\n\nIt should answer:\n\n- What is actively being worked on now\n- What did the user ask for\n- Which files and functions matter\n- Which commands have already been run\n- Which errors happened and how they were resolved\n- What remains next\n\nThis layer should be updated during long tasks and before compaction or handoff.\n\nUse this structure:\n\n```markdown\n# Session Title\n\n# Current State\n\n# Task Specification\n\n# Files and Functions\n\n# Workflow\n\n# Errors and Corrections\n\n# Key Results\n\n# Worklog\n```\n\nKeep it concise but concrete. Prefer file paths, exact commands, and specific failure modes over generic summaries.\n\n## Layer 3: Durable memory\n\nUse `.agent-memory/` for long-lived memories that should survive across conversations.\n\nStore durable memories in topic files and keep `.agent-memory/MEMORY.md` as an index.\n\nUse the following durable memory types:\n\n### `user-profile`\n\nInformation about the user's role, goals, background, and level of familiarity.\n\nExamples:\n\n- backend-heavy engineer who wants frontend explanations grounded in systems concepts\n- founder who prefers quick trade-off summaries\n\n### `working-style`\n\nGuidance about how to collaborate with this user or team.\n\nExamples:\n\n- run tests before proposing a commit\n- avoid long recap paragraphs\n- prefer one bundled refactor PR in this codebase\n\n### `project-context`\n\nImportant project facts that are not derivable from the repo.\n\nExamples:\n\n- freeze window dates\n- stakeholder constraints\n- migration rationale\n- incident aftermath that still shapes decisions\n\n### `external-reference`\n\nPointers to systems outside the repo.\n\nExamples:\n\n- which dashboard matters for this codepath\n- which Linear board tracks this class of bugs\n- which Slack channel owns deployment coordination\n\n## Durable memory format\n\nEach durable memory should live in its own file with frontmatter:\n\n```markdown\n---\nname: testing-policy\ndescription: Integration tests in this repo must hit a real database\ntype: working-style\n---\n\nIntegration tests in this repo must hit a real database.\n\nWhy:\nA previous production migration failure was missed by mock-based coverage.\n\nHow to apply:\nWhen changing data access or migrations, prefer real-db integration coverage over mocks.\n```\n\nThe index file should stay short:\n\n```markdown\n- [Testing Policy](testing-policy.md) - Real database integration tests are expected here\n```\n\n## What not to save as durable memory\n\nDo not save these unless there is a strong reason and the non-obvious part is the actual point:\n\n- file structure\n- code architecture visible in the repo\n- git history\n- recent diff summaries\n- temporary task state\n- obvious commands already documented in project instructions\n\nIf it can be recovered cheaply from the current repo, prefer not to save it as durable memory.\n\n## Recall discipline\n\nNever trust durable memory blindly.\n\nBefore acting on it:\n\n- verify named files still exist\n- grep for named functions or flags\n- prefer current repo state over historical memory if they conflict\n- update or remove stale memories when you discover drift\n\n## Promotion workflow\n\nWhen reviewing memory, classify each item:\n\n- Promote to instruction memory\n- Keep in durable memory\n- Keep only in session memory\n- Delete as stale, duplicate, or overfit\n\nPromote into the instruction layer when the item has become a rule.\nKeep it in durable memory when it remains useful context but is not a rule.\nKeep it only in session memory when it is tied to the present thread.\n\n## Review workflow\n\nWhen the user asks to review memory:\n\n1. Read the host instruction file such as `CLAUDE.md`\n2. Read `.agent-memory/MEMORY.md`\n3. Read the most relevant durable topic files\n4. Read `.agent-memory/session/summary.md` if current-thread context matters\n5. Produce a report with:\n   - promotions\n   - cleanup\n   - conflicts\n   - ambiguous items\n\nDo not modify durable memory or instruction files without user approval unless the user explicitly asked you to apply the cleanup.\n\n## File layout used by this skill\n\n```text\n.agent-memory/\n├── MEMORY.md\n├── user/\n├── style/\n├── project/\n├── references/\n└── session/\n    └── summary.md\n```\n\n## References\n\n- Architecture notes: [references/architecture.md](references/architecture.md)\n- Host tool mapping: [references/host-tool-mapping.md](references/host-tool-mapping.md)\n- Example durable memory files: [examples/persistent-memory/MEMORY.md](examples/persistent-memory/MEMORY.md)\n- Example session summary: [examples/session-memory/summary.md](examples/session-memory/summary.md)\n","tags":{"ai-agents":"0.1.0","claude-code":"0.1.0","developer-tools":"0.1.0","latest":"0.1.0","memory":"0.1.0"},"stats":{"comments":0,"downloads":497,"installsAllTime":0,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1775535269998,"updatedAt":1778492452586},"latestVersion":{"version":"0.1.0","createdAt":1775535269998,"changelog":"Initial release: clean-room layered memory skill for Claude Code style workflows.","license":"MIT-0"},"metadata":null,"owner":{"handle":"indulgeback","userId":"s17c9rx4tm2s32dxkb55zg4txd84dc39","displayName":"Liu Wenyu","image":"https://avatars.githubusercontent.com/u/117838866?v=4"},"moderation":null}