---
title: "Skills Are a Git-Native Distribution Primitive"
description: "The industry has been converging on repo-as-source-of-truth for agent skills for months. What was missing was a working example of the whole lifecycle, fully built. One tool actually built it."
canonical_url: "https://artificialcuriositylabs.ai/posts/skills-are-git-native-distribution/"
md_url: "https://artificialcuriositylabs.ai/posts/skills-are-git-native-distribution.md"
published_at: "2026-05-16T00:00:00.000Z"
modified_at: "2026-07-06T00:00:00.000Z"
tags:
  - "ai-native"
  - "agents"
  - "skills"
  - "distribution"
  - "patterns"
---

## TL;DR

- Most tools solve discover-and-install for skills but leave drift as the default. The missing operation is contribute-back: a versioned, CI-gated publish that treats a skill update like a software release.
- The industry converged on git-native distribution as the pattern. The gap was a tool that built the complete loop — not just install, but version, review, publish, propagate.
- One registry now exists with that full lifecycle, built by the Snyk founder on a $125M bet that skills need the governance code always needed.
- Publishing is unilateral by default — nobody reviews unless a team wires a CI gate in. The infrastructure exists; enforcing it is still a choice.

---

Institutional knowledge that lives in a wiki page dies when the person who wrote it changes teams. Institutional knowledge that lives in a `SKILL.md` — instructions an agent actually reads before acting — survives, because the artifact that carries the knowledge is the same artifact that does the work. The industry has been quietly building the infrastructure for that, and the complete lifecycle for it now exists.

[Your Agent's Behavior Is Code — Start Versioning It](https://artificialcuriositylabs.ai/posts/agent-behavior-is-code/) made the same claim in April: institutional knowledge locked in people's heads or unread wikis is now versionable, diffable, executable, and should be treated with the same discipline as code. [Skills as Institutional Memory](https://artificialcuriositylabs.ai/posts/skills-as-institutional-memory/) named the specific gap: “Skills don’t yet have a standard for communicating breaking changes to methodology.” That gap is the one [Tessl](https://tessl.io) closed.

## The Convergence Was Already Real

Every signal pointed the same direction, independently, over the past several months:

- **[Anthropic's skills repo](https://github.com/anthropics/skills)** — a public collection of shareable Agent Skills, now past 158,000 GitHub stars. Fork it, adapt it, PR your improvement back.
- **`gh skill install`** ([docs](https://cli.github.com/manual/gh_skill_install)) — GitHub's own CLI installs a skill straight from any repo into your local agent, across [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview), [Goose](https://goose.block.xyz), [Junie](https://www.jetbrains.com/junie/), [OpenCode](https://opencode.ai), [Windsurf](https://devin.ai/desktop), and more.
- **[mdskill.dev](https://mdskill.dev)** — a live, security-audited directory sitting at 10,000+ skills across 270+ repos.

The pattern underneath all three is the same three-operation model:

```
REPO (source of truth)
  └── docs/skills/ or .claude/skills/
        └── SKILL.md + scripts + resources
        ↓ discover / install / adapt
LOCAL HARNESS (runtime)
  └── vendored or symlinked copy
        ↓ contribute back (PR)
REPO (updated with field improvements)
```

Discover, install, contribute back. Every tool above nails the first two operations. Almost none of them close the third.

[Rajiv Pant named the gap precisely](https://rajiv.com/blog/2026/03/23/managing-ai-agent-skills-at-scale-three-repo-architecture/): "Both the installed copy and the source had improved independently over the week." That's drift — the exact failure mode you'd expect once discover-and-install is solved but contribute-back isn't. If you've been managing your own skills for a while, you've probably already built half the fix yourself: a symlink from your agent's skill directory into a personal repo, so there's one copy, not two, and nothing to drift. That solves replication. It does nothing for versioning, review, or distributing an update to a different machine.

## What the Complete Loop Actually Looks Like

I tested one registry — Tessl — directly rather than reading about it. The day-to-day experience is in [Agent Sprawl Is a Skills Problem](https://artificialcuriositylabs.ai/posts/agent-sprawl-is-a-skills-problem/). The mechanism, confirmed hands-on:

A skill lives as a plain `SKILL.md` plus a manifest in an ordinary git repo — nothing proprietary about the storage. [Tessl's own reference tile](https://github.com/tesslio/spec-driven-development-tile) runs a real CI pipeline on every pull request: a check that fails the merge if the manifest's version field wasn't bumped, a structural lint, and an automated quality review — before a publish step ever fires on merge to `main`. That's the contribute-back operation, implemented with the same rigor as a software release, not a manual sync.

Publishing doesn't hand a live git checkout to consumers. It vendors an immutable, versioned snapshot into a local cache, pinned to the exact version published — so editing the source does nothing to anyone's install until you deliberately publish again. I edited a skill, bumped its version, republished, and ran the update command elsewhere: the exact edit landed in the installed copy, and nowhere else, until I asked it to.

`--bump patch|minor|major` on the publish command is semantic versioning applied to a skill's methodology — the mechanism for communicating breaking changes that didn't exist before.

Governance is a five-role ladder — Consumer, Member, Publisher, Manager, Owner — each with a defined permission set, confirmed against Tessl's own documentation. Publisher can create, publish, and unpublish (within a two-day window, an npm-style undo guard, not indefinite retraction). Manager and Owner control who holds that role. None of it requires code execution inside the platform — agents read the resulting files the same way they'd read anything else in a repo.

## The Market Bet Behind This

Tessl's homepage leads with "Skills are the new code. Treat them that way," and three questions aimed at governance risk: would you know if a risky skill ran in your environment, what are duplicate and outdated skills costing your team, are your agents actually using the skills they have. Distribution is the proof point. The claim being sold is bigger — that skills are about to need the same enterprise discipline code has always needed.

The founder is [Guy Podjarny](https://www.linkedin.com/in/guypo), previously of [Snyk](https://snyk.io) — built on the same instinct: take a category everyone was quietly ignoring and make it a governance line item. [The company has raised $125 million](https://www.indexventures.com/perspectives/when-everyone-speaks-software-tessls-vision-for-ai-native-development/) from Index Ventures, Accel, GV, and boldstart. Whether "skills are the new code" lands the way "shift security left" did for Snyk is still an open question.

## What's Still a Choice, Not a Guarantee

The open thread the industry hasn't answered, and Tessl doesn't answer it either: who reviews the skill when the author and the contributor are both agents?

The honest answer: nobody, by default. Publishing is unilateral for anyone with Publisher role. The lint-and-review-as-CI-gate pattern is real and it works — but it exists because one team chose to require it in their pull request checks, not because the registry enforces it as a platform guarantee. Strip that CI config out and a Publisher ships straight to the registry with no review step at all. The infrastructure for rigorous, git-native skill governance now exists end to end. Whether any given team actually wires the review gate in is still a social decision, not a technical one.

Skills distribution stopped being a hypothetical pattern the moment a tool built the complete lifecycle — discover, install, version, review-if-you-choose-to, publish, propagate — on infrastructure that already knows how to ship software. The part that was missing is built. The part that was always going to be a choice still is.