init

name

init

description

This skill should be used when the user asks to "set up turing-mem", "initialize the memory store", "init tm", "repair the memory store", accepts an offer to set up after a guard reports a non-OK status, or invokes /tm:init. Creates config.json and the memory dir, adopts an existing store, scaffolds the current project folder, and walks the bootstrap repair flow. Every significant step is confirmed with the user before acting — nothing is created without explicit approval.

tm — init

First-run setup / repair for the turing-mem store. This skill is the interactive front-end for the repair flows in references/bootstrap.md — that file is the authoritative playbook; follow it exactly. Auto-trigger only on a clear user ask for setup/repair (or an accepted offer) — never from mere inference; every significant step below is confirm-gated, so nothing is created or changed without explicit approval.

1. Guard (always first)

Run:

${CLAUDE_PLUGIN_ROOT}/scripts/tm-guard.sh "$PWD"

It prints TM_STATUS, MEMORY_DIR, PROJECT_ID, PROJECT_PATH, PROJECT_EXISTS, OVERRIDE, STORE_VERSION, PLUGIN_STORE_VERSION. Then read the repair playbook: <MEMORY_DIR>/references/bootstrap.md when the store exists, else the plugin copy at ${CLAUDE_PLUGIN_ROOT}/references/bootstrap.md. The reported TM_STATUS selects the flow below.

2. Repair flow by status

Confirm every significant step via AskUserQuestion before acting (proceed / adjust / cancel).

NEED_INIT — config missing/unparsable, or memory_dir absent

1. Confirm creating ${XDG_CONFIG_HOME:-$HOME/.config}/turing-mem/config.json.
2. Ask where the memory dir should live — suggestions first: probe ~/turing-mem, ~/.turing-mem, and ${XDG_DATA_HOME:-~/.local/share}/turing-mem for an existing store (.turing-mem/manifest.json present) and offer each found store as its own option, then the default ~/turing-mem (create fresh), then a custom path. Never ask bare "where?" with no options.
3. Write the config with python3, creating parent directories. Keys: memory_dir (absolute path string) and project_overrides ({} if absent). Preserve any parsable existing content.
4. If the chosen dir has no store yet, scaffold it: ${CLAUDE_PLUGIN_ROOT}/scripts/tm-scaffold.sh store <memory_dir> — creates .turing-mem/manifest.json, AGENTS.md, CLAUDE.md, references/, and global/.
5. If the new store is not already inside a git repo, offer git init (recommended: durable writes then commit as mem(<project-id>): <gist> and unconfirmed log checkpoints become revertible). On yes, run git init and an initial commit of the scaffold. If it is already inside a larger repo (e.g. a synced vault), skip the offer — that repo's workflow owns memory commits.
6. Re-run the guard.

NEED_ADOPT — dir exists but has no .turing-mem/manifest.json

1. Show the directory; confirm adopting it as a turing-mem store, or choosing another path (loop back to the NEED_INIT flow, step 2).
2. On adopt, follow the bootstrap.md adopt flow: write the manifest, then fill in any missing store files with tm-scaffold.sh store (it must not clobber existing content — check bootstrap.md).
3. Re-run the guard.

NEED_MIGRATE / READ_ONLY — store version mismatch

All writes are blocked. NEED_MIGRATE (store older than the plugin pin): follow the migration guidance in bootstrap.md — in v0.1 only store_version 1 exists, so this indicates a corrupted manifest; inspect .turing-mem/manifest.json with the user. READ_ONLY (store newer than the plugin pin): instruct the user to update the plugin (/plugin marketplace update then reinstall). Reads remain available via /tm:recall.

OK with PROJECT_EXISTS=false — store fine, no project folder matches

The guard already matched both the derived name and the projects/*-<hash> suffix, so this state means no folder exists for this project's key.

1. Derive identity: ${CLAUDE_PLUGIN_ROOT}/scripts/tm-project-id.sh "$PWD" prints KEY=, NAME=, HASH=, PROJECT_ID=.
2. Confirm the folder name via AskUserQuestion. The folder is <prefix>-<HASH>: the suffix is the identity anchor (the guard resolves projects/*-<HASH>), so the prefix is purely human-facing and renameable later with /tm:rename. Offer:
   • <NAME> (recommended) — the session working-directory name;
   • the repo name from the key, when the key is remote-based and that name differs from <NAME>;
   • a custom prefix (kebab-cased; the -<HASH> suffix is always kept);
   • or link this directory to an existing project folder instead (/tm:link, e.g. a no-remote project created on another host).
3. On create: ${CLAUDE_PLUGIN_ROOT}/scripts/tm-scaffold.sh project <MEMORY_DIR> <chosen-prefix>-<HASH> <KEY> — scaffolds INDEX.md (frontmatter key: <KEY>, last_consolidated: never), MEMORY.md, notes/, log/.

OK with PROJECT_EXISTS=true

Nothing structural to repair. Run ${CLAUDE_PLUGIN_ROOT}/scripts/tm-status.sh "$PWD" and check STALE_DOCS: when non-zero, the store's plugin-owned docs (references/, AGENTS.md, CLAUDE.md) predate the current plugin — list STALE_DOC_LIST, confirm via AskUserQuestion, then run ${CLAUDE_PLUGIN_ROOT}/scripts/tm-scaffold.sh refresh <MEMORY_DIR> (overwrites only those docs, never notes/logs/MEMORY.md/indexes). Otherwise report the guard block to the user and stop.

3. Verify

Re-run the guard and confirm TM_STATUS=OK and PROJECT_EXISTS=true before reporting success. Report: memory dir, project id and path, whether an override is active, and whether the store is a git repo.

Codex note

Setup is a Claude-Code-only flow (bootstrap.md says the same). On Codex, do not run this flow interactively — direct the user to complete init in Claude Code, or to hand-edit config.json and run tm-scaffold.sh per bootstrap.md.