xtraceai/memhub

Use when the user wants the MemHub companion — the small animal above the prompt that shows what the plugin is doing — turned on, turned off, swapped for another animal, or explained, or asks about the one-line MemHub status text above the prompt (e.g. "turn on the companion", "activate the goose", "enable my companion", "what is that goose above my prompt", "why do I see only a MemHub status line and no animal", "show me the hippo instead", "turn the companion off", "/memhub:companion"). Checks whether this Claude Code loads it (mods are on by default from 2.1.287), explains that the animal is off by default with a plain status line in its place, shows or hides it, and says what each of its states means.

Use when the user wants to create an engineering rule for the Rulebook (e.g. "/memhub:create-rule", "add a rule that we never force-push", "make a rule for this mistake", "make it actually stop me"). Pins a when-X-then-Y sentence, drafts a deterministic check, and files it for review through the memhub create_rule tool — a rule that advises and a rule that stops the command are filed the same way, and a reviewer turns either one on.

Use when the user wants to hand their current work to one or more teammates so they can pick it up (e.g. "hand this off to Alice", "hand off this session to Bob", "pass this work to Carol and Dan", "share my context with Alice so she can continue", "write a handoff for Bob"). Writes a handoff brief — goal, current state, decisions, next steps, gotchas — into a shared agent brain the teammates search from their own agent. The same set of people always reuses one standing handoff brain, so the history between them stays in one place; a separate one-off brain only when asked. The session transcript itself is never shared.

Use when the user wants a past Claude Code, Codex or Cursor session saved into their memory because automatic capture missed it — a session from before the plugin was installed, one whose upload failed, or one from a host without capture hooks (e.g. "import this session into memhub", "save session abc123 to my memory", "upload yesterday's conversation"). Saves it to the user's own memory, not a team brain, at any size.

Link your coding sessions to a GitHub pull request in MemHub so the team sees the real work behind it — or find which of your past sessions on this machine wrote a pull request and link the ones you approve. Use when the user says e.g. "link this session to PR 42", "/memhub:link-pr", "attach my work to this PR", "unlink that session from the PR", "which sessions wrote this PR", "find the sessions behind my PRs", "map my unlinked PRs to sessions", "link the sessions that built PR 42". Every link is recorded as confirmed, so the PR's session context comes from facts rather than a branch-name guess; found sessions are only candidates until you say yes.

Use when the user wants to sign in to MemHub or sign in again, or MemHub says they are not signed in (e.g. "log in to memhub", "memhub login", "sign in to memhub", "sign in again", "memhub says I'm not signed in", "re-auth memhub"). Signs this machine in, so sessions are saved and team rules apply, and checks that it works.

Use when someone wants MemHub working where they are — a first setup, or a check or repair later (e.g. "onboard", "get started", "set up memhub", "set up my brain", "connect this repo to MemHub", "capture stopped working", "my sessions aren't being saved", "verify capture", "check memhub is working", "remove memhub's hooks"). One command signs in, sets up this machine's hooks, checks capture health, creates or reuses the repo's brain with its docs, offers up to five universal safety rules with one answer, and on Codex asks for the one hook approval only the person can give. Every step is skipped when already done; --status only reports, --remove takes the machine hooks out.

Use when a PR should be babysat to green — poll its review bots (any bot reviewer — Cursor BugBot, OpenAI Codex, the MemHub reviewer, others) and CI, fix the real findings, push, and when clean propose a team rule for any finding that taught something the next PR should not repeat (e.g. "babysit this PR", "watch PR 14 and fix the bot findings", or, on Claude Code only, auto-armed by the memhub hook right after gh pr create — Codex and Cursor do not run that hook, so there it is started by hand). Designed as the body of a self-paced /loop — one poll→fix→push pass per invocation; the final pass proposes rules (usually none) and ends the loop.

Use when the user wants to choose which repositories MemHub is active in, or asks why MemHub is quiet in one (e.g. "enable memhub for this repo", "turn memhub off in client repos", "which repos is memhub on for", "memhub says it is inactive here", "/memhub:repos add ."). Lists, adds or removes repositories on this machine's allowlist, or clears it so MemHub is active everywhere. Outside the listed repositories MemHub does nothing — no team rules, no session capture, no companion.

Use when the user wants a file kept in team memory where teammates and their agents can find it (e.g. "save this spec to memhub", "store this doc for the team", "upload this design doc", "save a new version of this runbook"). Uploads the file as is — to the repo's shared brain when there is one, otherwise to the user's own memory — and versions it when a document of the same name already exists.

Use when the user asks what the team knows, decided or wrote down about something, or what they themselves did in an earlier session (e.g. "what do we know about X", "did we decide on Y", "is there a spec for Z", "what did I do on this last week", "search memhub for W"). Read-only. Looks in the team's shared brain and in the user's own memory, opens the best match, and says which one the answer came from — or plainly that nothing was found.

Use for MemHub spec-driven development — bootstrap specs locally or in MemHub cloud, find requirements before coding, check a working diff, resolve drift, create or revise specs, or diagnose the repository's spec setup. Supports Git-authored specs and explicitly selected governing Brain documents.

Use to freshly check working-tree or pull-request changes against Git ownership specs or governing Brain requirements, investigate spec drift, or verify a proposed spec correction. Also handles /memhub:spec check. Produces cited findings and explicit coverage; does not modify code or specs by default.

Use to bootstrap repository specs locally or in MemHub cloud, create or revise a spec, resolve drift into a reviewable change, or diagnose spec workflow readiness. Also handles /memhub:spec init, revise, bootstrap, resolve, status, and setup. Reads Git or explicitly selected Brain sources without treating generated mirrors as authoritative.

Use when implementing a feature against repository specs, finding requirements before coding, or turning a Git or Brain spec into an implementation plan and acceptance checks. Also handles /memhub:spec work. Do not use merely because an unrelated document is called a spec.

Use when the user wants rules for the Rulebook — a first set for a repo that has none, or rules from what their team actually does. "/memhub:start-rulebook", "set up a rulebook for this repo", "what rules should we start with", "give us the default rules", "bootstrap rules for a new client", "mine our sessions for rules", "turn our CLAUDE.md into rules", "what should be in the rulebook", "backtest this rule", "did the new rules reduce friction" — or right after a Claude Code /insights run. Asks first which the person wants: STARTER rules (a tested catalog of universal coding-agent rules, filled in from a scan of this repo — seconds) and/or rules MINED from their own CLAUDE.md and the last 30 days of local Claude Code / Codex / Cursor sessions (minutes — it reads their sessions). Every candidate is replayed through the real hook and says why it exists, what it cost, and what changes with it on. Hook rules first, session-start notes last. Files survivors as proposed; never activates anything.