m2ai-portfolio Memory System Assembler
Guides a builder from zero to a working, personalized Claude Code memory system by sampling the open-source memory ecosystem rather than reinventing it.
Trigger
Use when the user says "build my memory system", "design my Claude Code memory", "what memory patterns should I use", "audit memory repos", "help me set up memory for Claude Code", "my memory feels generic", or "how do I customize Claude Code memory."
Phase 1: Workflow Interview
Ask the user one question at a time in natural conversation:
- Session cadence -- How many Claude Code sessions per day? (1-3 / 4-8 / 8+)
- Primary work type -- What do you use Claude Code for most? (code / writing / research / multi-project management / mixed)
- What breaks for you -- When memory fails, what gets lost? (preferences, decisions, project context, cross-session patterns, all of the above)
- Persistence horizon -- How far back does memory need to reach? (current session only / about a week / indefinitely)
- Maintenance appetite -- How much time per week are you willing to spend maintaining memory? (0 minutes / ~5 minutes / 30+ minutes)
- Solo or shared -- Is this a solo Claude Code environment or shared across a team?
Phase 2: Map the 7 Memory Layers
Teach the user the building blocks before picking them. Present this table and explain each layer briefly:
| Layer | What it stores | Lifespan | Maintenance |
|---|---|---|---|
| 1. In-context | Current session facts injected via prompt | Session only | Zero |
| 2. CLAUDE.md rules | Durable behavioral rules and conventions | Permanent | Manual edits |
| 3. Memory files | Structured facts in a /memory/ directory |
Permanent | Auto-capture or manual |
| 4. Hooks | Triggered capture (SessionStart, PostToolUse, etc.) | Permanent | One-time setup |
| 5. Scheduled compaction | Periodic summaries of session transcripts | Rolling window | Cron or manual |
| 6. External store | SQLite or vector DB for semantic recall | Permanent | Integration work |
| 7. Agent-managed | A sub-agent writes learnings back after each task | Permanent | Agent ownership |
Ask: "Which of these layers do you already have? Which are missing from your setup?" Use the gaps and the interview answers to focus the next phase.
Phase 3: Audit Reference Repos
Based on the interview, suggest 2-3 open-source Claude Code memory repos to clone and audit. For each:
git clone <repo_url> /tmp/memory-audit/<repo-name>
Then audit it inside Claude Code with this prompt:
"Read this repo and tell me: (1) which of the 7 memory layers it implements, (2) what files it creates or modifies, (3) estimated maintenance burden per week, (4) the single most useful pattern for someone whose primary work type is [user's answer from Phase 1]."
Produce a comparison table after auditing all repos:
| Repo | Layers covered | Key pattern | Fits this user? |
|---|---|---|---|
| ... | ... | ... | Yes / No / Partial |
Phase 4: Cherry-Pick and Assemble
From the audit results, select patterns that scored "Yes" or "Partial" for this user's workflow. For each selected pattern:
- State which layer it addresses
- Describe what file it creates or modifies
- State the weekly maintenance cost honestly
Generate an assembly plan before writing any files:
Memory System Plan
==================
Layers in scope: [list]
Files to create: [list]
Hooks to install: [list]
Estimated setup time: [X minutes]
Estimated weekly maintenance: [X minutes]
Step 1: [concrete action]
Step 2: [concrete action]
...
Get the user's confirmation before proceeding to Phase 5.
Phase 5: Generate Artifacts
For each selected pattern, produce the actual file content:
CLAUDE.md memory section -- rules for what to remember and when. Example:
## Memory Protocol
After every session, capture:
- Decisions made (what and why)
- Preferences the user corrected
- Project context that would take >30 seconds to re-establish
Store in `./memory/` as dated markdown files.
Memory file templates -- e.g., memory/user.md, memory/project.md with frontmatter:
---
type: user | project | feedback | reference
updated: YYYY-MM-DD
---
Hook stubs -- if the user has hooks enabled:
# session-start-memory.py (SessionStart hook)
# Reads memory files and injects them as context at session start
import os, glob
memory_dir = os.path.join(os.getcwd(), "memory")
for f in glob.glob(f"{memory_dir}/*.md"):
print(open(f).read())
Compaction script stub -- if maintenance appetite >= 5 min/week:
# compact_memory.py -- run weekly or when memory files exceed 50 entries
# Summarizes dated memory files into a single rolling summary
All paths use ./ or an environment variable -- no hardcoded absolute paths.
Verification
- All 6 interview questions answered (or sensible defaults applied with a note)
- User knows which of the 7 layers they are and are not implementing, and why they skipped the others
- At least one open-source repo was audited before cherry-picking patterns
- Assembly plan was confirmed by user before any files were generated
- All generated file paths use
./or env-configurable values -- no hardcoded personal directories - Weekly maintenance cost stated explicitly and accepted
Source
Mark Kashef -- "Master ALL 7 Levels of Claude Code Memory" (YouTube, 2026-04-22). Video ID: OMkdlwZxSt8. Core insight: with 35+ open-source memory systems available, memory should be treated like a fingerprint -- no two should look the same. The clone-audit-cherry-pick pattern avoids reinventing the wheel while keeping the result personalized to actual workflow.