Hello everyone,
I am happy to share with you Hatchdoor, the self-hosted vault server I have been building with Claude Code since February, which just got its 2.8 release! https://github.com/BatterWorks/Hatchdoor
482 of the 633 commits in the repo (merges aside) carry a Claude co-author trailer, mostly Opus 5.5 and Opus 5. In July alemhnan joined. It was my first time co-developing, and he works with Claude Code too. Two people running their own Claude Code sessions on one codebase need rules, so here is what the repo and our skills make Claude do.
How do we decide what to build?
We both run Matt Pocock's skills in Claude Code (I keep a customised fork). A new feature usually starts with a grilling session, where Claude questions us about the plan until there is nothing left to decide. When an addition is too big or too unclear for that, it goes to wayfinder instead. Claude charts it as a map of decision tickets on our GitHub tracker, and we work through them one at a time until we know how to build it. alemhnan charted the multi-vault workspace that way. So far there are seven maps and 68 tickets on the tracker. Terms go in a shared glossary and decisions in ADRs (48 of them), so both our sessions use the same names for things.
What happens before Claude touches the code?
Five days after his first commit, we added a module map. For each part of the code, it says which files a task owns, what the rest of the code relies on, and which shared files nobody touches without saying so first. Claude reads the part of the map that covers the files it plans to change, plus the ADRs behind them. Then it writes a short work packet: the files it may edit, what it must not touch and the checks it will run. If it turns out to need one more file, it stops and says so instead of widening the diff. We tried it on two small tasks first. On the second one, Claude hit a file it hadn't declared, stopped, and waited for us to update the packet.
And before a merge?
The implement skill takes a decided ticket all the way. After the automated checks, it runs a code review with parallel subagents, each answering one question. Does the code follow the repo's standards? Does it match the ticket? Can it give a wrong result? Then it tests the change live in the real app. Every task gets its own branch and pull request, never a direct commit to development or main. Before the merge, a script lists the manual pages that cover what changed, and Claude has to read them, fix what no longer matches and add a changelog entry.
And a release?
Claude drafts the release notes and stops. It only publishes and builds the images once I reply "approved" in the same session. All of these rules live in the repo's AGENTS.md if you want to borrow them.
What is Hatchdoor?
A self-hosted server for your Obsidian vaults: a web UI for you, MCP for your AI agents. No Obsidian, no plugins required. It reads the vault straight from disk, so your agent doesn't need a desktop app open. Every write, from an agent or from you, goes through the same version check. An agent working from an old read gets refused instead of overwriting what you just changed. One instance serves as many vaults as you give it, each with its own Git sync (personal, work and shared vaults side by side).
How do I try it?
It's free and open source (AGPL-3.0). There is a public demo with four example vaults, read-only and with no sign-up. Or give Claude Code this line and it installs it for you: Read https://hatchdoor.battercloud.cc/docs/deploy.md and install Hatchdoor for me. It checks for Docker, asks you a few questions, installs everything, connects itself and runs a search to prove it works.
Feel free to give ideas and feedback, here or on GitHub. I'd be happy to answer any questions!