Code moves by copying. Capability moves by teaching.
Transferable build recipes for AI agents.
sporo turns a build you already did into a recipe — one self-contained file any AI agent can rebuild from, on its own stack, in a repository that has never seen yours. Your scars included, so nobody pays for them twice.
sporo initGive any agent this line. It reads the sealed sporo seed — a human-auditable install recipe, not a script — then works through it in your repo, detecting first and proving each step.
Read https://sporo.dev/seeds/sporo.md and follow it to set up sporo in this repoOr read it first: the seed as Markdown ↗ — every step is there to review before an agent runs it.
$curl -fsSL sporo.dev/install.sh | shPackage anything. Rebuild it anywhere.
A single prompt, a module, a whole project, an entire microservice — sporo distils it into one portable recipe. Not the code: the principles, contracts and scars that make it work. On the far side an agent germinates it back into the real thing — on a different stack, in a repo that has never seen yours.
Not a prompt. Not a template. Not a packaged skill.
A recipe is transferable, verifiable build intent. The name comes from spore — the minimal portable unit that grows the organism in a foreign environment. A recipe carries that minimum — principles, contracts, scars — and leaves behind everything that only makes sense in your repo. Read a real one → · browse the corpus →
A summary, then eleven gated sections. None decorative.
A recipe isn't free-form prose — it's a fixed shape a linter enforces: neutrality (roles, never your paths or product names), a Done when: on every build step, and scars that carry symptom, root cause and fix. The full genre →
The day that was 25.3 hours long
Symptom: the effort total exceeded the length of the day it reported.
Root cause: summing parallel agent sessions measures machine busy-time, not elapsed time — two different questions, silently added.
Fix: report both, name the method next to each number, never add them.
A clean-room rebuild cannot produce this section. That's why it's the most valuable one.Author once. Rebuild anywhere. Improve on every return.
The author side
sporo harvest— mine the repo's own record; scars come from history, not memorysporo new— a coached draft, scar candidates pre-seededsporo lint— the genre gate: shape, scars, neutralitysporo seal— version + content hash; sealed text never silently mutatessporo export— one self-contained file. Hand over this, never the source
The reader side
- Probe, don't assume — every precondition checked against the real repository
- Map roles — the facts file, the collector: the reader decides where each lives here
- Agree the outcome — which outputs, in what form, confirmed with a human first
- Never substitute silently — degrade honestly, label it in the output
The loop
- Report-backs are new scars
- New scars raise the version
- Today's recipe has already absorbed a failure you'd hit next month
- The moat isn't the file format. It's this loop.
One schema. Ten stacks. Zero drift.
The team case: everyone rebuilds a reporting system on their own stack, but one shared consumer parses every feed. In a recipe that shape is marked Binding: exact — and exact is enforced, not promised:
- The seal refuses a change to an exact shape under anything less than a major version — a break never ships wearing a compatible number
- Fixtures travel with the shape — a valid instance, and the mutations a consumer must reject; the linter runs them
- Every adopter checks their own output in CI, against the handed-over file alone — no checkout of your repo, no account, no server
$ sporo conform handoff.md my-feed.json
# the renamed field a consumer would miss:
✗ contract #1 $.counted: missing — the consumer
parses this field and will starve without it
✗ contract #1 $.tallied: not in the contract
$ sporo conform handoff.md fixed-feed.json
sporo conform: contract #1 ✓Readable before it runs. Self-checking after. It makes the result check itself.
A skill package is opaque until it runs: you trust it or you audit its code. A recipe is prose — a human reads it and decides whether to let an agent act, before a single line executes. Every step carries its acceptance, verification gates ship with the capability, exact-bound schemas are checked mechanically.
Recipes are not the right tool everywhere.
- ✕Same stack, same harness, same company — hand over the code, or package a skill. A recipe re-derives what you could have copied.
- ✕Determinism matters more than adaptability — zero re-derivation cost beats a document an agent has to interpret.
- ✕The capability is one library call — the recipe is the install command.
- ✕Nothing went wrong building it — a build with no scars didn't need a recipe.
Recipes earn their cost where the destination is genuinely heterogeneous: a different stack, a different agent, a different company — and code that literally cannot be handed over. That's the wedge: private teams transferring capabilities across a boundary code can't cross.
One binary. No runtime. No dependencies.
$ curl -fsSL sporo.dev/install.sh | sh
$ sporo init # install the authoring surface into a repo
$ sporo genre # read the rules the gate enforcessporo upgrade (the binary), then sporo update in each repo (its skills). The binary hints — one quiet line, at most once a day — when a newer release exists.macOS (Apple Silicon & Intel), Linux, Windows — amd64 and arm64, checksums published with every release. Apache-2.0, source on GitHub.
go install sporo.dev/sporo/cmd/sporo@latest works too; a brew tap follows.
Don't take our word for it — verify the binary.
Every release is signed with cosign — keyless, so there's no signing key you have to trust — and carries a SLSA build-provenance attestation binding the binary to this repository's release workflow, plus a full SBOM. Confirm what you downloaded is really ours, offline, in two commands:
# build provenance — who built it, and from which commit
$ gh attestation verify \
sporo_…_linux_amd64.tar.gz \
-R ydnikolaev/sporo
✓ built by ydnikolaev/sporo · release.yml# signature — the keyless cosign bundle over checksums
$ cosign verify-blob \
--bundle checksums.txt.sigstore.json \
checksums.txt
Verified OK