The harness

What .claude/ is, why it is checked in, and how it onboards you.

The harness

.claude/ is the harness — the config that makes an agent work the way we work. It is checked into the repo on purpose. Clone be-internal and you inherit the operating model. You don’t get told about it, you get handed it.

One repo means one harness, shared by every area:

be-internal/.claude/
├── settings.json      pre-approved commands
└── agents/            the five roles, defined once
    ├── researcher.md
    ├── historian.md
    ├── librarian.md
    └── designer.md

Areas do not get their own teams. Same five agents everywhere; only the subject matter changes.

settings.json — the advisor, and permission to finish

{
  "advisorModel": "opus",
  "permissions": { "allow": [
  "Bash(npm run:*)", "Bash(sh scripts/*)",
  "Bash(git add:*)", "Bash(git commit:*)",
  "Bash(git push:*)", "Bash(git fetch:*)", "Bash(git worktree:*)",
  "Bash(gh pr create:*)", "Bash(gh pr merge:*)",
  "Bash(gh pr view:*)", "Bash(gh api:*)",
  "Bash(open https://internal.beliefengines.io*)" ] } }

advisorModel turns the advisor on for every session in this repo, so it is never something you remember to pass. It must be at least as capable as the main model — on Opus 5 that means Fable or another Opus (why).

Every command in the loop is pre-approved. That is the point — an agent that stops to ask four times per typo is not an agent, it is a form. Validate, commit, push, open the site: all of it lands without a prompt.

The allowlist is also the boundary. Nothing destructive is on it — no --force, no reset, no rm. Widening it is a deliberate act, in a commit.

Onboarding is one command

  clone ──▶ @be-category-name ──▶ working
                    │
                    ├─ cwd = the area
                    ├─ rules loaded
                    ├─ five agents up
                    └─ advisor attached

There is no briefing step and no setup command to run first. You type the name of the area and you are working in it — see the entry point.

Two configs, not a hierarchy

Precedence, not nesting. Both are one level; the repo one wins.

   ~/.claude/                    be-internal/.claude/
   yours, on your machine        ours, in git
   how you personally work       how this repo gets worked on
            └────────── the repo wins ──────────┘

Your global config never leaves your machine. The repo harness is shared, versioned and reviewable — when the way we work changes, it changes in a commit someone can read.