# PurposePurpose
One H1. The what and why, linking to the README pitch.
requiredAn open, recursive spec format — not a framework
A SEED is a markdown spec for installing your software — its dependencies, the steps to set it up, and read-only checks that prove it worked. Any AI coding agent reads it and installs on the host in front of it, adapting to the environment: apt or brew, the right version pins, the OS’s actual paths. No runtime, no SDK, no lock-in. What the agent shows you is what runs.
The format
A fixed grammar: a # Purpose H1, then four required H2s in order, then Feedback if you want install reports. The format is written in itself — an agent that’s read one SEED has read them all. No parser, no runtime to learn.
# PurposeOne H1. The what and why, linking to the README pitch.
required## DependenciesOther SEEDs and system packages this install needs.
required## ObjectsThe nouns of the system — the things that exist once it’s installed.
required## ActionsThe steps that set it up. The agent runs these, showing each command first.
required## VerificationRead-only checks that prove the install worked.
required## FeedbackOpt-in install reports that flow back to improve the spec.
optionalPurpose and the four required H2s come first, in order. Optional sections follow as Feedback → Open Items → Non-Goals, and a root SEED opens with a ## Normative Language declaration (sub-SEEDs inherit it).
Why publish to the convention
One spec, every host. The agent picks apt or brew, the right pins, the correct paths for the OS it’s on. The format is a convention nobody owns — there’s no vendor between your spec and the machine. Your individual SEED is a repo you own and fork; the format it conforms to is open and ownerless. Two different things — neither one locks you in.
linux ❯ apt-get install ffmpeg ✓ macos ❯ brew install ffmpeg ✓ one spec → apt or brew, whichever the host has
A SEED can depend on other SEEDs. The agent installs leaves-first, so complex deployments are just SEEDs that name other SEEDs — no orchestration layer. Each node is published and verified on its own, and every SEED you ship becomes a dependency someone else can build on.
seed-hostex-history-ingest
└─ seed-hermes-gbrain
└─ seed-hermes
└─ (leaves first)
Security in OpenSeed is review, not a sandbox. The convention requires a conforming agent to:
These are obligations the convention places on the agent, enforced by review — not a promise a runtime can’t be bypassed.
Every SEED ends with ## Verification — read-only checks that confirm the install actually worked, not just that the steps ran. For CI or any non-agent caller, a SEED can ship a ref/verify.sh that runs a few structural checks and returns a plain exit code.
$ bash ref/verify.sh tree conforms ✓ exit 0 installed ≠ works. Verification proves both — and anyone can fork the checks.
Compatible tooling
An OpenSeed is just markdown — anyone can author, host, and install one by hand. Plow gives SEEDs a home: a one-line installer, and a registry to discover and fork SEEDs others have published.
Curl the installer; Plow drops the OpenSeed skills into every agent on your machine.
Browse a registry of published SEEDs — find one, fork it, build on it.
Opt-in, anonymous install reports are coming — they’ll feed real-world install signal back into the spec so authors can tighten it.
Install reporting is opt-in and off unless a SEED declares it. The convention works without Plow; Plow just makes it effortless.
A community convention, shaped in the open. Open to all — propose a change.