Hubskillz

A Git repo of skills, or Hubskillz

Most teams start with a repo holding the SKILL.md folders and a script that copies them into ~/.claude/skills. Here is what that covers and what it leaves out.

A Git repo versions the text of a skill and costs nothing. It cannot tell you what runs on the machines, it either overwrites or freezes edited copies, and it shuts out colleagues without a terminal. Stay on the repo with three developers on a single project. Move to Hubskillz at the second machine per person, or the first non-technical colleague.

Last updated: August 30, 2026

At a glance

CriterionGit repoHubskillz
HistoryThe Git history of the whole repoA version series per skill, with author and message
ReviewA pull request, as long as the team sticks to itDraft, diff, approval by a maintainer
Installgit pull then a copy script, on every machinehubskillz sync, one command per machine
Machine stateUnknownPer machine and per project: synced, outdated, customized, missing
Locally edited skillOverwritten by the script, or never updatedFlagged as customized and left alone without --force
Without a terminalGit requiredRead, propose and approve in the browser
Skills from skills.shCopied in by hand, then frozenTracked, with the upstream diff and the Snyk and Socket audits
Team scopeSubfolders, by conventionRequired and recommended skills, per team
PriceFreeFree for one person. Team: 9 € per person per month, opening soon

What the repo gets right

A repo gives you most of day one: a single place to read a skill, a full history, and the pull request review the team already practises. Nothing to install, nothing to pay.

While the skills fit in one working repo and everyone spends their day in it, copying by hand stays painless.

What is missing once the team grows

The repo knows what is written. It has no idea what is running. Nobody can answer “who is still on April’s code review skill”, because updating depends on a git pull each person runs when they think of it.

A skill tweaked locally vanishes at the next copy script, or survives forever if the script preserves existing files. Both behaviours produce the same surprise in a meeting.

Skills installed from skills.sh live outside the repo, in ~/.claude/skills. They are neither versioned nor reviewed, and an upstream update lands without anyone reading the diff.

The people who write, design or sell use the same skills as the developers. Asking them to clone a repo is asking them to do without.

When to stay on the repo

One person, or three developers on a single working repo: a .claude/skills folder committed at the root does the job, and Hubskillz would only add a step.

The tipping point is the second machine per person, the first non-technical colleague, or the first skill that comes from outside.

Moving from the repo to Hubskillz

hubskillz push sends an existing skill folder to the directory as a draft. A maintainer reviews it and approves it, and it becomes the reference version.

On each machine, hubskillz status lists the gaps before anything is written, and hubskillz sync --all closes them. The repo can stay the source during the move: both copies coexist, and the command simply reports which ones differ.

Frequently asked questions

Do we have to delete the skills repo?

No. Many teams keep the repo as an archive and let the directory drive the machines. The CLI compares the installed content against every known version, wherever it came from.

What about project-specific skills?

A project keeps its skills in <repo>/.claude/skills. Hubskillz tracks that folder the way it tracks the global root ~/.claude/skills, and reports the state separately for each registered project.

Next steps

Other comparisons