checkup

name

checkup

description

This skill should be used when the user asks to "run a memory checkup", "check up on my memory", "take care of my memory", "tidy up memory", "do whatever memory needs", "what should memory do next", or invokes /tm:checkup. Auto triage across the whole turing-mem surface - one status read, then a priority ladder picks the single best next action (repair, link, doc refresh, consolidate, checkpoint, commit reminder) and dispatches the matching verb. When the project is unresolved it searches the store for candidate folders and presents concrete choices. Every action goes through that verb's own confirm gates; nothing is decided silently.

tm — checkup (auto triage)

The "just handle it" verb: read the current state once, walk a priority ladder, propose the single most valuable next action, and on approval dispatch the matching tm verb — which then runs exactly as written, including all of its own confirmation gates. This skill decides what; the dispatched skill decides how. It never duplicates another verb's procedure and never writes anything itself (the one exception: a log checkpoint via the remember flow, which is unconfirmed by design).

1. Gather state (one script run)

Run:

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

Keep the full KEY=VALUE block: TM_STATUS, MEMORY_DIR, PROJECT_ID, PROJECT_PATH, PROJECT_EXISTS, OVERRIDE, KEY_MISMATCH, STORE_VERSION, PLUGIN_STORE_VERSION, STALE_DOCS/STALE_DOC_LIST, STORE_GIT, STORE_DIRTY, UNCONSOLIDATED_LOGS, LAST_CONSOLIDATED, LAST_CHECKPOINT, plus the note/log counts.

2. Triage ladder — first match wins

Walk top to bottom; the first rung that matches is the proposal. Ignore everything below it for now (the loop in step 4 comes back). Rungs 1–3 use the candidate-search in step 3 to offer concrete choices instead of a bare "run /tm:init".

1. TM_STATUS ≠ OK → the store itself needs attention. For NEED_INIT, probe the likely store locations first (~/turing-mem, ~/.turing-mem, ${XDG_DATA_HOME:-~/.local/share}/turing-mem — a dir with .turing-mem/manifest.json) and offer the concrete choices up front: each found store, the default ~/turing-mem (create fresh), or a custom path — then run the /tm:init flow with the choice. For NEED_ADOPT / NEED_MIGRATE / READ_ONLY, dispatch /tm:init for that status.
2. PROJECT_EXISTS=false → no project memory resolved for this session directory: run the candidate search (step 3) and present its choices.
3. KEY_MISMATCH=true → the resolved folder's recorded key differs from this directory's derived key. Show both keys and the folder, then offer: link this directory to the right folder (/tm:link, usually correct), or create a separate new project (step 3 choices).
4. STALE_DOCS > 0 → the store's plugin-owned docs predate the plugin: offer the confirm-gated refresh (tm-scaffold.sh refresh <MEMORY_DIR>, per the status skill).
5. UNCONSOLIDATED_LOGS ≥ 10 → checkpoint backlog: run /tm:consolidate.
6. Uncaptured work in this session — the conversation contains a decision, root cause, non-obvious fix, or user correction newer than LAST_CHECKPOINT and not yet in log/ → write a checkpoint via the /tm:remember flow (its normal unconfirmed tier-1 write). Judge this from the conversation itself; when the session has no such content, skip.
7. STORE_DIRTY=true with STORE_GIT=own-repo → memory changes sit uncommitted: offer the store commit (git add -A && git commit -m "mem(<PROJECT_ID>): <gist>" from <MEMORY_DIR>). Nested store: skip this rung — the parent repo's workflow owns commits.
8. LAST_CONSOLIDATED more than ~a month old on a project with active notes → memory may have gone stale rather than merely backlogged: suggest /tm:retro (suggest only; retro auto-runs nothing).
9. Nothing matched → memory is healthy. Report a 3-line digest (project id, note/log counts, last consolidated + last checkpoint) and stop.

3. Candidate search — concrete choices for an unresolved project

When the store exists but this directory has no project (rung 2, and the create branch of rung 3), never present a bare "init or link?" — gather evidence first:

1. Derive identity for the session working directory: ${CLAUDE_PLUGIN_ROOT}/scripts/tm-project-id.sh "$PWD" → KEY, NAME, HASH, PROJECT_ID. (Identity is anchored on the session dir, not the git root — a subfolder of a larger repo is its own project.)
2. Search the store for existing folders that might already be this project:
   • ls <MEMORY_DIR>/projects/ and compare each folder's name prefix against NAME (shared tokens, one containing the other);
   • grep -l the derived KEY — and its meaningful fragments (the repo path, the session-dir basename) — across <MEMORY_DIR>/projects/*/INDEX.md frontmatter keys;
   • read the one-line summaries in global/INDEX.md ## Projects for topical matches.
3. Present one AskUserQuestion with the concrete options (best candidates first, max 4; "Other" covers custom input):
   • Link to <candidate-folder> — one option per strong candidate, showing its recorded key and one-line summary so the user can recognize it;
   • Create <NAME>-<HASH> — the suggested new folder, named after the session dir (mark Recommended when no candidate matched);
   • Create with a different name — same suffix, user-chosen prefix.
4. Dispatch the choice: link → the /tm:link flow mapping this session directory to the chosen folder; create → the /tm:init create flow with the chosen prefix. Each flow's own confirmations still apply.

4. Propose, dispatch, loop

1. State the matched rung in one line — what was found and which verb fixes it — and confirm via AskUserQuestion (do it / show full status instead / stop). One action per proposal, never a batch.
2. On approval, invoke the matching skill and follow it exactly as written — its guard runs again, its own confirmations still apply (this skill's confirmation does not replace them; a consolidation or promotion still asks on its own).
3. After the action completes, re-run step 1 and walk the ladder again. Offer the next rung the same way. Stop when rung 9 is reached or the user declines a proposal.
4. "Show full status instead" → present the /tm:status report, then re-offer.

Codex fallback

Same ladder, same one-action-at-a-time flow; confirmations in plain text ("found N unconsolidated checkpoints — consolidate now? yes/no"), candidate choices as a numbered list. Claude-Code-only rungs (init, link) follow the bootstrap.md harness note: direct the user to Claude Code or the hand-edit path.

Additional resources

• ${CLAUDE_PLUGIN_ROOT}/skills/status/SKILL.md — the report this triage is built on.
• <MEMORY_DIR>/references/bootstrap.md — repair flows for rungs 1–3 (plugin copy at ${CLAUDE_PLUGIN_ROOT}/references/bootstrap.md if the store does not exist yet).