Claude Code for Teams: Worktrees, CI, and Shared Config
Deploy Claude Code across your team with shared configuration, git worktrees for parallel development, and CI/CD integration.
Why teams need shared Claude Code configuration
When one developer on your team uses Claude Code with a carefully crafted CLAUDE.md and another uses it with no configuration, the output quality varies wildly. Code generated by the first developer matches team standards. Code from the second developer introduces inconsistencies — different naming conventions, different error handling patterns, different file organisation. Shared configuration solves this. By committing .claude/settings.json and CLAUDE.md to your repository, every team member gets the same Claude Code experience. The same hooks run on every save. The same coding standards are enforced. The same custom commands are available. This is not just about consistency — it is about institutional knowledge. Your CLAUDE.md captures decisions that otherwise live only in developers' heads: why you use this library instead of that one, how error boundaries work in your app, what the naming convention is for API routes. New team members get onboarded through the CLAUDE.md. It answers questions they did not know to ask. The configuration also evolves with the team. When someone discovers a useful hook or command, they add it and the whole team benefits. Your Claude Code setup becomes a shared, version-controlled asset — like your linting config or CI pipeline.
Shared CLAUDE.md patterns
For a monorepo, create a root CLAUDE.md with global standards and directory-level CLAUDE.md files for each package. The root file covers: overall project architecture, shared coding standards, cross-package conventions, and deployment rules. Each package's CLAUDE.md covers: that package's tech stack, its specific patterns, and its testing approach. For example: root CLAUDE.md says "All packages use TypeScript strict mode. Shared types live in packages/shared/types." The packages/api/CLAUDE.md says "This is a Fastify API. Routes go in routes/. All routes validate input with Zod." The packages/web/CLAUDE.md says "This is a Next.js app. Use server components by default. Tailwind for styling." For multi-team setups, each team maintains their own directory-level CLAUDE.md while the platform team maintains the root. This mirrors your org structure — platform sets the standards, teams apply them to their domain. Review your CLAUDE.md files quarterly. Remove rules that are no longer relevant. Add rules for recurring issues. Keep them concise — a 1,000-word CLAUDE.md that nobody reads is worse than a 200-word one that everyone follows.
Git worktrees for parallel AI-assisted development
Git worktrees let you have multiple working copies of the same repository checked out simultaneously, each on a different branch. This is a game-changer for Claude Code because you can run multiple Claude Code sessions in parallel — each in its own worktree, each on its own branch, each working on a different task. Without worktrees, if Claude Code is refactoring your authentication system, you cannot use it for anything else until it finishes. Your single working directory is mid-refactor. With worktrees, you create a separate checkout: git worktree add ../my-project-auth feature/auth-refactor. Now you have two directories: your main working copy and a separate one for the auth work. Start Claude Code in each. They work independently and do not interfere with each other. Practical pattern: keep your main worktree for code review and small fixes. Create temporary worktrees for each significant feature or refactoring task. Each worktree gets its own Claude Code session. When the work is done, merge the branch and remove the worktree: git worktree remove ../my-project-auth. This mirrors how CI systems work — each job gets a clean checkout. The mental model is simple: one task, one worktree, one Claude Code session. Parallelism without conflicts.
CI/CD integration
Claude Code runs in non-interactive mode with the --print flag (or -p), making it usable in CI/CD pipelines. This unlocks automated AI-powered workflows that run on every push, pull request, or scheduled trigger. Automated code review: add a CI step that runs claude -p "Review the changes in this PR. Check for bugs, security issues, and style violations. Output as a markdown checklist." with the PR diff piped in. Post the output as a PR comment using your CI platform's API. Test generation: when a PR adds new code without tests, trigger a CI job that runs claude -p "Generate unit tests for the new functions in this PR" and opens a follow-up PR with the generated tests. Changelog generation: on merge to main, run claude -p "Based on the merged PRs since the last release, generate a changelog entry in Keep a Changelog format." and commit the update to CHANGELOG.md. The key to CI integration is deterministic prompts. Your CI prompts should be specific, structured, and version-controlled — treat them like code, not casual conversation. Store them in .claude/ci-prompts/ and reference them by path. This ensures reproducible results and makes it easy to iterate on prompt quality across your team.
Measuring team productivity with Claude Code
You cannot improve what you do not measure. When deploying Claude Code across a team, track metrics that show real impact — not vanity metrics. Core metrics to track: time-to-merge (how long from PR open to merge), review turnaround (how long until a PR gets its first review), defect rate (bugs found in production after Claude Code-assisted development versus before), and developer satisfaction (monthly survey — do people feel more productive?). Use the /cost command data to track Claude Code usage per developer and per project. High usage is not inherently good or bad — what matters is the outcome. A developer spending heavily on Claude Code but shipping faster with fewer bugs is getting excellent ROI. Track what Claude Code is used for. If 80 percent of usage is code review and test generation, that tells you those are the highest-value use cases for your team. Invest in better hooks and commands for those workflows. Avoid measuring lines of code generated — this is a meaningless metric that incentivises bloat. Instead measure tasks completed per sprint, time spent on boilerplate versus creative work, and the ratio of generated code that survives review unchanged. Run a baseline measurement before rolling out Claude Code, then measure again after 30, 60, and 90 days. This gives you the data to justify expanding the investment — or to identify where the workflow needs adjustment.
Security and access controls for team deployment
Deploying Claude Code across a team requires thoughtful security controls. The core principle: Claude Code should have the minimum access needed for each task, and that access should be auditable. API key management: never share a single API key across the team. Each developer should have their own key, linked to their identity. This enables per-developer usage tracking and the ability to revoke access individually. Use environment variables or a secrets manager — never hardcode keys in configuration files. Repository access: Claude Code inherits the permissions of the user running it. Ensure developers only have access to repositories they need. In a monorepo, use directory-level .claude/settings.json to restrict which tools are available in each package. MCP server access: scope MCP servers to the minimum required permissions. The database MCP should use read-only credentials. The GitHub MCP should be limited to specific repositories. The Slack MCP should only access designated channels. Audit logging: configure hooks to log all Claude Code actions — files read, files written, commands executed, MCP tools used. Store these logs centrally for compliance and incident investigation. Policy documentation: write a clear "Claude Code Usage Policy" covering what it can and cannot be used for, how to handle sensitive data, and what requires human review before merging. Commit this policy as .claude/POLICY.md and reference it in your CLAUDE.md.
Claude Code at Scale
This guide is hands-on and practical. The full curriculum covers the conceptual foundations in depth with structured lessons and quizzes.
Go to lesson