Working across your projects
The common question is “how do I install it into this repo?” The happy answer is that you don't — here's how it fits code you already have.
It's already in every project
You install the plugin once per machine, so the team is available in every project you open in Claude Code — your existing apps, a new repo, a scratch folder. You don't install it “into” a repo and you don't reinstall it per project. Open a project, talk to a teammate, and they read that project's real code to help.
A codebase never becomes a hub
The hub is where the memory lives. If every repo were its own hub, your business would split into a dozen separate Brains and nothing could consolidate them. So a repo gets a pointer home instead — a small .capsho-hq/link.json file naming its hub:
$ node <path-to-the-clone>/scripts/setup.mjs link <path-to-your-hub>
Or just say set me up while you're standing in the repo and Monty works out that it's a project rather than a business, and links it.
It stays out of your pull requests
The pointer is excluded via the repo's.git/info/exclude, which is local and never committed — so it never turns up in a teammate's diff, and you don't have to edit .gitignore to hide it.After that, every session inside that repo starts already reading the right business's Brain. Several repos for one business is fine — link each one, or keep them under projects/ in the hub.
Teach it a codebase in one go
Don't want to wait for the team to pick things up as it works? From inside the repo, say:
$ learn my codebase
That's Theo. He reads the repo end to end, runs your dev, build, test and lint commands to find out which ones actually work, maps where things live, names the fragile corners, and writes the lot into that project's own CLAUDE.md — which every future session in that repo reads automatically. If anything faces the outside world he also runs a short security pass and reports what he finds in plain language.
It's read-only, by law
Theo changes nothing during a study — no formatting fix, no stray import, no “while I'm here”. If he finds a bug he names it and keeps going; fixing it is a separate job you ask for separately. Run this once when the team first meets a repo, or after a big change — not every session.Your live files are protected by default
When work would land on a live file, it gets moved onto a draft copy first and you're told so in the same breath. Your memory and settings are deliberately exempt, because drafting those would be absurd: Brain/, Desk/, Library/, .capsho-hq/, .claude/ and the files sitting directly at your business root all edit in place.
One consequence, written down as a rule
A site or app kept underLibrary/ is not protected — Library/ is memory, and the rule is applied literally, so edits there land on the live version with no draft in between. Code belongs under projects/.More than one person
Being straight with you: CapshoHQ is built for one person, or two people who share a machine. Each person installs the plugin on their own computer, and the hub is a folder on disk — there's no account, no sync service, and no built-in way to keep two people's Brains in step.
You can of course put a hub folder somewhere you both reach. It isn't a feature we ship, test or support yet, so we're not going to write you a recipe for it and pretend otherwise. If you need it, tell us — it's the kind of thing that gets built because someone asked.
