Source-Code Registry Pattern
A source-code registry distributes usable building blocks as inspectable source plus metadata, so agents and humans can install, edit, audit, and compose them inside their own repo.
Core idea
The old package model hides implementation behind an import. The source-code registry model installs the implementation into your project. That makes the artifact editable by humans, diffable in git, and legible to agents.
The pattern appears across UI and agent infrastructure:
| Registry | Unit installed | Why it matters |
|---|---|---|
| shadcn/ui registries | component source | Teams own the component code and can adapt it. Source: shadcn registry docs, https://ui.shadcn.com/docs/registry, 2026-06-19 |
| Skills.sh - Agent Skills Registry | SKILL.md procedures |
Agents install operational behavior as readable markdown. |
| MCP Registry | MCP server metadata and install info | Agents/clients discover tool providers programmatically. |
| Agent Machines loadouts | skills, MCPs, service routes, runtimes | A worker boots with a governed capability bundle. |
| Sigil UI | token/component system | Agents edit the design source, not screenshots. |
Why agents like this pattern
Agents work better when the thing they use is:
- local in the repo,
- text-readable,
- typed or schema-described,
- versioned,
- small enough to inspect,
- constrained by tests/doctors,
- linked to examples,
- easy to uninstall or replace.
That is exactly the shape of source-code registries. They give agents a capability plus the context to modify it safely.
Registry vs package
| Package registry | Source-code registry |
|---|---|
| Import a black-box dependency | Copy source into the repo |
| Upgrade by changing version | Upgrade by applying/reviewing code changes |
| Strong encapsulation | Strong inspectability |
| Better for stable libraries | Better for UI, skills, prompts, templates, and agent procedures |
| Vulnerability scanning is dependency-centric | Review is diff-centric |
Neither replaces the other. Use packages for stable infrastructure. Use source registries for artifacts that need local ownership, taste, customization, or agent editing.
Security and governance
Source install does not remove supply-chain risk. It changes where review happens. A registry item should carry:
- provenance,
- version,
- maintainer,
- file manifest and write targets,
- required env/auth,
- install command,
- verification command,
- permission tier,
- rollback/uninstall notes.
This is the bridge to Agent Capability Registry: discovery is not approval, and installability is not trust.
Kevin rule
For any registry Kevin depends on, create or update:
- a tool/concept page for capability facts,
- a skill if there is a repeatable procedure,
- resolver/capability routing if it changes what agents should use first,
- doctor or test coverage if the installed artifact becomes part of a product surface.
Concept Position
| Field | Value |
|---|---|
| Concept family | Agent harness and runtime primitives |
| Concept owned | A source-code registry distributes usable building blocks as inspectable source plus metadata, so agents and humans can install, edit, audi... |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: A source-code registry distributes usable building blocks as inspectable source plus metadata, so agents and humans can install, edit, audi... Source: User request, 2026-07-01
- 2026-06-19 | Created to connect shadcn registries, skills.sh, MCP Registry, Agent Machines loadouts, and Sigil into one distribution pattern. Source: whole-wiki concept review, 2026-06-19