Claude Code for Teams: A Skills Standardization Playbook

Sit five developers down with Claude Code and you’ll get five different tools. One has a CLAUDE.md file with strong opinions about testing. One has never opened the skills directory. One installed a debugging skill off a GitHub thread three weeks ago and forgot to tell anyone. Two are running the defaults, which means Claude guesses at their conventions fresh every session.

The code that lands in your PR queue reflects that split. Some diffs come with tests written first and a clean commit history. Others come with a plausible-looking fix for a bug nobody actually diagnosed. Same model, same repo, same week, five different output qualities, and the reviewer catches all of it by hand.

This is a personal-configuration problem wearing a team problem’s clothes. Individually, each developer’s setup is defensible. Collectively, the team has no floor. Nobody agreed on what “good” looks like when Claude is doing the first draft, so nobody can hold the line on it. This piece is about the fix: project-level skills that live in the repo instead of on laptops, and the governance and rollout that makes them stick.

The fix is where the skill lives, not what it does

Claude Code reads skills from two places. Personal skills sit in ~/.claude/skills/, tied to one machine, invisible to teammates, gone the moment that developer switches laptops. Project skills sit in .claude/skills/ inside the repository itself, committed alongside the code they govern.

That second location is the entire trick. A project skill is a file in git: it gets a diff, a reviewer, a commit message explaining why debugging should follow a hypothesis-first loop instead of whatever felt right that day. When someone improves the skill, the improvement ships to everyone on the next pull, the same way a linter config update does.

Compare that to the alternative most teams reach for first: a wiki page titled “How we use Claude” that three people have read and nobody enforces. A wiki page is advice. A project skill is closer to a dependency: Claude loads its description at the start of every session in that repo and applies it automatically when a task matches, without anyone needing to remember it exists or re-explain it in the prompt.

The practical result is that “our team’s standard” stops being a sentence in an onboarding doc and becomes something Claude actually does, identically, whether it’s the tech lead’s session or the new hire’s session on day one.

What to standardize first

Don’t try to encode your entire engineering culture into skills in one sitting. Three areas cover most of the variance we see between developers on the same team, and each has a tested, scored skill you can point to as a concrete example of what “good” looks like, even if you end up writing your own version tuned to your stack.

A review checklist. The gap between a review that finds real bugs and a review that finds variable-naming preferences is exactly what a good review skill closes. Code Review Checklist scores 8.4/10 in our testing: on a 600-line PR it found one real off-by-one error and two dead-code paths, and produced zero style-only nitpicks. If every reviewer gets that quality of first pass before a human opens the diff, senior engineers spend review time on architecture instead of catching what a checklist should have caught.

TDD discipline. Test-Driven Development, from Jesse Vincent’s Superpowers collection, scores 9.6/10. We ran it across a three-feature session and Claude wrote the failing test first every time, refusing to skip the cycle even with a shortcut available. It’s a pure behavior skill, no scripts or external tools, which makes it the easiest thing to make universal: “write the test first” doesn’t depend on your framework.

A debugging protocol. Systematic Debugging, also 9.6/10, replaces the default “try a plausible fix” loop with reproduce, hypothesize, instrument, verify. In our test it root-caused a race condition that had already survived three guess-based fixes. This is the skill that matters most on a team, because guess-and-check debugging is where the highest-variance output comes from, and a shared protocol collapses that gap.

Three skills. Not the twenty you’ll be tempted to add once the first three work.

Who approves a new skill

Once skills live in the repo, someone has to decide what gets added to it, and this is the part teams skip until it bites them. A skill is instructions Claude follows automatically and sometimes scripts Claude will execute, which puts it in the same trust category as a new npm package or CI action. Nobody would let a developer add an arbitrary dependency to package.json without a PR review. A skill deserves the same gate.

The mechanics are simple once you commit to treating it that way. A new skill enters the repo through a normal pull request, same branch protection as any other change. The reviewer reads the whole SKILL.md, checking for instructions unrelated to the stated purpose and any network call whose reason isn’t obvious. If the skill bundles scripts, someone actually opens them. This is the same two-minute audit we walk through in our security guide.

Assign an owner, one person rather than a committee, usually whoever proposed the skill or a rotating tech lead, responsible for the skill’s description staying accurate and its instructions staying current. When a skill’s trigger phrase starts firing on the wrong tasks, or its instructions drift from the workflow it was written for, that owner fixes it or pulls it.

Version it like everything else in the repo. If a skill changes behavior significantly, that’s worth a note in the PR description and, for anything with real behavioral weight, a mention in standup so people know their sessions will act differently starting today.

Onboarding is the actual killer feature

Here’s the part that’s easy to undersell when you’re pitching this to a skeptical team lead: a new hire clones the repo on day one and gets the same review discipline, the same test-first habit, and the same debugging protocol as the person who’s been there two years. Not because they read a 40-page onboarding doc closely. Because the skills are already sitting in .claude/skills/, and Claude picks them up the moment the new hire opens the project.

Think about what onboarding usually looks like without this. A senior engineer explains the team’s testing philosophy in a 1:1, the new hire nods, and three weeks later half of it has evaporated under deadline pressure, because habits formed under pressure default to whatever’s fastest. With project skills, the discipline isn’t a memory the new hire has to maintain. It’s infrastructure, enforced on their first PR as much as their hundredth.

It also closes the gap across seniority levels. A junior developer’s session running the same debugging skill as a staff engineer’s produces output at a much closer quality level than the two would reach unassisted, because a lot of what separates a good debug session from a bad one is procedure, not experience.

If you haven’t set up the rest of the Claude Code layer yet, that’s worth doing before or alongside this. Our setup guide covers the CLAUDE.md and permissions layers that project skills sit on top of.

How to tell if it’s actually working

Resist the urge to invent a dashboard for this. The signal you want is already flowing through tools you have.

Watch PR review comment volume and, more importantly, comment type. If reviewers start leaving fewer “did you test this” and “this doesn’t handle the null case” comments and more comments about actual design tradeoffs, the review and TDD skills are doing their job. If comment count drops but the comments that remain are still catching correctness bugs the skill should have caught, the skill isn’t tuned right yet, not the team.

Watch regression rate. A debugging skill that enforces hypothesis-verify discipline should mean fewer “fixed” bugs that resurface a week later, since guess-and-check fixes are exactly the kind that come back. This is a slower signal, usually visible over a month or two rather than a sprint, but it matters most for a team that’s been burned by “fixed” bugs before.

Watch time-to-first-approval on PRs, treating one data point as a hint and a sustained shift across several sprints as a real signal. And talk to people: whether developers feel Claude’s output has gotten more consistent, whether a new hire says the codebase felt legible faster than their last job, is worth more than any of the above in the first month.

A four-week rollout for a ten-person team

Week 1. Pick one repo, not all of them, and one skill; the review checklist is usually the easiest sell because reviewers see the benefit immediately. Add it to .claude/skills/ through a normal PR. Get two or three volunteers to use it on their next few reviews and report back in a short thread, not a meeting.

Week 2. Add the TDD skill to the same repo. This is the one that meets the most resistance, since it changes how people write code rather than how they review it. Expect friction and treat it as data. Keep the debugging skill out for now, and collect specific complaints (“it fires on tasks where I don’t want it to”) to fix the skill’s description before you try to fix people’s behavior.

Week 3. Add the debugging skill. By now the team has a feel for how project skills behave, so this addition should go faster. Do a short retro on the two weeks of data: are review comments changing, is anyone quietly avoiding the skills, why. Adjust trigger descriptions if a skill fires too often or not enough.

Week 4. Roll the same three skills out to the rest of the team’s repos. Write a short note in each repo’s README that says what’s in .claude/skills/ and why, so the next new hire doesn’t have to ask. Set the approval process from the section above as a standing rule, since the real test of governance is what happens to the fourth skill someone proposes, not the first three.

Four weeks, three skills, one repo scaled to the rest of the org. Resist compressing this; the friction in week 2 is information you want before you’re running five skills across ten repos.

The plugin option for multi-repo orgs

Project skills solve standardization within a repo, but most engineering orgs aren’t one repo. If your ten developers work across fifteen services, copying .claude/skills/ into each one and keeping them in sync by hand turns into its own maintenance job, the kind that quietly stops happening after the second quarter.

Claude Code plugins solve that layer. A plugin packages a set of skills, plus commands and other configuration, into one installable unit that isn’t tied to a single repo’s git history. Instead of fifteen copies of the same three skills drifting independently, the org maintains one plugin, versioned once, and every repo installs from it. An update to the debugging skill then propagates everywhere the plugin is installed, instead of requiring fifteen separate PRs.

This is a step up in operational complexity, and it’s not worth taking until you’ve felt the pain of keeping multiple repos in sync. For a ten-person team on one or two repos, the project-skills approach in this piece is the right stopping point. For an org running the same standards across many codebases, our plugins guide covers the packaging and distribution mechanics.

The failure mode: mandating twenty skills on day one

The most common way this goes wrong isn’t technical, it’s a rollout mistake. A tech lead reads about project skills, gets excited, and commits twenty of them in one afternoon: review, TDD, debugging, plus a dozen more for logging conventions, commit message format, API design, accessibility, and whatever else seemed reasonable at 4pm on a Thursday.

Two things break. First, overlapping descriptions start firing on the wrong tasks, or on each other, because nobody checked whether skill three’s trigger phrase collides with skill eleven’s; these conflicts are one of the most common defects we see in testing, and they get worse as the count climbs. Second, and more damaging, the team never develops trust in the skills, because a week under twenty new rules feels like a compliance exercise, and people start working around Claude instead of with it.

Three skills, adopted over a month, with real feedback shaping each one before the next arrives, builds trust that twenty skills dropped at once never will. If your team is still deciding where to start, our coding skills rankings are ordered by tested score, which is a reasonable filter for picking the next one after your first three.

FAQ

Do project-level skills work the same as personal ones?

Yes, the format is identical. The only difference is location: .claude/skills/ in the repo instead of ~/.claude/skills/ on a laptop. Claude Code loads both the same way. If a skill exists in both places with the same name, the project version generally takes precedence for that repo, which is exactly the behavior you want for a team standard.

Will this slow down Claude for everyone on the team?

Barely. Each installed skill costs roughly 100 tokens of always-loaded metadata. Three project skills across a team add less standing context than a single connected MCP server typically does. The real cost of getting this wrong isn’t speed, it’s trigger confusion from overlapping descriptions, which is why the rollout plan above adds skills one at a time.

What if a developer disagrees with the team’s TDD or debugging standard?

That’s a conversation to have before the skill merges, in the PR review, the same place you’d have it about a linter rule. Once it’s in the repo it applies to everyone, but “everyone” should mean everyone had a chance to weigh in during review, not that one person decided unilaterally and pushed to main.

Should we require skills or leave them optional?

Project skills load automatically for anyone who has the repo, so there’s no separate “require” step, they’re just part of the codebase. What you can make optional is contribution: not every developer needs to propose new skills, but every developer’s session runs the ones that are merged. Treat the merge decision as the gate.

How is this different from just writing a long CLAUDE.md?

Loading behavior. CLAUDE.md loads into every session regardless of what the developer is doing that day, which makes it right for facts that always apply: build commands, architecture, naming conventions. A skill loads only when a task matches its description, which makes it right for a procedure you need sometimes: how the team debugs, how the team reviews. If your CLAUDE.md has a long section describing how to write tests or structure a review, that section wants to become a skill instead.