Skip to content

xtraceai/memhub

v0.71.0Apache-2.0

XTrace MemHub team memory: search_memory / save_artifact / import_conversation MCP tools plus skills for setup, login, onboarding, artifact upload, session import, team-memory recall, session handoff, spec-driven development, Rulebook rule authoring (create-rule) and rules proposed from CLAUDE.md + past sessions in one run (rules-from-sessions), and PR babysitting. A rule lives in a RULEBOOK — a container with its own membership, so it reaches exactly the people that book binds; the authoring skills resolve which book it lands in and offer to create one when there is none. Session auto-capture ships through the host-native plugin layer (hooks are outside the Agent Plugins spec). Session ↔ PR linking: after a call that addresses GitHub (gh pr …, a curl/gh api REST request, or a GitHub MCP tool) whose output names exactly one pull request, a PostToolUse hook asks the backend one question and injects one instruction — a session that ran gh pr create — or the GitHub MCP create tool — links itself unconditionally (opening it is work the session did, and a PR has many sessions), while every other GitHub call, a hand-rolled curl POST included, leaves the authorship judgment to the agent, and an org with no GitHub integration is told once that connecting it is what links sessions to shipped code. The hook is stateless apart from one short-lived negative answer (an enabled org with GitHub disconnected, cached 30 minutes per credential, and never inferred from a reply that merely says the feature is off) and degrades to silence on every failure. Two skills complete it: link-pr (link this or a named session by hand — also the answer for a PR opened by a script or CI helper, which is deliberately not detected) and find-contributing-sessions (scan this machine's local session history for the sessions that wrote a PR's code, rank the candidates by the evidence that matched, and link the ones you approve). The agent records ONE work type for a pull request it links (feat, fix, chore, docs, perf, refactor, other), and only when the PR has none yet — the first label is permanent, and asking again would cost the link, not just the type. Spec workflows: spec-work guides implementation, spec-check freshly reviews changes, and spec-maintain offers local/cloud bootstrap and reviewable Git or Brain proposals through the shared spec entry point.

create-rule
find-contributing-sessions

Use when the user wants to know which coding sessions actually wrote a pull request's code, and to link them in MemHub (e.g. "/memhub:find-contributing-sessions", "find the sessions behind this PR", "which sessions wrote this PR", "link the sessions that built PR 42"). Scans THIS MACHINE's local session history (Claude Code, Codex, Cursor), ranks the candidates by the evidence that matched, and links only the ones you approve.

handoff-session

Use when the user wants to hand off the current session/work to a teammate via MemHub (e.g. "hand this off to Alice", "handoff this session to Bob", "share my context with Carol so she can pick this up", "pass this work to X"). Creates a shareable agent brain holding a handoff brief, and shares it read-only with the teammate along with the repo room where per-turn capture already extracted the session.

import-session

Use when the user asks to import, upload, or save a Claude Code, Codex, or Cursor session/conversation/transcript into MemHub or team memory (e.g. "import this session into memhub", "save session <id> to memhub", "put that conversation in an agent brain"). Ships the transcript via a terminal upload script — any size, no token-by-token re-emit.

link-pr
login

Use when the user wants to authenticate or re-authenticate the MemHub plugin, or when memory capture is not working because of auth (e.g. "log in to memhub", "memhub login", "authenticate memhub", "memhub says I'm not authenticated", "my sessions aren't being saved", "capture stopped working", "re-auth memhub"). Provisions the plugin's own OAuth token — which is SEPARATE from the /mcp connector's login — and verifies it works.

onboard

Use when a new user wants to set up MemHub / an agent brain for their repo, or asks to "onboard", "get started", "set up my brain", or "seed a brain from my work". Crosses the empty-brain cold start — creates the repo's agent brain, seeds it from a real Claude Code session, shows the compiled overview, and proves proactive recall on the repo's own symbols — then reports an activation funnel.

pr-babysit

Use when a PR should be babysat to green — poll its review bots (Cursor bugbot, OpenAI Codex) and CI, fix the real findings, push, and when clean save a PR review record to the repo's MemHub room (e.g. "babysit this PR", "watch PR 14 and fix the bot findings", or auto-armed by the memhub hook right after gh pr create). Designed as the body of a self-paced /loop — one poll→fix→push pass per invocation; the final pass writes the memory and ends the loop.

rules-from-sessions
save-artifact

Use when the user asks to save, store, or upload a file/document/spec to MemHub or team memory as an artifact (e.g. "save this spec to memhub", "store this doc as an artifact", "version this design doc in memhub"). Uploads the file's bytes via a terminal script — never call save_artifact directly or re-emit file contents.

search-memory

Use when the user asks what the team knows, decided, discussed, or saved about a topic, or wants to check MemHub/team memory (e.g. "what do we know about X", "did we decide on Y", "search memhub for Z", "is there a spec for W"). Read-only — searches facts, episodes, artifacts, and documents.

setup

Use when the user asks to set up, repair, or verify the installed MemHub host integration, especially Codex automatic capture, PreToolUse directive recall, hook installation, or capture health. Installs the Codex user-hooks compatibility bridge idempotently while preserving unrelated hooks, then checks plugin authentication and reports the one required trust step.

spec

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.

spec-check
spec-maintain

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.

spec-work

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.