Claude Migrate Memory To Doc
Migrates Claude Code personal memory (the per-project memory/ directory) into...
Install
npx skills add daymade/claude-code-skills --skill claude-migrate-memory-to-doc -g -a claude-code -y- Repository
- daymade/claude-code-skills1.5k
- Category
- AI and agents
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- Yes, review before use
What it does
Migrates Claude Code personal memory (the per-project memory/ directory) into tool-agnostic reference docs so other AI CLIs that auto-load AGENTS.md (Codex primarily) can read the same user profile and preferences. Use when the user says "migrate my memory", "my memory is locked to Claude Code", "make Codex/Cursor read my profile", or reports memory has grown bloated with content that should be shared across tools. Also use it to retire a project's auto memory entirely (turn it off, move everything into documents, archive the directory).
Migrate Claude Code Memory to Tool-Agnostic Docs
Why this skill exists
Claude Code's personal memory lives in ~/.claude/projects/<project-slug>/memory/. It is locked to Claude Code: not version-controlled with the repo, invisible to every other tool. The moment the user runs Codex, Cursor, or any other AI CLI in the same directory, those tools cannot read "who the user is / how to work with them", even though a user profile and collaboration preferences are exactly what any AI assistant should read first.
This skill moves the cross-tool-shareable content out of memory into a tool-agnostic location, and leaves memory as a thin handoff cache. The real problem it solves is tool lock-in, not "messy memory".
This skill runs inline (never context: fork): it spawns parallel review subagents and runs codex via Bash, a forked subagent could do neither.
First: which goal?
| Goal | The user wants | Path |
|---|---|---|
| A, end tool lock-in | other AI tools to read the same profile and preferences; memory stays as a thin handoff cache | the Workflow below, all phases |
| B, retire auto memory | a project to stop using auto memory, with documents owning everything it held | references/retire_auto_memory.md; from the Workflow below use Phase 1's scope table and Phase 6's archive rules, and do Phases 2 and 5 only if the user also wants Codex to read the result |
Goal B has no "stays in memory" bucket: handoff state, external pointers and pending rulings need a document home, the memory directory ends empty, and the project switch is turned off and proven with a control probe. When the request does not say which goal, ask.
The core insight, read this before touching anything
The hard part is not moving files. It is this:
A reference file reached only by a plain-text pointer is read on-demand and is NOT guaranteed to load, in either tool.
