Recipe, skill, prompt, or MCP?
All four move 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 | Recipe | |
|---|---|---|---|---|
| What it is | An instruction you paste | A capability installed into your agent | A running service your agent calls | 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 | 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 | Yes — that is the whole point |
| Carries your scars | No | Sometimes, implicitly | No | Yes — symptom → root cause → fix |
| Versioned & sealed | No | Depends | Depends | Yes — version + content hash |
| Improves over time | No | By editing in place | By redeploying | By report-backs → next version |
| Needs an account / server / runtime | No | No | Yes | 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.
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.
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.
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.