Skills are software packages
The centre of the June theory, from four briefs written on 4 June 2026. Not a metaphor — a checklist, applied to the estate’s own eight skills.
“Skills are code and need to be version-controlled, and need to be treated like software. Skills are a software package, that is the best analogy. Skills are not just a bit of code; skills are like a dependency, and need to be managed just like a dependency. The same way we have npm and pip for managing dependencies, we need a way to manage skills like that.”
The same brief enumerates what the analogy demands: “vulnerabilities management, documentation, integration, wrappers, code reviews, deployment, CI pipelines, distribution reviews — every analogy we have with code, we need with skills.”
The scorecard
Score the estate against its own checklist and this is what comes back. One green cell.
| Lifecycle stage | For code | For skills |
|---|---|---|
| Version control | everywhere | skills live in git, but with no versions of their own |
| Dependency management | pip / npm | none — the use-sg-playwright duplicate is the consequence |
| Vulnerability management | partially | one threat model, Feb 2026, never repeated |
| Code review | standard | no skill review process |
| CI | extensive | no skill is tested |
| Distribution | PyPI, Docker Hub | no registry |
| Documentation | standard | the one stage where skills are arguably ahead |
Every row is stated in the brief itself; nothing here is computed from a live scan of the repositories. The catalogue shows the same gap field by field: 0 of 8 skills declare a version, 0 of 8 declare permissions.
Why skills are the successor to packages, not a variant
Skills describe intent, in English, not just capability.
A code package exports functions; a skill exports a way of doing something, including the judgement calls. That is why the scorecard above cannot simply be closed by pointing pip at a skills folder — versioning intent, reviewing intent, and testing intent are open problems (see Q1 and Q2), and this site says so rather than pretending the tooling gap is the only gap.
It connects to coding.sgit.ai’s /for-agents/ argument from the other side: that site shows code written so a model can read it; this thesis says the next package format is the readable intent.
The forking ecosystem
“Forking a skill is good; sync back via pull-request-equivalents; edge customisation stays compatible with the top.”
This is the mechanism that makes the customisation cascade safe: a corporate skill forks into team versions, and the fork relationship — not discipline — is what keeps them reconcilable. The corpus calls the return path “the open-source tax”: take a customised fork, contribute the generalisable part back. The fork-and-return economics belong to open-source.sgit.ai; this site owns the skills application of it.
The honest sequencing
What building the thesis would take, cheapest step first:
- A version per skill. One
versionfield in every SKILL.md frontmatter, following the estate’s own repo-root version convention. - One canonical copy. Kill the
use-sg-playwrightduplicate — one repo owns it, the other imports it. The pip moment: the first real dependency. - A skill test. Any test. The skill-creator tooling this estate uses elsewhere already runs evals; no shipped skill has one.
- A registry page. Even a generated catalogue on this site is a registry v0.
- Then the graph projection, which is a research programme rather than a step. Read on →