How does it work?
ssh in, type claude, say what you want. One harness, flat repos, one CLI.
1. One box, one keystroke
Every employee has a home on the Belief Engines dev workstation. They
ssh in and type claude. That is the whole onboarding.
ssh dev-box ──▶ ~ ──▶ claude ──▶ "I have an idea about zoom transcripts"
│
▼
be wiki new zoom-etl
~/be-wiki-zoom-etl github.com/beliefengines/be-wiki-zoom-etl
The human talks. Claude runs the CLI. See The entry point.
2. Flat, and the name is the map
~/
├── CLAUDE.md AGENTS.md .claude/ the harness, provisioned
├── be-cli/ the CLI
├── be-internal/ this wiki
├── be-wiki-zoom-etl/ one idea
├── be-wiki-onboarding/
└── be-customer-broheim-capital/
Every folder is be-<type>-<name>. Nothing nests. ls ~ is the
inventory; sorting by name is sorting by type. The scheme is
Naming.
3. One harness under everything
be-harness invariant · hashed · one repo
│
├──▶ ~/ every home on the box
└──▶ be-<type>-template ──▶ be-<type>-<name>
.claude/ — the agents, /gm /gn, the rules — is the same in every
home and every repo, copied from be-harness and checked by hash. Edit
it and the push is refused. A type adds its own layer on top; an instance
adds the work. See The harness.
4. Types come from templates
be wiki new, be cli new, tomorrow be customer new — each type is a
be-<type>-template repo in GitHub and one file in the CLI. No type is
invented in a repo name; it is added to the table first. See
The CLI.
5. Agents return pointers
Four core agents everywhere — researcher, historian, librarian, designer — plus whatever the type adds (a wiki has a writer and a reader). Each hands back a path or a URL, never prose. See The fleet.
6. Converge, then graduate
A wiki is one person’s idea. Others pull it, their agents read it cold
and file questions; the author answers. When a stranger’s brief matches
the author’s page and no question is open, it graduates into this wiki as
docs/be-<category>-<name>/. Engineering work leaves as a PR —
Handoff.