Claude Code for teams: what to set up before you scale it

The five building blocks at a glance

CLAUDE.md: shared instructions

A project CLAUDE.md holds what any engineer on the repository needs Claude to know: build and test commands, coding standards, architecture decisions and common workflows. Running /init generates a starting file from the codebase, which you then refine with things Claude could not discover alone.

Keep it short. Anthropic's guidance is to target under 200 lines per file, because longer files use more context and are followed less reliably. Move rules that apply to only part of the codebase into .claude/rules/, where they load only for matching files. Personal preferences belong in a user-level file or in CLAUDE.local.md, not in the shared one.

One point trips up many teams: Claude treats these files as context, not as enforced configuration. Write instructions that are concrete enough to verify, and use permissions or hooks for anything that must never happen.

Permissions: what Claude may do without asking

Permission rules come in three kinds. Allow rules let a tool run without approval, ask rules prompt every time, and deny rules block the call. Rules are evaluated deny first, then ask, then allow, so a broad deny cannot be undone by a narrower allow.

Commit shared rules in the project's .claude/settings.json so every developer starts from the same baseline. For controls that nobody should be able to change locally, administrators deploy managed settings, which user and project settings cannot override. Decide early which permission modes you accept: the default mode prompts on first use of each tool, while others accept edits automatically, restrict Claude to planning, or skip prompts.

Hooks: rules that always run

Hooks are commands that Claude Code runs at specific lifecycle points, such as before a tool call, after one succeeds, or when a session starts. Because they run every time, they suit rules that cannot depend on the model's judgment.

• Block edits to protected files such as .env or lock files with a PreToolUse hook.
• Run the formatter after every file edit with a PostToolUse hook.
• Send a notification when Claude is waiting for input.
• Log tool use to a shared audit service.

MCP servers: connections to your tools

MCP servers give Claude Code access to issue trackers, databases, documentation and internal APIs. A server added at project scope is stored in .mcp.json at the repository root and shared through version control, and Claude Code asks each user for approval before using it.

Anthropic's documentation recommends that one central team configures MCP servers and checks the file into the codebase. It also warns that servers which fetch external content can expose you to prompt injection. Keep the list short, prefer servers you control or trust, and use organization allowlists if you need a hard boundary.

Review practices: keep humans in the loop

• Agent-written changes go through the same pull request review and branch protection as any other change.
• Tests and linters run in CI on every pull request, so problems surface before a reviewer spends time.
• If you add Claude Code to CI through Anthropic's GitHub Action, limit who can trigger it and cap turns and runtime.
• Start new users on codebase questions and small fixes before larger tasks, as Anthropic's rollout guidance suggests.
• Review the instruction file and permission rules on a schedule, the same way you review other shared configuration.

Have BlackCard set it up with you

BlackCard puts these five building blocks in place for small and mid-size companies: the instruction files, the permission rules, the hooks, the MCP servers and the review practice, configured in your own repositories. The same senior team then rolls Claude Code out from a pilot team to every engineer and trains them hands-on in their own codebase. Book a free 15-minute call to go through your setup, in English or German.