---
title: The harness
description: "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:

```text
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

```json
{
  "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](/how-to-fly/the-advisor)).

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

```text
  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](/how-to-fly/the-entry-point).

## Two configs, not a hierarchy

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

```text
   ~/.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.