Sharing Claude Code skills with a team through the repository
Commit skills to .claude/skills/ and everyone who clones the repo gets them. How to lay that out, review skill changes and stop two skills fighting.
The fastest way to give a whole team the same Claude Code behaviour is to commit it. A skill in .claude/skills/ inside the repo is picked up by everyone who works in that repo, with no install step.
A layout that stays tidy
repo/
.claude/
skills/
house-react/
SKILL.md
references/conventions.md
release-notes/
SKILL.mdTreat a skill change like a config change
A rule in a team skill shapes every file it touches from then on. Review it the way you would review a lint rule: does it say what it means, does it conflict with an existing rule, and did anyone check it still triggers on the requests it should. Keep a short changelog at the bottom of SKILL.md so people know why a rule appeared.
Avoid two skills fighting over one job
If a teammate has a personal skill that does the same thing as the team's, Claude has two candidates for the same request, and which one wins is hard to predict. Decide that the project skill owns team conventions, and keep personal skills for personal habits. When a skill fires where it should not, see a skill that fires too often.
Installing a skill just for yourself instead is covered in how to install a Claude Code skill.
Questions
How do I share a Claude skill with my team?
Put it in .claude/skills/ inside the repository and commit it. Everyone who pulls the repo and uses Claude Code in it gets the skill.
Should skill changes go through code review?
Yes. A skill changes how code gets written for everyone, so a change to its rules deserves the same review as a change to a lint config.
What if someone has a personal skill with the same purpose?
Two skills competing for the same requests make behaviour unpredictable. Agree that the project skill owns that job, and keep personal skills for personal habits.