Basic Memory Setup

Basic Memory setup

Run a short, adaptive interview (~2-3 minutes) and then write the configuration. Be conversational and skip questions whose answer is already obvious from context (e.g. if list_memory_projects shows a single local project and no cloud workspaces, don't ask about cloud/teams — just confirm). Suggest a sensible default for every question so the user can accept with one word. Don't do any writes until the interview is done and you've confirmed the plan.

Prerequisite check

First confirm the Basic Memory MCP server is connected — call list_memory_projects. If that tool isn't available or errors, Basic Memory isn't wired into Claude Code yet. Stop and walk the user through it first (everything below depends on it):

1. Install it: uv tool install basic-memory --prerelease=allow (or pip install basic-memory), version >= 0.19.0. Keep --prerelease=allow with uv: published releases pin a FastMCP pre-release, and without the flag uv silently installs an older Basic Memory release.
2. Connect it: claude mcp add basic-memory -- uvx --prerelease=allow basic-memory mcp, then restart the session so the MCP server loads.

Re-check list_memory_projects before continuing — don't start the interview until it succeeds.

Interview

Ask only what you can't infer. Cover:

1. Focus / how you'll use it. "What will this project mostly be — code/dev, research, writing, knowledge capture, planning, or a mix?" This answer drives the folder structure you suggest (step 4) and is stored so the SessionStart brief can surface it. If you infer it instead of asking, state the use-case you assumed and the structure it implies so the user can correct it in one word.

   A code/dev answer makes this a coding setup (sessionProfile: "coding"): verify the directory is inside a Git repository, resolve a stable repository identifier such as owner/name from the origin remote or GitHub CLI, show it to the user, and ask for confirmation. Do not guess when the remote is missing or ambiguous, and do not infer coding merely because the current directory is a Git checkout — for mixed use, ask whether this repository should capture Git and pull-request context. The coding profile seeds the Coding Session schema so deliberate checkpoints carry required, queryable Git identity (repository, branch, SHA, and working directory), plus typed pull-request fields when a PR exists.

2. Project mapping. "Do you already have a Basic Memory project for this, or should I create one?"

   • Existing → show list_memory_projects() and let them pick. That name becomes primaryProject.
   • New → propose a name (default: this repo's directory name) and create it with create_memory_project.
     • Local project (default): path defaults to ~/basic-memory/<name>/; any connected Basic Memory server can create it.
     • Cloud project (the user wants capture in a cloud workspace): pass the workspace selector (a slug from list_workspaces) and a cloud-style path like /<name>, and create it with a cloud-connected MCP server. A purely local server (uvx --prerelease=allow basic-memory mcp) treats the path as a local directory and fails to create it (e.g. read-only /). When both a local and a cloud server are connected, route creation and the schema seeding through the cloud one, and pin primaryProject to the new project's external_id UUID (collision-proof across workspaces).

3. Cloud / teams (skip if there are no extra workspaces). Run list_workspaces. If the user belongs to more than one workspace, they likely have a team workspace alongside their personal/default one. Use list_memory_projects to see the projects in each (note: project names collide across workspaces, so always use the workspace-qualified name, e.g. my-team-2/notes, or the external_id UUID — never a bare name).

   • Read from the team (recommended): ask which team projects to pull into the session brief for recall. Store their qualified names in secondaryProjects. These are read-only — recall reads across them; nothing is written to them. Cap: the SessionStart brief reads only the first 6 shared projects per session (a latency/output bound), in list order. If the user wants more than six, order the most relevant first and tell them the rest are configured but not read each session.
   • Share target (optional): if the user wants a place to publish notes to the team via /basic-memory:bm-share, add it to teamProjects as "<qualified-name>": { "promoteFolder": "shared" }. Sharing is always a manual gesture — auto-capture never writes to a team project.

   Keep primaryProject a project the user owns for their own capture; team projects are for reading and deliberate sharing only.

4. Placement — learn or suggest (depends on the project's state). The goal is a short placementConventions string (3-6 lines) telling you where new notes go. How you get it depends on whether the project already has notes:

   • Existing project with notes → learn. Inspect it: list_directory for the folder layout, sample a few notes per folder (and, where a folder holds recurring typed notes, you may run schema_infer to see their shape). Summarize the real conventions — folder-by-topic layout, naming style, the observation categories they favor. Infer from their actual notes; don't impose.
   • New or empty project → suggest (there's nothing to learn yet). Propose a light structure that fits the focus from step 1 — 3-5 optional top-level folders, no deep taxonomy — and be explicit that it's a starting point, not a scaffold: notes work fine without it and structure can stay emergent. Don't create empty folders; folders appear as notes land in them. Let the user edit or decline in one word. Either way, keep it short and store the result as placementConventions. The SessionStart brief surfaces it (alongside captureFolder), so this is what makes your captures land where the user expects — without it, placement is guesswork.

5. Schemas. "I'll add the session schema for this profile, plus decision and task schemas, so I can find them precisely later — okay?" (See "Seed the schemas" below.)

6. Lifecycle-event capture. "The plugin keeps a local trail of SessionStart and PreCompact events for diagnostics by default. Keep that on?" Default to on. Explain that the normal session brief and PreCompact checkpoint work either way; capture adds bounded lifecycle metadata to a local inbox until bm hook flush archives it locally. It never creates knowledge-graph notes. Persist the JSON boolean false only when the user opts out.

   • Capture stays local and personal. It never writes directly to team projects.

7. How active should I be? (output style) "Want me to proactively capture — search the graph before recalling, write material decisions as typed notes, and cite permalinks? Or keep it quiet (just the session brief, the PreCompact checkpoint, and /basic-memory:bm-remember on demand)?" Enabling it sets outputStyle: "basic-memory". Default to enabled; leave it off for a recall-only, low-noise setup. (This is the single knob for how proactive the assistant is — the hooks always run regardless.)

8. Shared skills (optional, default yes). "Want the full Basic Memory toolkit — the shared memory-* skills (memory-notes, memory-tasks, memory-research, memory-schema, memory-defrag, …)? I can install them alongside this plugin." These are the canonical, framework-agnostic skills (the same set OpenClaw bundles). This plugin ships only the Claude-Code-specific glue and pulls the shared set on demand — it doesn't vendor its own copies. (See "Install the shared skills" below.)

Apply (after confirming the plan)