Set up Memmo

From the repo root:

npx @memmo/cli init

It signs you in if this machine isn't yet (your browser opens once) and creates your first project from the repo name if you have none. In CI, memmo login --token or a MEMMO_TOKEN variable does the sign-in.

It registers the repo (from its git remote) in a project, then writes:

.mcp.json                 # the Memmo MCP server (runs via npx — nothing to install)
CLAUDE.md                 # a short section telling the agent how to use memory
.claude/settings.json     # hooks: SessionStart · UserPromptSubmit · PreToolUse · SessionEnd

Commit these three. Teammates who clone the repo are told how to join on their first Claude Code session. Then say yes to the scan: Claude Code reads the codebase and proposes starter memories to your inbox.

Every Claude Code session in that repo now:

• starts with a briefing — rules, architecture, key commands, known risks;
• recalls what matters for the task when you type a prompt;
• is warned before editing risky files;
• proposes new memories when it ends — including corrections to outdated ones.

The agent can also call the tools directly:

get_repo_context()          → the briefing
search_memory(query)        → approved memories, ranked by meaning
get_relevant_warnings(files)→ risks for the files about to change
propose_memories([...])     → record something worth keeping (goes to the inbox)

Inbox is where proposals wait for a human — approve, edit, reject, or set confidence thresholds to auto-triage. Memory is everything approved, as a list and as a map of how memories link and replace each other. Live shows what each session was told.

Approved memory reaches agents three ways, all on by default:

• In the session — the briefing, recall and warnings above (Claude Code hooks, or the tools for any MCP agent).
• In the repo — rule files: CLAUDE.md & co written from memory, plus a tree of small files, for any agent and any teammate.
• In the pull request — the reviewer checks diffs against what the team knows.

Under Sources → Knowledge sources, point Memmo at documents that already exist: a standards folder in a tooling repo (read with your GitHub account), a Notion page (with an integration token), a URL, or pasted markdown. Each source is fetched into documents, the extractor proposes memories from what they say, and they are refreshed daily so corrections flow through. A document can also be written into the repo's memory tree in full, under .memmo/memory/docs/, for agents to read.

Memory types are yours too: under Settings → Memory types you can reword the built-in ones or add your own — say, “API contract” — with a description the extractor matches against, a section for briefings and rule files, and the tasks it should be recalled for.

A project is the set of repos that share one memory — one monorepo, or many services. Each memory applies to every repo in the project or to specific ones. An organization holds projects, members and billing; belonging to it is enough to use its projects.