The right skills, composed for each surface.
A pile of skills is cheap to add and expensive to carry. Spindle composes source skills into tight, surface-specific blends — resolved for the repo, rendered for the harness and model, and materialized exactly where the agent runtime loads them.
Agent "skills" — the reusable instruction files a coding agent loads to do a job well — multiply fast. Left unmanaged, every repository inherits the same growing pile: skills it will never use, skills that quietly contradict each other, and a context budget spent on instructions instead of work. Spindle treats a surface's skill set as something you compose and verify, not something you accumulate.
The everyday workflow is one command. spindle bind looks at a
repo, figures out what kind of surface it is, resolves the exact subset of
skills it should receive, checks that subset for coherence, renders each skill
for the target harness and model, and writes the result into the harness's
native skills directory. The agent simply finds the right skills already there.
Two minutes in
# install the toolchain and a reference distribution of skills
$ uv sync --extra dev
$ spindle dist install examples/spindle-sample/distributions/spindle-sample
$ spindle dist activate spindle-sample
# see what you've got
$ spindle doctrine show
$ spindle skill list
# compose + render + materialize the right blend for a repo
$ spindle bind /path/to/repo --harness claude
resolved 4 skills · lint ok · rendered (identity) · linked → .claude/skills/That last command is the whole idea in miniature: classify the repo, select the channels it subscribes to, resolve them into one blend, render through the harness/model profiles, lint for coherence, and materialize the selected skills where the runtime can load them — failing closed if the blend isn't coherent.
The shape of the idea
Why it exists →
The case against the skill pile: context budget, silent conflicts, one-size-fits-all phrasing, and eroded guardrails. Why the extra step pays for itself.
How it works →
The data model — package, distribution, channel, surface, profile,
blend, doctrine — and the six-stage bind pipeline that turns
sources into materialized skills.
Does it actually help? →
Binding proves a skill is available, not that it's better. Spindle runs paired, held-out behavioral evaluations and gates promotion on the result.
Use it →
Install a distribution, bind a repo, and build your own packages, distributions, and channels. Plug in your own task, gate, and scout sinks.
What it is, precisely
Spindle is a small, dependency-light Python toolchain for a specific loop:
install skill packages, group them into distributions, resolve the
right subset for a repo or agent surface, render that subset for a harness/model
profile, and materialize the result where the agent runtime loads it.
Packages and distributions are ordinary pip-installable projects that declare
themselves with [tool.spindle.package] and
[tool.spindle.distribution] metadata, so the whole ecosystem grows
through packaging you already understand.
The public base ships a minimal reference distribution under
examples/spindle-sample. Everything private — an organization's
own packages, project registries, task sinks, marketplace providers — lives in
separate adapter packages that depend on Spindle, never inside its core.
Rendering proves a skill is present. Only a held-out evaluation proves it helped.The distinction Spindle is built around.