Claude Skills and Git: Version, Review, and Share

Versioning Claude skill files with Git means every change to a skill has a history: who changed it, when and what they wrote in the commit message. That history is useful when a skill starts producing different results — you can see what changed and when, rather than comparing files from memory.

A Git repository also gives you a review step before changes go live. Tools like fenbs record why the team approved a change, which is the part Git does not capture: the commit shows what changed; fenbs shows the reasoning behind the decision.

Why version skill files

A skill file that has been working well for weeks can stop producing good results after a small edit. Without version control, rolling back to the previous version requires remembering what it said. With Git, you run git diff to see the change and git revert to undo it.

Version control is also how you share skills across a team without emailing files or pasting into a chat. Each person pulls the latest version from the shared repository and installs it. Everyone runs the same skill from the same source. For where skill files live locally, see claude skills files. For finding skills to version, see claude skills marketplace. A skill that lives only on one person's machine stops being useful the moment that person is unavailable.

Setting up a skills repository

1. Create a new Git repository for team skills. You can use an existing project repository with a .claude/skills/ folder, or a standalone skills repository if you share skills across multiple projects.
2. Add your current skill files to the repository. Commit them with a message that describes what each skill does, not just "add skill files".
3. Add a short README that lists the skills, what each one does and the argument format it expects. This becomes the team's reference when choosing which skill to use.
4. Set up a branch or pull request workflow. Require at least one review before a skill change merges to the main branch.
5. After merging, team members pull the update and restart their Claude environment to load the new skill version.

Reviewing a skill change before it goes live

A skill change is a change to an instruction set that may affect every task the skill is used on. Review it the way you would review a change to a shared coding style guide: check whether the change is an improvement, whether it could break existing uses and whether the commit message explains why the change was made. When in doubt, ask the author to run the eval cases before merging.

• Read the diff carefully. A small wording change can produce a significantly different result.
• Check the "not for" section. If the change removes a constraint, verify that the constraint was not protecting against a real failure mode.
• Ask the author to run the eval cases for this skill. A change that passes the eval is much safer than one that has not been tested.
• Approve or request changes in the pull request. Write the reason in the review comment.

What Git captures and what it does not

Git captures what changed and when. It does not capture why the team decided the change was an improvement, what alternative was considered or what would cause them to revert it. A good commit message helps, but it is rarely detailed enough for a future reviewer who was not in the original conversation.

The decision record belongs somewhere more structured than a commit message. That might be a pull request description, a linked decision in your project tool or a record in fenbs that the team reads when they need to understand the reasoning behind the current version.

Keeping personal skills in sync across machines

If you work on more than one computer, your personal skills folder on each machine can drift out of sync. One machine may have a newer version of a skill while the other still has the original. A small Git repository for your personal skills folder solves this: commit on one machine, pull on the other and both run the same version.

Keep personal and team skills in separate repositories. Personal skills are preferences you maintain yourself; team skills are shared agreements that require a review before they change. Mixing them in one repository ties your personal updates to a review process they do not need. A clean separation also makes it obvious which skills need communication to the team before they change.

How to do this with fenbs

1. Create a free account and add a project for the skills repository.
2. For each skill in the repository, add the current version text to Skills and prompts in fenbs. Include a note pointing to the repository path.
3. When a pull request is merged, record the change as a Decision in fenbs: what changed, the reason and who approved it.
4. Connect your AI app over MCP from Integrations. It reads the current approved skill content and the decisions behind each version, so it understands not just the current instructions but the constraints that produced them.