migrate-memory

Migrate built-in memory into gutt

Claude Code keeps its own file-based memory store per project. Where it is non-empty, that is organizational knowledge sitting outside the graph — invisible to teammates, to every other project on the machine, and to gutt search. This skill moves it across exactly once, and is the only place in the plugin that deletes a user's memory files.

It builds on memory-capture (how to write), memory-search (how to dedup and verify) and conflict-adjudication (what to do when a local note and the graph disagree) rather than restating them. Migration does not get its own dedup or conflict rules — it is a bulk caller of those skills, and a store is the largest batch of writes the plugin ever makes. Read this file's rules first; they are stricter than the general ones because the local copy is destroyed at the end.

Hard rules (non-negotiable — read first)

1. Ask before anything. Use AskUserQuestion for consent and for scope before the first write. The session-start offer also asks with AskUserQuestion, so arriving here usually means consent to run is already given — that answer covers starting the skill, not the writes. Scope is still unasked, and so is anything you only discovered by reading the files. Where you got here some other way (the user named the skill, or the offer was answered in prose), treat consent as unasked: an offer is not an answer.
2. Back up before you write, verify before you delete. The order is fixed: back up → write episodes → search to confirm they landed → record the confirmations → delete. memory-capture rule 6: a write is queued, not confirmed, so a success response is not evidence. Never delete on a 200.
3. Deletion is the script's job, not yours. Do not rm anything and do not use Write/Edit on the store. store-cli.cjs delete removes only files with a recorded verification, which is what makes an unlanded write cost nothing.
4. Record the answer, including "no". Every terminal answer is persisted per project. A decline must never be re-asked; a completed migration must never be re-offered.
5. Degrade by stopping. No write tool visible, or MCP unreachable → write nothing, delete nothing, say so in one line, and leave the decision unset so the offer returns next session. A partial migration is worse than none.
6. Default to the org group; screen for what must stay personal. Visibility to teammates is the whole point of migrating, so the group is the default. But publishing is the one failure here that restoring a file cannot undo, so read every fact before it goes: anything sensitive — a credential, PII, a note about a named person, or personal preference data — goes to personal scope regardless of what the user picked for the batch.