Skill registry

Claude Code agent skills are operating knowledge Orgabot injects into workers. Until now the only way to install them was orgabot-skills/install.sh, a per-machine script that symlinks whatever your working tree happens to contain. That has three problems: every machine drifts, nothing records which version of a skill a mission actually ran with, and a write to a skills repository is a write straight into the instruction stream of every worker that uses the skill.

The skill registry closes all three. A repository becomes a skill source, its content is pinned to a commit an owner approved, and that content is materialized into each worker CLI's skill directory on every machine.

Connect a repository

orgabot skills connect <org> <owner/repo> [--path .claude/skills] [--ref main] [--cadence <ms>]

--path restricts which paths inside the repository count as skill content; leave it off to take the whole repository. A skill is any directory containing a SKILL.md, which is the same rule install.sh has always applied.

Connecting admits nothing. It records the source, resolves the ref once to a concrete commit, reads the content there, and raises an approval:

✓ skill source connected MattSenter/orgabot-skills sksrc_1a2b3c4d5e6f
  resolved main to 9f29d0…
  skills: orgabot-mission, orgabot-register
  nothing has been admitted yet. Skill content is instruction authority injected into workers, so it needs an approval:
  orgabot approve apr_12ab34cd  then  orgabot skills admit sksrc_1a2b3c4d5e6f

Admit the content

The approval carries a digest of exactly this content - every skill, and every file inside it - not just the ref name, and the approval request spells out the content delta so you decide on what will actually enter a worker's context. Approve it, then:

orgabot skills admit <source-id>

Admission re-reads the content at that commit and re-digests it. If the bytes are not the ones the approval named, nothing is admitted and nothing is written. An approval minted for one body of skill content authorizes that body and nothing else, so no other approved record in your queue can stand in for it.

Sync, and what a push does not do

orgabot skills sync                # fetch the pinned commits, refresh provenance, re-materialize
orgabot skills sync --check        # also compare each tracked ref against its pin
orgabot skills sync --due          # run only the sources whose cadence is due

A sync serves the pinned commit and nothing else. There is no auto-tracking of a moving branch: a push to the repository by itself changes nothing inside Orgabot. When --check finds that the tracked branch has moved, it raises a bump proposal - another approval, bound to the digest of the new content, showing exactly which skills were added, changed, or removed. It never re-pins on its own.

If the content at a pinned commit ever stops matching what was admitted (a force-push, say), the sync refuses it, keeps serving the previously approved content, and records the reason. orgabot skills list shows it.

The optional cadence is a command, not a daemon: set it with orgabot skills cadence <source-id> <ms|off> and run orgabot skills sync --due from the cron or launchd job you already use for orgabot duty run-due.

Materialization

Admitted skills are written into Orgabot's own content directory (~/.orgabot/skills/) and linked from each worker CLI location - ~/.claude/skills and ~/.agents/skills, the same two install.sh uses.

orgabot skills materialize   # reconcile the links
orgabot skills verify        # report drift without changing anything

Two things it never does. It never clobbers a real directory or file: a name collision with a skill you wrote yourself is reported and left alone. And it only ever removes links it created - a link pointing anywhere outside the registry's content directory is yours, and stays. Every mission launch runs the read-only verification and tells you if what a worker will see differs from what was admitted.

Multiple machines

Connect the same sources on a second machine and sync. Because the pins and the provenance come from the sources and their approved commits, both machines converge on identical content. (One shared live registry across hosts is a hosted-control-plane feature and is not part of this; deterministic reproduction is.)

What the registry records

orgabot skills show <source-id> prints the whole provenance of a source: repository, path, pinned commit, content digest, who connected it, which approval admitted it and who decided that approval, when it last synced, and every skill it serves with its own digest and file count. Admissions, bumps, denials, revocations and syncs are all written to the organization's audit ledger.

Revoking a source stops it being served immediately and removes its links, but keeps the record - it is the answer to what a mission that already ran got its skill content from.

orgabot skills list
orgabot skills show <source-id>
orgabot skills disconnect <source-id>

Where install.sh fits now

orgabot-skills/install.sh still works and still symlinks the skills in your working tree. That is the local, unversioned, ungoverned copy, which is what you want while you are editing them. The registry is the governed path: pinned, approved, attributable, and identical on every machine.