v0.5.0 · transferable build recipes for AI agents · open source

Code moves by copying. Capability moves by teaching.

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.

$curl -fsSL sporo.dev/install.sh | sh
one static binary · macOS / linux / windows · zero accounts, servers or runtimes · latest release
01 — INSTALL
One command, one binary.

Nothing else lands on the machine.

02 — INIT
sporo init in your repo.

The authoring surface installs itself — skill, seeds, guardrails.

03 — DONE
Your agent does the rest.

It harvests, drafts, lints, seals, exports. You review one file.

11 gated sections per recipe 16 CLI verbs 6 platforms, checksummed 0 accounts, servers or runtimes
01what is a recipe

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.

a skill
runs where
inside the harness that defines it
assumes
your tools, your paths, your conventions
transfers
by copying the package
on failure
breaks silently when the harness drifts
a recipe
runs where
anywhere an agent can read and act
assumes
nothing — it probes and maps
transfers
by being rebuilt, once, from scratch
on failure
loud by design — every step carries its own acceptance
02the genre

Eleven sections. Every one gated, none of them 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 →

01The problem — acceptance at the top, in the reader's terms
02Why the obvious approach fails — the dead end, named
03The principles — the payload; portable claims
04The ground it needs — preconditions, each as a ladder
05The contracts — shapes shown, each with its binding
06The build sequence — a Done-when per step
07The seams — what stays configurable, and why
08The scars — symptom → root cause → fix, earned
09Verification — gates ship with the capability
10The trade-offs — including when not to build it
11For the human — the one section written for you
from a real recipe — the scars section

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.
03how it works

Author once. Rebuild anywhere. Improve on every return.

The author side

  1. sporo harvest — mine the repo's own record; scars come from history, not memory
  2. sporo new — a coached draft, scar candidates pre-seeded
  3. sporo lint — the genre gate: shape, scars, neutrality
  4. sporo seal — version + content hash; sealed text never silently mutates
  5. sporo 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.
author→ export→ rebuilt on a foreign stack→ report back→ new scar → new version↺
04for teams

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 ✓
05 · why prose, not packages

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.

06when not to use it

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.

07get sporo

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 enforces
Updating later: sporo 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.