Shared infrastructure

The repo is the config

The capstone track has one job: turn one fluent person into a team that ships agents weekly. This lesson turns the setup into infrastructure: two canonical repos, a team skills marketplace, a written role table, and an onboarding path you have timed on a clean machine. Ten weeks in, everyone has personal fluency - but fifteen people with fifteen slightly different setups is not a system, it is fifteen experiments. The fix is one principle from the official guidance: the repo is the config. Everything that defines how your team uses Claude Code lives in git, and a new machine inherits it by cloning.

• CLAUDE.md - how we work, what we never do. Shared behavior.
• .claude/settings.json - permissions, hooks, sandbox config. Shared enforcement.
• .claude/skills/ and the org skills plugin - shared procedures.
• .claude/rules/ - modular, path-gated guidance.
• .mcp.json - shared tool connections, secrets as ${VAR} placeholders.

The two repos every org needs

If you followed the foundation track, these mostly exist. Week eleven is where you make them canonical and complete:

• The workspace repo - the company brain, project structure, root CLAUDE.md, and the baseline .claude/settings.json. The default place every session opens.
• The skills repo - the org's skill library packaged as a plugin, installed by every machine from your private marketplace, owned and reviewed like the asset it is.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env*)",
      "Edit(./archive/**)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "python3 .claude/hooks/guard.py" }
        ]
      }
    ]
  }
}

Remember the precedence rules from the foundation track: settings merge across managed, local, project, and user scopes; permission rules merge with deny winning everywhere. So the committed project file sets the floor, individuals can tighten in settings.local.json, and nobody can quietly loosen what the team decided.

The company brain is the team's shared context

The workspace repo earns its keep when it stops being a folder and becomes the company brain: the one place every session, every agent, and every new hire reads first. We run our own company this way. One monorepo holds every client build and every internal system, and a new build starts by reading it, not from a blank page. The pieces that make it work:

• Root CLAUDE.md as the index: who we are, how we engineer, where things live, hard rules. Short, and the only file most sessions need to find everything else.
• Self-describing folders: every project ends with its own CLAUDE.md header saying what it is. No central list to maintain, so the index never goes stale.
• A hand-maintained "current best" table: per dimension (UI, cleanest code, outbound pipeline, LLM cost engineering, deploy setup), which prior build to copy. It is the one list a human updates by hand, and it is the reason a new build inherits the best version of each piece instead of any version.
• ICP, voice, and positioning as files, not in people's heads. One copy each: our signal ICP lives in one YAML file that two different engines read, and both refuse to run if it is missing. A second copy is a guarantee the two will disagree within a month.
• Hybrid search over the brain: local keyword plus vector search over every Markdown file, including a few hundred call transcripts, wrapped in a skill that tells Claude to search before answering from memory. No API call, re-indexes in seconds.
• A foundation skill pack installed into every project's .claude/skills/ by one install script: engineering standard, agent building (model routing, caching, cost caps), subagents and context, self-verify, ship-to-own, and a spend policy. Improve a skill once in the brain and every project picks it up on its next install.

Team skills: ship them through a plugin marketplace

Skills live in three places, and the choice is about who should get them: a project's .claude/skills/ (everyone who clones that repo), your own ~/.claude/skills/ (just you), or a plugin in a team marketplace (every machine, versioned, updated in the background). For anything the whole team runs, use the marketplace. A marketplace is a git repo with a .claude-plugin/marketplace.json listing your plugins.

{
  "name": "acme-tools",
  "owner": { "name": "Ops team" },
  "plugins": [
    {
      "name": "gtm-skills",
      "source": "./plugins/gtm-skills",
      "description": "List build, pre-launch audit, verification"
    }
  ]
}

1. Validate before you push: claude plugin validate ./acme-tools. It catches bad JSON, missing fields, and relative paths that use ...
2. Teammates register it once: claude plugin marketplace add your-org/acme-tools, then claude plugin install gtm-skills@acme-tools. The install id is always <plugin>@<marketplace name>.
3. Or require it: put extraKnownMarketplaces and enabledPlugins in managed settings (every machine) or in the repo's .claude/settings.json (that repo's contributors, after they trust the folder).
4. Score changes before shipping them: claude plugin eval runs a scored eval suite for a plugin against a no-plugin baseline.

Anthropic's marketplaces as of September 2026: claude-plugins-official is added automatically; the community one is added with /plugin marketplace add anthropics/claude-plugins-community and installed from with @claude-community (not the repo name); anthropics/skills provides the document-skills and example-skills plugins. Browse at claude.com/marketplace/plugins.

Role-based defaults

Not everyone needs the same leash length. The practical way to do roles without enterprise tooling: per-project settings. Each role's main working repo carries the settings that fit its risk profile.

• Builders (your champions, ops leads) - fuller allowlists, hooks as the guardrail, sandbox on. They build the skills others run.
• Operators (most of the team) - auto mode (the built-in starting mode for interactive sessions since v2.1.283, September 2026) with a generous read allowlist, write actions behind asks, side-effect skills locked to human invocation with disable-model-invocation: true.
• New joiners (first two weeks) - plan mode as the habit, everything reviewed, paired with a champion. The trust ladder from the foundation track, formalized.

Auto mode is now where every interactive session starts unless you say otherwise. claude -p and the Agent SDK still start in Manual (the mode formerly labeled "default"). If a role should start elsewhere, set defaultMode in that person's user settings or in managed settings, not in the repo. An admin can turn auto mode off org-wide with permissions.disableAutoMode: "disable".

Onboarding: the one-hour setup

The test of your infrastructure is the next hire. Target: from blank laptop to productive, supervised first session in under an hour, with no champion hand-holding beyond the buddy chat.

1. Admin grants the seat (and checks it includes Claude Code - the week-one lesson, still the top blocker).
2. New joiner installs via the native installer, runs claude doctor, logs in, verifies with /status.
3. Clones the workspace repo - and with it inherits CLAUDE.md, settings, hooks, and rules.
4. Adds the skills marketplace and installs the org plugin (skipped if managed settings already require it); /skills confirms the library is live.
5. Runs their first task in plan mode with their buddy watching - the trust ladder starts on day one.

Package this checklist as a skill in your library - a team-onboarding skill that walks the new machine through setup interactively. The docs endorse exactly this pattern; it turns your setup into a replayable guide instead of tribal knowledge.

Do this now

Sources and further reading

• Claude Code documentation
• The .claude directory reference
• Create a plugin marketplace
• Anthropic's plugin marketplaces