Skills
Share agent skills across every project of an organization — a git repository, a catalog, and a switch per project.
A skill is a folder with a SKILL.md in it (a name, a description, instructions) and
whatever scripts or references sit next to it. Claude Code keeps each skill's description in
context and loads the rest when the task calls for it.
Skills that belong to one repository live in that repository's .claude/skills/, and reach the
agent with the clone. Skills that belong to you live in your dotfiles. Organization skills
are the ones in between: the same deploy, repos or mattermost skill, wanted in every project
of the team, written once.
An owner or admin adds a skill source in Settings → Skills:
| Field | What it is |
|---|---|
| Repository | picked from your organization's git connections — or a clone URL |
| Path | the folder whose sub-folders are skills, e.g. skills (empty = repository root) |
| Ref | a branch (followed at every task) or a tag (pinned); empty = default branch |
| Mode | On in every project, or Off unless a project turns it on |
Every sub-folder of the path holding a SKILL.md is a skill. Open a source to see them with their
descriptions, as read on the ref — and to make a single skill the exception to the source's mode,
so one repository can hold both the common base and the niche ones.
Why a repository and not an upload: history, review in pull requests, rollback and pinning come for free, and an agent that hits a trap can fix the skill the normal way — clone, edit, open a pull request.
A project gets the organization's default set without configuring anything. In the project's Edit → Skills section, each skill has a switch: turn on an optional one, turn off a default one. The label next to it says who decided — the organization's default, or this project — and a project's own setting can be reset to the default.
This is about relevance, not security: every skill description is paid on every session, and a
picnic skill in the backend repository is noise the agent may act on.
Saved immediately and outside the project's versions: switching a skill neither creates a version nor rebuilds the image.
When a workspace is created, a Skills setup step (after your dotfiles, before your
repositories) clones each source into ~/.spunto/skills/ and links every retained skill into
${CLAUDE_CONFIG_DIR:-~/.claude}/skills/ — one link per skill:
$ ls -la ~/.claude/skills
picnic -> /home/vscode/.spunto/skills/<source>/skills/picnic
spunto -> /home/vscode/.spunto/skills/<source>/skills/spunto- Nothing is overwritten. A skill of the same name from your dotfiles — or anything already there — wins, and the conflict is printed in the setup log.
- The exact commit of each source is printed in the setup log, for audit: a skill's scripts run in the workspace, with its secrets.
CLAUDE_CONFIG_DIRis read inside the workspace, so it can come from one of your secrets.
Before every task, the same step runs again: each source is fast-forwarded and the links are redone from the project's current selection — a skill merged this morning, or switched on a minute ago, reaches the next task, even on a reused workspace. It only removes links it made itself.
The clone is made as the organization (the same credential that clones your projects), so it
works for every member. After that, the repository in ~/.spunto/skills/ is an ordinary checkout:
a git pull or a git push of a fix goes through the workspace's credential helper as you,
like your project's repositories.
Only owners and admins edit the catalog and a project's selection. Every member can read both.
GET/POST /api/orgs/{orgId}/skill-sources, PATCH/DELETE …/{id} | the catalog |
GET …/skill-sources/{id}/skills | the skills a source holds on its ref |
GET /api/orgs/{orgId}/projects/{id}/skills | the catalog as a project sees it, with the reason for each state |
PUT/DELETE …/projects/{id}/skills/{sourceId}/{skill} | turn a skill on/off for a project, or back to the default (* = the whole source) |
Full schemas in the API reference.