Claude Code for Teams — Shared Workflows and Cowork Patterns

The cowork concept

Cowork is the pattern of multiple engineers operating from the same Claude Code foundation: the same skills, the same configuration defaults, and the same permission policies, all committed to the repository and therefore consistent across every machine that clones it.

Without this kind of shared foundation, each engineer develops their own informal conventions — specific prompts they type repeatedly, personal configuration files that live only on their laptop, habits about which tasks to hand to the AI and which to do manually. This is fine individually, but it does not scale. When one engineer leaves, the institutional knowledge about how the AI tooling was configured leaves with them. When a new engineer joins, they rebuild the same configuration from scratch. And when the team wants to audit what AI-assisted changes were made, there is no consistent record.

The cowork approach moves that knowledge into the repository. Skills become code. Configuration becomes a checked-in file. Workflows become reviewable artifacts. The team improves skills through pull requests the same way they improve application code. That shift is small in implementation terms and significant in practice.

Shared skills

The shared skill library is the core of a team Claude Code setup. It lives under .claude/skills/ in the repository root and is automatically discovered by the CLI when any engineer starts a session in that repository. No registration step is required; the CLI reads the directory on startup.

Managing the shared library works like any other part of the codebase. New skills go through pull requests. Changes to existing skills are reviewed by the engineers who use them. Deprecations are handled by removing the skill file and leaving a note in the commit message. The review process also serves as skill documentation: the conversation about whether a skill's tool manifest accurately reflects what it does tends to produce much better descriptions than writing the documentation in isolation.

Teams typically accumulate skills in three categories: release and deployment automation, code quality checks, and project-specific knowledge (like how to run a particular integration test suite or how to apply the project's migration pattern). The first two categories often apply across projects; the third is project-specific and belongs in the project repository rather than a shared registry.

Shared configuration

The shared configuration file (.claude/settings.json) specifies the team defaults that every session should start from. Common settings include the default model tier for interactive work versus automated batch tasks, which skills load automatically, the permission threshold for shell commands, and any MCP server connections that the whole team uses. Individual engineers can override specific values in a personal .claude/settings.local.json that is listed in .gitignore.

Keeping the shared config minimal is generally better than loading it with every possible preference. The shared file should express the team's agreed defaults — the settings where consistency matters. Personal preferences — preferred editor integration, notification style, session verbosity — belong in the local override. When the boundary between shared and personal is unclear, err toward shared: a setting that one engineer needed for a reason is probably useful for the rest of the team too, and they can always override it locally if not.

Collaboration patterns and review workflows

In a team workflow, Claude Code proposes changes; engineers review and approve them; the result goes through the normal pull request process. This sequence looks similar to pair programming, except the AI takes the first pass rather than a colleague. The review burden is different: instead of reading a colleague's code from scratch, you are reviewing a diff that the AI produced against your instruction. That is typically faster because the instruction context is fresh, but it requires discipline — it is easy to approve a diff that looks right without reading it carefully.

Teams that have adopted Claude Code successfully tend to set an explicit norm around AI-assisted reviews: treat the AI's output the same as you would treat a junior engineer's output. Read the diff. Ask why a particular approach was taken if it is not obvious. Run the tests locally if the change touches something complex. The AI does not get a lighter review because it is fast; speed is not the same as correctness, and the cost of merging a wrong change is the same regardless of who wrote it.

Research on collaborative human-AI development workflows, including studies published through Carnegie Mellon's School of Computer Science, points to review quality as the primary determinant of output quality in assisted workflows. The tooling is not the constraint; the review habit is.

Team patterns and configuration paths

The table below shows common team adoption patterns, where the relevant configuration lives, and what team size the pattern is typically suited for.

Team pattern	Config path	Typical size
Shared skill library only	.claude/skills/ in project repo	2–10 engineers
Shared config + skills	.claude/settings.json + .claude/skills/	5–20 engineers
Shared config + MCP connections	.claude/settings.json with mcp block	10–30 engineers
Cross-repo skill registry	Enterprise registry path in org settings	20+ engineers
Enterprise managed rollout	Centrally administered; SSO + audit enabled	50+ engineers

Onboarding new engineers

One of the clearest benefits of the shared configuration approach shows up during onboarding. A new engineer clones the repository, installs the CLI, and immediately has access to the same skills and defaults the rest of the team uses. The onboarding documentation shrinks because much of what used to be written instructions — "remember to run this migration check before every deploy" — is now a skill that the CLI can invoke on demand.

The remaining documentation covers things the CLI cannot help with: architecture decisions, team conventions around code review, escalation paths, and the social context of the codebase. Separating the procedural from the contextual makes both parts better. Procedures belong in skills. Context belongs in documentation. When the two are mixed in a single runbook, the procedural parts go stale and the contextual parts get lost in the noise.