rename

name	rename
description	This skill should be used when the user asks to "rename the project memory folder", "change the memory folder name", "rename project X in memory", "give this project's memory a different name", or invokes /tm:rename [new-name]. Renames a project's store folder prefix — the -8hex identity suffix is always preserved, so resolution keeps working from every clone and host. Updates the global index row and any config overrides pointing at the folder. The rename is always confirmed before anything moves.
argument-hint	[project-id] <new-name>

tm — rename a project's memory folder

A project folder is projects/<prefix>-<8hex>. The 8-hex suffix (sha256 of the project key) is the identity anchor — the guard resolves projects/*-<8hex> — while the prefix is purely human-facing. A rename therefore changes only the prefix: memory keeps resolving everywhere with zero re-linking. Auto-trigger only on a clear user ask to rename; the move is always confirmed first.

Guard (run first, always)

Run ${CLAUDE_PLUGIN_ROOT}/scripts/tm-guard.sh "$PWD" and read its KEY=VALUE output. If TM_STATUS is not OK, stop and follow the repair flows in <MEMORY_DIR>/references/bootstrap.md (if the store does not exist yet, the same file ships in the plugin at ${CLAUDE_PLUGIN_ROOT}/references/bootstrap.md). Do not continue until the guard prints TM_STATUS=OK. Keep MEMORY_DIR, PROJECT_ID, and PROJECT_PATH for the steps below.

1. Resolve the target and the new name

1. Interpret the arguments:
   • one argument → rename the current project (the guard's PROJECT_PATH) to that name;
   • two arguments → the first is a project id (or store-relative projects/... path), the second the new name;
   • none → list ls <MEMORY_DIR>/projects/ and ask which folder to rename and to what.
2. Kebab-case the new prefix (lowercase, non-alphanumerics collapsed to -). The new folder is <new-prefix>-<8hex> carrying the target's existing suffix — never accept a name that drops or alters the suffix; it is the identity.
3. Stop and report if the target folder does not exist, or the destination folder already does.

2. Confirm and apply

1. Show old → new folder names plus everything that will be touched — the folder move, the global/INDEX.md ## Projects row, any matching project_overrides entries in config.json (and, for a nested store, that the surrounding repo's workflow owns the commit). Confirm via AskUserQuestion (proceed / adjust / cancel) before moving anything.
2. Move the folder: mv "<MEMORY_DIR>/projects/<old-id>" "<MEMORY_DIR>/projects/<new-id>".
3. Update the project's row in global/INDEX.md under ## Projects: the id text and the [[../projects/<id>/INDEX|index]] link both switch to the new id.
4. Sweep leftover store-relative references: grep -rl "projects/<old-id>" "<MEMORY_DIR>" and fix any hits (promotion backlinks and the like) — links must keep resolving inside the store.
5. Update the machine-local config — every project_overrides value equal to projects/<old-id> becomes projects/<new-id> (keys and all other config content preserved):

CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/turing-mem/config.json"
python3 - "$CONFIG" "projects/<old-id>" "projects/<new-id>" <<'PY'
import json, sys
path, old, new = sys.argv[1:4]
with open(path) as f:
    cfg = json.load(f)
ov = cfg.get("project_overrides") or {}
changed = [k for k, v in ov.items() if v == old]
for k in changed:
    ov[k] = new
with open(path, "w") as f:
    json.dump(cfg, f, indent=2)
    f.write("\n")
print(f"updated {len(changed)} override(s)")
PY

6. If the store is its own git repo (its git toplevel is <MEMORY_DIR> itself), run git add -A && git commit -m "mem(<new-id>): rename from <old-id>" from <MEMORY_DIR>. Nested store: skip — the parent repo's workflow owns the commit.
7. Re-run the guard and verify. When the current project was renamed, expect PROJECT_ID=<new-id> and PROJECT_EXISTS=true (suffix resolution finds the new folder).

Notes

• config.json is machine-local and never synced: hosts that resolve by derived id or suffix need nothing after a rename, but any other machine that pinned the old path via /tm:link must re-run the override fix (step 5) there. Mention this when overrides were updated.
• Renaming never touches note content, INDEX.md frontmatter (key, last_consolidated), or history — it is a folder-prefix move plus link upkeep.

Codex fallback

Rename edits config.json, so it is a Claude-Code-first flow. On Codex, confirm in plain text ("rename <old-id> → <new-id> — proceed? yes/no"), then run the same steps 2–7 by hand.