Agent skill

Claude Migrate Memory To Doc

by daymade in daymade/claude-code-skills

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…

MITAuto-check passedAgent Workflows

Install Claude Migrate Memory To Doc

skills CLI
$ npx skills add daymade/claude-code-skills --skill claude-migrate-memory-to-doc -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install daymade/claude-code-skills claude-migrate-memory-to-doc --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/daymade/claude-code-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/daymade-claude-code/claude-migrate-memory-to-doc .claude/skills/claude-migrate-memory-to-doc && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
claude-migrate-memory-to-doc
GitHub stars
1.4k
Token cost
~4.1k tokens
SKILL.md length
2,061 words
Files
8 (incl. scripts, references)
Skills in repo
103
Repo updated
First seen
Licence
MIT

At a glance

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…

  • Works in 6 steps: Diagnose & scope → Tool-agnostic migration → Multi-agent review → …
  • The user says migrate my memory
  • SKILL.md covers Why this skill exists, First: which goal?, The core insight — read this… and Tool-agnostic architecture, plus 3 more sections
  • Runs Python scripts from its folder; calls codex

What it does

Claude Migrate Memory To Doc is an agent skill from daymade/claude-code-skills. 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…

Its SKILL.md is about 4.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 10 other files, including scripts and reference files (for example `references/diagnosis_and_scoping.md`, `references/failure_cases.md` and `references/retire_auto_memory.md`).

It sits in Agent Workflows, covering Agent memory. The repository describes itself as: Professional Claude Code skills marketplace featuring production-ready skills for enhanced development workflows. The licence is MIT.

When your agent uses it

  • The user says migrate my memory
  • My memory is locked to Claude Code
  • Make Codex/Cursor read my profile
  • Reports memory has grown bloated with content that should be shared across tools

Example prompts

  • “migrate my memory”
  • “my memory is locked to Claude Code”
  • “make Codex/Cursor read my profile”
  • “/claude-migrate-memory-to-doc”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Diagnose & scope
  2. Tool-agnostic migration
  3. Multi-agent review
  4. Fix
  5. VERIFY BY RUNNING CODEX (do not skip, do not delegate to the user)
  6. Memory cleanup

What it can do on your machine

Read from SKILL.md and the folder at commit 872127b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Python), which the agent can run.

    Shell commands in SKILL.md call:

    • codex

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Claude Migrate Memory To Doc loads about 4.1k tokens when it runs, and up to ~12k if it reads all its reference files. Until then it costs about 143 tokens; SKILL.md has 2,061 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~143
When it runs · the whole SKILL.md, loaded when a task matches
~4.1k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~12k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from daymade/claude-code-skills at commit 872127b, republished under its MIT licence (© daymade). 2,061 words, ~4,139 tokens.

Download SKILL.mdSave it as .claude/skills/claude-migrate-memory-to-doc/SKILL.md (or your agent's skills folder). This skill also uses 7 other files; get the full folder from GitHub.
name
claude-migrate-memory-to-doc
description
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).
disable-model-invocation
true

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?

GoalThe user wantsPath
A — end tool lock-inother AI tools to read the same profile and preferences; memory stays as a thin handoff cachethe Workflow below, all phases
B — retire auto memorya project to stop using auto memory, with documents owning everything it heldreferences/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.

  • Claude Code auto-preloads a reference only via @import syntax. A plain-text pointer ("see ~/.claude/references/user/foo.md") is on-demand: the agent must choose to open it.
  • Codex is stricter: it does not parse or follow text paths written inside CLAUDE.md at all. It only auto-injects the doc files themselves (its AGENTS.md / configured fallback) along the ~/.codex → git-root → cwd chain. Reference files named anything else, sitting in ~/.claude/references/, are never auto-loaded by Codex.

Therefore the architecture must be a two-layer split:

LayerWhereGuarantee
Guaranteed-hit — the few facts that must be true every turninlined into CLAUDE.md body (both tools inject it)always present
On-demand detail — full profile, war-stories, edge casesreferences/ files, reached by pointerloaded when relevant

Putting the hardcore facts only in a reference and trusting a pointer is the #1 way this migration silently fails. Inline them.

Tool-agnostic architecture

~/.claude/CLAUDE.md            global instructions — BOTH tools inject this.
                               Inline the hardest user facts here (a short "User context" section).
~/.claude/references/user/     SSOT for profile / preferences / methodology / personal affairs.
~/.claude/references/user-profile.md   hub: condensed core + index into the user/ files
~/.codex/AGENTS.md  ──symlink──▶  ~/.claude/CLAUDE.md
                               so Codex's GLOBAL layer injects the same file Claude Code reads.
~/.codex/config.toml           raise project_doc_max_bytes — Codex truncates docs at 32 KiB by default,
                               which silently drops the back half of a long CLAUDE.md.

Scope note: the wiring (the ~/.codex/ symlink, the config edit, and the Phase 5 verification) is Codex-specific and was verified against Codex only (2026-06). The ~/.claude/references/user/ content layer transfers to any tool that auto-loads a project doc, but Cursor and others need their own wiring (Cursor reads .cursor/rules / a project-root AGENTS.md, not ~/.codex/) — not implemented or verified here.

Workflow

Copy this checklist into your working notes and check items off:

Memory → Tool-Agnostic Doc Migration:
- [ ] Phase 1: Diagnose & scope — classify every memory file by SCOPE
- [ ] Phase 2: Tool-agnostic migration — references/ + inline hardcore + symlink + config
- [ ] Phase 3: Multi-agent review — 4 parallel reviewers
- [ ] Phase 4: Fix everything review surfaced
- [ ] Phase 5: VERIFY BY RUNNING CODEX (not by reasoning)
- [ ] Phase 6: Memory cleanup — clean / thin / keep + soft-delete to backup
Phase 1 — Diagnose & scope

Preflight — find the memory directory. Claude Code memory lives at ~/.claude/projects/<project-slug>/memory/, where <project-slug> is the working directory path with / → -. A user may have memory across several projects — list them with ls ~/.claude/projects/*/memory/ and pick (or merge) the project(s) whose memory holds the cross-tool user content.

List every file under that memory directory. Classify each by scope, not by "is it messy". Full decision table and the agent-can't-judge-private-context caveat: read references/diagnosis_and_scoping.md.

The short version:

  • Team rules / standards / SOPs → project CLAUDE.md or docs/ (version-controlled, team-visible).
  • Cross-tool user profile / collaboration preferences / methodology / personal affairs → ~/.claude/references/user/ (tool-agnostic). This is the bucket that migrates.
  • Temporary handoff snapshots / external system pointers → stay in memory. This is memory's legitimate purpose; do not migrate them. (Goal B: these go to documents instead, see references/retire_auto_memory.md §4.)

Before calling any entry "not covered anywhere", search every place that could own it: global and project instruction files, ~/.claude/references/, every skill source repository (public and private), project docs and handover packs, and hook or script headers. Name all of these roots in any sub-agent prompt — an agent searches only the roots it is told about. Calibrate each search command on a string you know exists before trusting a zero.

Do NOT migrate everything. Over-migrating handoff state into long-lived docs is its own mistake. But do look at the whole directory — not just feedback_*.md — because project SOPs and operational war-stories often sit in project_*.md or architecture_*.md files and belong in the repo's docs.

Also flag private-context / PII in this pass: a memory file that maps system usernames to real names, private contacts, or other personally identifying information should stay in private memory even if it is project-relevant. Project docs are version-controlled and potentially shared; identity-mapping belongs in the thin handoff layer.

Phase 2 — Tool-agnostic migration

Snapshot CLAUDE.md first (cp ~/.claude/CLAUDE.md ~/.claude/CLAUDE.md.bak) — you're about to edit it. If ~/.claude/CLAUDE.md doesn't exist, create it (some users only have a project-level one).

If command -v codex is empty (Codex not installed): do only steps 1 and 4 below (the references/ + inline-CLAUDE.md work), and skip the symlink (2), config (3), and all of Phase 5. The content migration still stands; leave a note that wiring Codex later needs the symlink + project_doc_max_bytes.

For each "migrates" item, move the content into ~/.claude/references/user/ (group by theme into a handful of files + a user-profile.md hub). Then wire the two-layer architecture:

  1. Inline the hardcore into a # User context section near the top of ~/.claude/CLAUDE.md (within the first ~32 KiB so Codex sees it): the 3–6 facts that must hold every turn (e.g. how to address the user, hard preferences, the single most important identity fact). Everything else stays as pointers.
  2. Symlink ~/.codex/AGENTS.md → ~/.claude/CLAUDE.md (only if ~/.codex/AGENTS.md is absent or an empty placeholder — never clobber a real file).
  3. Raise project_doc_max_bytes in ~/.codex/config.toml if CLAUDE.md exceeds 32 KiB.
  4. Update the project's knowledge-storage rule (if one exists) so "user preferences → memory" doesn't contradict the new "user profile → ~/.claude/references/user/" reality.

Exact directory layout, the hub-and-spoke pattern, and the governance-rule fix: references/tool_agnostic_migration.md.

Phase 3 — Multi-agent review

Spawn 4 review subagents in parallel (one message, multiple Task calls). Each audits one dimension: content completeness (did any fact get dropped/altered), cross-reference breakage (which [[links]] will dangle if memory is deleted), tool-agnostic link integrity (does the symlink/pointer chain actually resolve; does Codex really read it), duplication/drift (does a reference duplicate a CLAUDE.md rule). Exact prompts: references/review_and_verification.md.

Agent findings are hypotheses, not verdicts — filter them (probability × cost × does-it-actually-happen) before acting.

Phase 4 — Fix

Address what review surfaced. Common real findings (all from a live run): a hub file that forgot to index one of its own children; hardcore facts left only in a reference (move them inline); [[links]] in surviving files pointing at to-be-deleted memory (repoint to the new reference); a governance table row updated but the judgment sentence in the same section left contradicting it.

Phase 5 — VERIFY BY RUNNING CODEX (do not skip, do not delegate to the user)

The step you'll be tempted to replace with "looks right" or "you can check it yourself later". Don't. Run codex from any dir with --skip-git-repo-check, match its session log by session id (not by mtime), and grep for your inlined hardcore section + a back-of-file string. The inlined section may be titled # User context, # 用户上下文, or whatever localization the user uses — grep for the actual heading string, not a hardcoded English one. A passing run greps 1 for that heading and 1 for the back-half string (if CLAUDE.md > 32 KiB). The exact, empirically-verified command block — --skip-git-repo-check, session-id extraction (it's in the header, not the tail), the 32 KiB check, plus the < 32 KiB and codex-not-installed shortcuts and expected console output — is in references/review_and_verification.md. Use it verbatim; don't hand-roll a variant here (that's how the two copies drift).

Show full SKILL.md (755 more words)Show less
Phase 6 — Memory cleanup

For the memory files that did NOT migrate, do one of three things (decision detail in references/diagnosis_and_scoping.md):

  • Clean — expired (past-dated handoffs) or stale (derived counts that should be computed, not stored) → archive.
  • Thin — a handoff that restated a SSOT living elsewhere → cut the duplication, keep only the pointer + the volatile state (e.g. "instance X still billing, shut it down").
  • Keep — legitimate handoff / already a clean pointer → leave it. (Not in Goal B: everything is archived.)

Update the memory index (e.g. MEMORY.md) to drop migrated entries and add one migration pointer.

Before moving anything, grep the whole memory dir AND the project docs / CLAUDE.md for references to the files you are about to archive. A surviving file or active doc that links to an archived file ends up with a dangling reference. Repoint those links to the new doc location or to a plain-text pointer. Memory cross-links are not the only risk — project CLAUDE.md and handoff docs often cite memory files by name.

Soft-delete, never hard-rm. Move migrated/cleaned files to a dated backup dir outside memory/ (e.g., a sibling ~/.claude/projects/<slug>/.memory-archive-2026-07-06/ — use the actual current date, not a placeholder). Putting the archive inside memory/ leaves it readable as live memory, defeating the cleanup. Update the index pointer to the new outside-memory path. Tell the user they can rm the backup after a couple of weeks of confirming both tools behave.

After a migration that taught you something new, update this skill. If you hit a failure mode not listed in references/failure_cases.md, append it; if a step was underspecified, tighten the SKILL.md checklist. A skill that isn't fed back its own lessons will repeat the same mistakes.

Do NOT (each one learned by getting it wrong in a live run)

  • Don't reach for "delete" first. The instinct is to delete messy memory. Wrong order: first classify migrate / thin / keep. Most "messy" memory is either migratable value or legitimate handoff — deleting loses the value.
  • Don't assume reference + pointer = tool-agnostic. A pointer is on-demand in both tools. The hardcore facts must be inlined into CLAUDE.md body, or they silently won't load.
  • Don't believe Codex follows text pointers. It reads the AGENTS.md/CLAUDE.md file itself, not paths written inside it. Verified against official docs + a real session log.
  • Don't forget Codex's 32 KiB doc truncation. A long CLAUDE.md loses its back half in Codex unless project_doc_max_bytes is raised. The user may have been running half a CLAUDE.md for months without knowing.
  • Don't change a governance table row and leave the judgment logic in the same section contradicting it. Grep the whole section after editing one fact.
  • Don't delete a memory file before grepping for [[cross-references]] to it. A surviving file pointing at a deleted one becomes a dangling link.
  • Don't let an agent batch-decide what to delete/keep when the content depends on the user's private context. Agents lack "what the user actually values"; surface candidates, let the user (or you, with full context) decide.
  • Don't make the user verify. Running codex and grepping the log is agent-doable — own the verification loop, don't hand it back.
  • Don't treat "the symlink exists" as Codex verification. A correct symlink is necessary but not sufficient; the only proof is a real codex exec session whose rollout log contains your inlined hardcore section.
  • Don't put the archive inside memory/. It remains readable as live memory there, defeating the cleanup. Move it to a sibling dir outside memory/.
  • Don't migrate real-name identity maps or PII into project docs. Project docs are version-controlled and shared. If a memory file maps user3 → <a coworker's real name>, keep it in private memory (thinned to a pointer if the SSOT lives elsewhere) — do not move it to docs/.
  • Don't overwrite an existing doc with a memory duplicate without diffing first. Many memory files are partial duplicates of docs (e.g., architecture_v2_decision.md vs docs/decisions/2026-02-21-v2-architecture.md). Migrate only the unique details; append them to the existing doc rather than replacing it.
  • Don't forget to repoint links in project docs, not just memory. CLAUDE.md and handoff docs often cite memory files by basename. Grep them before archiving.
  • Don't accept a sub-agent's "no home found" without knowing which roots it searched. Three inventory agents that were never told about the private skill repo sent two already-documented entries back as "needs migration".
  • Don't turn auto memory off globally to retire one project's memory. The global switch silently stops every other project's memory from loading; use the project's .claude/settings.local.json.

Failure cases (the full war-stories)

The reasoning behind the Do-NOTs, with what actually broke each time: references/failure_cases.md.

© daymade, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 7 other files (scripts, references) in daymade-claude-code/claude-migrate-memory-to-doc of daymade/claude-code-skills.

  • SKILL.md
  • references/diagnosis_and_scoping.md
  • references/failure_cases.md
  • references/retire_auto_memory.md
  • references/review_and_verification.md
  • references/tool_agnostic_migration.md
  • scripts/migrate_verbatim.py
  • tests/test_migrate_verbatim.py

Open the folder on GitHubat commit 872127b

Compare with similar skills

Claude Migrate Memory To Doc next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Claude Migrate Memory To Doc compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Claude Migrate Memory To Doc this skilldaymade/claude-code-skills1.4k—~4.1kAutomated safety check: PassMIT
Neat-Freak Knowledge CloseoutKKKKhazix/khazix-skills21k—~1.9kAutomated safety check: PassMIT
Beads Task Memorygastownhall/beads28k—~1.2kAutomated safety check: PassMIT
Reflect on Session Learningscursor/plugins10k5 repos~1.2kAutomated safety check: PassNone
MemPalace Memory SearchMemPalace/mempalace59k—~1.4kAutomated safety check: PassMIT
Compound Learning WriterEveryInc/compound-engineering-plugin25k—~2kAutomated safety check: PassMIT

Similar skills

  • Neat-Freak Knowledge Closeout

    KKKKhazix/khazix-skills

    Brings project docs, agent rule files, authorized memory and leftover workspace files back in line with what the code and runtime actually do at the end of a work session.

    21k GitHub stars~1.9k tokensUpdated 8 days ago
    Agent WorkflowsAuto-check passed
  • Beads Task Memory

    gastownhall/beads

    Tracks multi-session work with dependencies in the bd issue tracker so the agent can find ready tasks and recover its context after conversation compaction.

    28k GitHub stars~1.2k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Official

    Starts three parallel reviewer subagents over the current conversation transcript, then turns their findings into concrete edits to existing skills.

    10k GitHub starsUsed in 5 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • MemPalace Memory Search

    MemPalace/mempalace

    Mines project files and conversation exports into a local, searchable memory palace and recalls past work by semantic search through the mempalace CLI.

    59k GitHub stars~1.4k tokensUpdated 2 days ago
    Agent WorkflowsAuto-check passed
  • Compound Learning Writer

    EveryInc/compound-engineering-plugin

    Records one solved and verified problem as a durable learning in the repository, but only when the reasoning is not already clear from the final code, tests or docs.

    25k GitHub stars~2k tokensUpdated 2 days ago
    Agent WorkflowsAuto-check passed
  • Searches past Claude Code, Codex and Cursor sessions and summarizes what was worked on, tried or decided, using extraction scripts instead of reading raw logs.

    24k GitHub stars~3.1k tokensUpdated today
    Agent WorkflowsAuto-check passed

More from daymade/claude-code-skills

All 103 skills in this repo
  • Video Comparer

    daymade/claude-code-skills

    This skill should be used when comparing two videos to analyze compression results or quality differences.

    1.4k GitHub starsUsed in 1 repo~1.4k tokens
    Auto-check: notes
  • CLI Demo Generator

    daymade/claude-code-skills

    Generates professional animated CLI demos as GIFs using VHS terminal recordings.

    1.4k GitHub stars~1.7k tokensUpdated today
    Auto-check passed
  • Doc To Markdown

    daymade/claude-code-skills

    Converts DOCX/PDF/PPTX and saved HTML/HTM to high-quality Markdown with automatic post-processing.

    1.4k GitHub stars~2.5k tokensUpdated today
    Auto-check passed
  • Interaction Design Board

    daymade/claude-code-skills

    Generates several distinct, clickable HTML interaction prototypes for one product surface into a Design Board and collects selection/remix feedback before implementation.

    1.4k GitHub stars~2.7k tokensUpdated today
    Auto-check passed
  • Auto Repo Setup

    daymade/claude-code-skills

    Diagnoses and repairs repository setup and guarded Git workflows for Claude Code or Codex — environment repair, startup sync, hook auditing, collaborator handoff.

    1.4k GitHub stars~2.8k tokensUpdated today
    Auto-check: notes
  • Bigdata Skill

    daymade/claude-code-skills

    Pulls Bigdata.com (RavenPack) financial and news data via the official bigdata-client SDK and /v1/ REST endpoints — structured financials, prices, analyst estimates, entity-sentiment series…

    1.4k GitHub stars~3.7k tokensUpdated today
    Auto-check passed

Categories

Questions about Claude Migrate Memory To Doc

What does Claude Migrate Memory To Doc do?

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…. Claude Migrate Memory To Doc is an agent skill from daymade/claude-code-skills.md (Codex primarily) can read the same user profile and preferences.

When should I use Claude Migrate Memory To Doc?

Claude Migrate Memory To Doc fits situations like: the user says migrate my memory; my memory is locked to Claude Code; make Codex/Cursor read my profile; reports memory has grown bloated with content that should be shared across tools.

How do I install Claude Migrate Memory To Doc in Claude Code?

Run `npx skills add daymade/claude-code-skills --skill claude-migrate-memory-to-doc -a claude-code`. Or copy the skill folder (daymade-claude-code/claude-migrate-memory-to-doc in daymade/claude-code-skills) into .claude/skills/claude-migrate-memory-to-doc in your project. Claude Code loads it when a task matches its description.

How do I install Claude Migrate Memory To Doc in Codex?

Run `npx skills add daymade/claude-code-skills --skill claude-migrate-memory-to-doc -a codex`. Or copy the skill folder (daymade-claude-code/claude-migrate-memory-to-doc in daymade/claude-code-skills) into .agents/skills/claude-migrate-memory-to-doc in your project. Codex loads it when a task matches its description.

Can I use Claude Migrate Memory To Doc in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add daymade/claude-code-skills --skill claude-migrate-memory-to-doc -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/claude-migrate-memory-to-doc, .gemini/skills/claude-migrate-memory-to-doc, .github/skills/claude-migrate-memory-to-doc and .opencode/skills/claude-migrate-memory-to-doc in your project.

What does Claude Migrate Memory To Doc need to run?

Going by SKILL.md and its folder, Claude Migrate Memory To Doc needs Python for the scripts in its folder and the command-line tools its instructions call (codex). Our summary lists: Python 3.

Does Claude Migrate Memory To Doc access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Claude Migrate Memory To Doc safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Claude Migrate Memory To Doc use?

Claude Migrate Memory To Doc is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Claude Migrate Memory To Doc use?

About 4.1k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 7.8k tokens, read only when the agent opens those files.

What are the alternatives to Claude Migrate Memory To Doc?

Skills that share tags, products or a category with Claude Migrate Memory To Doc: Neat-Freak Knowledge Closeout (KKKKhazix/khazix-skills, 21k stars), Beads Task Memory (gastownhall/beads, 28k stars), Reflect on Session Learnings (cursor/plugins, 10k stars) and MemPalace Memory Search (MemPalace/mempalace, 59k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Claude Migrate Memory To Doc?

daymade (a GitHub user) maintains it in daymade/claude-code-skills, which has 1,447 GitHub stars. The repository holds 103 skills in this directory. The repository was last updated on October 9, 2026.

Source: daymade/claude-code-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.