# 03 — The thesis: skills are software packages

The centre of the June theory, and the site's `/thesis/` page. Four briefs from 4 June 2026 carry it; this document assembles them.

---

## 1. The claim

> ***"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."***

Not a metaphor — a checklist. 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.**"*

Score the estate against its own checklist and the site has its `/shipped/` table:

| 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 — and the `use-sg-playwright` duplicate is the consequence |
| Vulnerability management | ✅ (partially) | ❌ — one threat model, Feb 2026, never repeated |
| Code review | ✅ | ❌ no skill review process |
| CI | ✅ extensive | ❌ no skill is tested |
| Distribution | ✅ PyPI, Docker Hub | ❌ no registry |
| Documentation | ✅ | ✅ — the one stage where skills are arguably *ahead* |

**One green cell.** That table is honest, it is generated from the thesis's own words, and it is the site's roadmap by another name.

---

## 2. Why skills are the *successor* to packages, not a variant

The sharper half of the thesis:

> **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 lifecycle table above cannot simply be closed by pointing pip at a skills folder — versioning intent, reviewing intent, and testing intent are open problems, and the site should say so rather than pretending the tooling gap is the only gap.

It also 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.

---

## 3. The projection paradigm — what a skill should be

From the same day's arch brief:

> *"a skill is a projection of a semantic knowledge graph, where **today's skills are static photographs** of what they should be."*

The decomposition: a skill is *"a graph of graphs of graphs"* of **typed primitives** — *principles, concepts, facts, knowledge, actions* — connected across multiple graph types (*"not only semantic knowledge graphs but control-flow graphs, permission maps, authentication maps, identity graphs"*), with the projection *"created in the context of use (multilingual, cultural, situational)."*

**Every shipped skill in the estate is a static photograph.** The site should say that plainly — the theory criticises the estate's own artefacts, and publishing the criticism is the credible move.

## 4. 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 (`04__`) 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.

**Deconflict:** the fork-and-return economics are `open-source.sgit.ai`'s ground. This site owns the *skills* application; link for the general argument.

---

## 5. What building the thesis would take — the honest sequencing

The site should publish this as a roadmap with the theory, since the theory demands it:

1. **A version per skill.** Cheapest possible start: a `version` field in every SKILL.md frontmatter, following the estate's own repo-root `version` convention.
2. **One canonical copy.** Kill the `use-sg-playwright` duplicate — one repo owns it, the other imports it. This is the pip moment: the first dependency.
3. **A skill test.** Any test. The `skill-creator` tooling this estate uses elsewhere already runs evals; no shipped skill has one.
4. **A registry page** — even a generated catalogue on this site is a registry v0, and `/catalogue/` (`02__`) is exactly that.
5. **Then** the graph projection, which is a research programme rather than a step.

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).