Recipe, skill, prompt, or MCP?
A prompt, a skill, an MCP server, a fine-tune — each moves capability between agents. Only one is a self-contained artifact that rebuilds it in a repository that has never seen yours. Here is where each one actually fits.
| Prompt | Skill | MCP server | Fine-tune | Recipe | |
|---|---|---|---|---|---|
| What it is | An instruction you paste | A capability installed into your agent | A running service your agent calls | Model weights retrained on your data | A self-contained file that teaches the build |
| Where it runs | Wherever you paste it | The harness it is installed in | Your (or a vendor’s) server | The model you trained and host | Any harness, on the reader’s own stack |
| Crosses to a repo that has never seen yours | No — assumes your context | No — tied to your harness | Only while the server is reachable | No — baked into one model’s weights | Yes — that is the whole point |
| Carries your scars | No | Sometimes, implicitly | No | No — averaged into the weights | Yes — symptom → root cause → fix |
| Versioned & sealed | No | Depends | Depends | By model checkpoint | Yes — id, version + content hash |
| Improves over time | No | By editing in place | By redeploying | By retraining | By report-backs → next version |
| Needs an account / server / runtime | No | No | Yes | Yes — training + a serving runtime | No |
A recipe does not replace a skill — sporo init installs the skill that writes recipes. The two work together: the skill authors in your repo, the recipe travels to the next one.
sporo's two genres answer different questions.
Both are sporo genres — versioned, sealed, and read by an agent in a repository that has never seen yours — but they answer different questions. A recipe teaches how to build a capability from principles: it names roles, never a tool, product, or path, so any agent can rebuild it on its own stack; its discipline is neutrality, which is what lets it transfer. A seed teaches how to bring in one named tool and stand it up — detect whether it is already present, install it from an origin the seed vouches for, prove the install took, put it to use, wire it into the repository's agent harness, and account for every one of those moves; its discipline is accountability for what it runs on the reader's machine. Write a recipe when there is no external tool behind the capability; write a seed when a specific tool, at a specific version, is worth bringing into a repository that lacks it.
What is the difference between a recipe and a skill?
A skill runs inside your harness — it is installed into your agent and acts where it lives. A recipe is a file that rebuilds the capability in a harness that has never seen yours. sporo init installs the sporo-recipe skill, which is the thing that authors recipes.
What is the difference between a recipe and a seed?
Both are sporo genres — versioned and sealed, read by an agent in a repository that has never seen yours. A recipe teaches how to build a capability from principles: it names roles, never a tool or a path, so any agent can rebuild it on its own stack. A seed teaches how to bring in one named tool and stand it up — detect whether it is already there, install it from an origin the seed vouches for, prove the install took, use it, wire it into the harness, and account for every move. A recipe’s discipline is neutrality, so it transfers; a seed’s is accountability for what it runs on your machine. Write a recipe when there is no external tool behind the capability; write a seed when a specific tool is worth bringing in.
Can’t I just share a prompt or a doc?
A prompt assumes your context and drifts the moment it leaves it. A recipe is a machine-gated genre: a neutrality rule (roles, never your paths or product names), a literal acceptance check on every build step, and scars recorded as symptom → root cause → fix — so an agent in another repository can actually act on it.
What is the difference between a recipe and fine-tuning a model?
Fine-tuning bakes behavior into a model’s weights: you assemble a dataset, train, and host the result, and the behavior lives in that one model. A recipe is a plain markdown file any model can read and act on — the build steps and the scars are written down instead of averaged into weights, so nothing is retrained and no model is locked in.
Do I need an account, a server, or a runtime?
No. sporo is one static binary and a recipe is one markdown file. Zero accounts, zero servers, zero runtimes — install with curl -fsSL sporo.dev/install.sh | sh.
What stacks does a recipe work on?
Any. A recipe names roles — “the facts file”, “the collector” — never your files, commands, or product, so the reader’s agent maps those roles onto its own stack and harness.
How does a recipe improve?
Through report-backs. A reader hits a new scar, records it, and it becomes the recipe’s next sealed version. The report-back loop, not the file format, is what compounds.
When should I not use a recipe?
When the capability is trivial, genuinely one-off, or so tied to your private infrastructure that nothing about it transfers. Then a prompt or an in-house skill is enough — recipes earn their gating when the capability is worth rebuilding elsewhere.
Is sporo open source?
Yes, Apache-2.0. One static binary for macOS, Linux and Windows, with checksummed release archives for six platforms.
Ready to try one? Read a real recipe, or install and author your own — curl -fsSL sporo.dev/install.sh | sh.