second-brain-os: Skill for Claude Code

migrate-work

Pulls your existing work into your PARA workspace. The signal is your past Claude and Codex sessions stored locally on your Mac, not a blind scan of your folders. It reads what you've actually been working on across Cowork, the Claude Desktop Code tab, the Claude Code CLI and Codex. It shows you the distinct projects it found that don't already have a home. For the ones you pick, it scaffolds clean PARA entries with a CLAUDE.md + memory.md, copying any real work files in (never moving them). It also brings over what Claude and Codex already remember about you (your global instructions, Claude Code's auto-memory, Codex's memories): facts about you go to USER.md, how you want the assistant to work goes to SOUL.md, and project notes go to that project's memory.md. You see every line before anything is written.

Why sessions, not a folder scan: your work could live anywhere; your sessions are the reliable record of what you actually do. Each session carries a title, a working directory, dates, and (while it still exists) a transcript. That's enough to recognize a project and seed its memory.

Hard invariants (DO NOT VIOLATE)

• M1 — COPY, NEVER MOVE. Originals are never moved, renamed, or deleted. Bring work in with cp/rsync; the user's source folders stay exactly where they are. A move that loses someone's only copy of real work is unrecoverable.
• M2 — DISCOVERY IS PURE READ. Phase 1 (enumerate sessions, read transcripts, scout-summarize) touches nothing on disk. No write happens before the approval gate. Every probe verb is read-only. Session stores and memory stores are never modified, and neither is cleanupPeriodDays or any other setting.
• M3 — ONE APPROVAL GATE. Exactly one human stop: the barrier between discovery and writes. Nothing is scaffolded or copied until the user explicitly selects items. Low-confidence/flagged items are never auto-applied.
• M4 — NO FABRICATION. Every discovered "project," summary, and seeded memory line traces to real session content. Never invent a project, a purpose, or a decision the transcript doesn't show. If a session is ambiguous, flag it for the user — don't guess. Recency-derived metadata (suggested_status, date range) is allowed ONLY as a LABELED inference confirmed at the approval gate. A session whose transcript is purged has only its title, folder and dates: say so, seed no decisions from it, and never reconstruct content from the title. Imported memory lines are written as they stand in the source file (only list markers, YAML quoting and Codex's internal file pointers removed): never reworded, merged, summarized or completed.
• M5 — CODE PLACEMENT. Runnable code stays in its existing standalone repository or, after the user identifies an owning Area, may be copied into <workspace.areas>/<area>/apps/<app>/ (ignored by the outer repo). NEVER copy runnable code into tracked Projects, Resources, or Inbox paths (a COD project's ignored app/ is the only Projects exception, and only with approval).
• M6 — NEVER AUTO-COMMIT. Writes create new files in the workspace; stop at the diff and surface a manual commit command. Never git add/git commit.
• M7 — TRANSCRIPT HYGIENE. Scouts read only the user's prompts and the assistant's prose. They never read tool_result blocks, attachments or hook output, since that's where file contents, env dumps and tokens land. Seeded memory paraphrases in a few words; it never quotes a transcript verbatim and never carries a credential, key, URL token or personal identifier. Assistant prose can contain these too (cloud IDs, account IDs, people's names and emails echoed back from a tool), so scouts scrub them from everything they return, not just from tool output. Memory lines are the user's own notes and are imported as written, with two exceptions: a line that looks like a credential is never written and never echoed, only reported by file and line; and a line carrying another person's contact details (email, phone) is shown at the gate marked as such, never preselected.