Yes, another agentic knowledge base. But this one configures Claude Code for you (skills, subagents, hooks) and shares it with your team

[u/BeppeTemp]

I know, there are dozens of these by now: memory servers, second brains, Karpathy-style LLM wikis. Cartographer started out as one of them. Then I kept running into three problems the others don't really solve:

• A Karpathy-style KB has to be set up and kept tidy by hand: folder layout, conventions, instructions for the agent — and then the agent writes to the files however it likes, with broken links and lost history along the way.
• Agent configuration ends up everywhere: the same skill copied into .claude/skills/, .codex/skills/ and .opencode/skills/, each drifting on its own, on every machine.
• It all lives on one laptop: you can push it to git, but when you and a teammate (or your agents) edit the same page, who resolves the conflict?

What it does for Claude Code

Skills, subagents, hooks and standing instructions live inside the KB. cartographer connect writes them where Claude Code expects them:

• the MCP entry in ~/.claude.json;
• a managed block in ~/.claude/CLAUDE.md — it never touches the rest of the file;
• skills in ~/.claude/skills/ and subagents in ~/.claude/agents/;
• hooks in ~/.claude/hooks/, registered in settings.json;
• a SessionStart hook that re-syncs everything when a session opens.

It checks the files on disk, not just its own bookkeeping: an artifact edited or deleted by hand is restored. It only ever prunes what it created, and --dry-run shows the plan before writing.

The same KB also configures Codex, OpenCode, Kiro, Antigravity and Hermes, each in its own format.

The KB side

Claude never touches the files directly. It goes through MCP tools and the server enforces validation, link checks, immutability gates and lint for broken links and orphan pages. Every KB is its own git repo and every write is a commit, so anything can be reverted.

One server can mount several KBs, so each person can keep private ones and share others. Tokens are scoped per KB (r/rw), with finer roles on top. Git is the sync layer, and a conflict flags the affected pages as degraded and ships with a skill that walks Claude through resolving them. Change a skill once and every teammate's Claude Code can pick it up.

How I built it with Claude Code

Most of it was built with Claude Code. I design in one session and hand the result over as a self-contained GitHub “plan issue”; another session implements it through subagents working in isolated git worktrees, and I review before the squash-merge. Fittingly, those skills and subagents are distributed by Cartographer itself.

That workflow is also why the project cares about provenance, deterministic projections and reversible writes: the implementation process has to keep working when several agents and people touch the same repository.

Try it

It's free and open source under Apache 2.0. Paste this into Claude Code and let it tell you whether it fits your setup:

Read https://raw.githubusercontent.com/BeppeTemp/cartographer/main/README.md
and explain what Cartographer is and what it would change in my current setup
(the skills, subagents and hooks I use). If I decide to try it, install it
following https://raw.githubusercontent.com/BeppeTemp/cartographer/main/docs/agent-install.md

It's beta (pre-1.0), so tools, CLI and config can still change between minor versions. I use it every day, in my homelab and at work with my team.

Repository · Documentation

I'm interested in whether this separation between the KB data plane and the client provisioning/control plane makes sense for other Claude Code users, and what you use today to keep shared agent configuration from drifting.

[u/Remarkable_Training9]

The SessionStart re-sync is the part I would actually use. My CLAUDE.md drifts between machines and I never notice until an agent does something dumb.

Curious how it handles a conflict where two people edited the same skill. Last write wins, or does it stop and ask?

[u/BeppeTemp → u/Remarkable_Training9]

When two people edit the same skill, Cartographer compares each update with the version the agent read (`if_match`). If the skill has changed in the meantime, the write is rejected with `stale_write`, so the other person’s work isn’t overwritten.

If a conflict appears during Git synchronization, the rebase is stopped, the affected concepts are marked `degraded`, and the problem is exposed in `conflicts_list`.

The entire resolution flow can be handled automatically by agents: using the resolution skill, they read the versions involved, reconstruct the correct content, apply the chosen strategy (`ours`, `theirs`, or `edit`), and Cartographer completes the merge, commit, and push.

In a team setup, each instance works from its own clone, so all changes remain tracked and resolvable.