How it works
Blueprints
Blueprints provide ready-made chain documents for common capabilities such as authentication, persistence and REST services. Your agent composes them at define time and builds against their acceptance criteria.
A blueprint is a pre-built implementation pattern packaged as chain documents: requirements, stories with their acceptance criteria, architecture components and decision records, plus the reference assets the pattern needs, such as design tokens, an OpenAPI skeleton or a CI workflow example. Your agent composes one onto the project at define time:
I want to start with a shape off the shelf. What's there, and which fits what I'm building?rcf define blueprint list
rcf define blueprint add @stock/<slug>The agent proposes a shape off the packaged shelf (plus any library your project has registered) and adds the slug you pick. Behind the scenes: add composes the chosen blueprint onto the chain under its own namespace; the packaged shelf itself is documented on the stock-blueprints reference page (there is no CLI verb today that pretty-prints the shelf by category), and `rcf define blueprint list` prints the blueprints already applied to this project.
The contributions are copied into the chain under the blueprint's own namespace, spa-REQ-001 rather than REQ-001, so they can never collide with the documents you and your agent author. From that point on they are ordinary chain documents: coverage counts them, and the verifier holds the built work to their checks. Delivery is still driven from build items you author against those checks, not from the blueprint's contributions in the abstract.
Why compose instead of invent
Three reasons, in the order they matter.
Proven patterns over blank-page invention. When you ask for "an app with sign-in", your agent can invent an auth model from scratch, and every invention is a fresh set of decisions nobody reviewed. A blueprint is the reviewed version: the requirements, the checks and the recorded decisions for that capability, worked through once and reused. Your agent still does the building; it stops doing the inventing.
Consistency across builds. Two projects composed from the same blueprint share requirement structure, decision records and check vocabulary. When you run several small products, or hand one over, that sameness is worth a lot: anyone who has read one chain can read the next.
The gates already know the pattern. Because a blueprint arrives as acceptance criteria rather than as advice, the whole referee applies to it unchanged. A blueprint's checks are counted by coverage, enforced at the build cycle's review and finalise gates, and probed by the independent verifier, exactly like checks you wrote yourself. The pattern does not sit alongside the method; it is inside it.
Composition, and what happens on conflict
Blueprints are designed to stack. A working set for a small product might compose a SPA front end, a REST surface, auth and persistence onto one chain, and the namespacing keeps every contribution attributable to its source.
Two blueprints can genuinely disagree, each shipping a project-wide decision record on the same topic (two different auth models, say). Your agent detects the collision and refuses to add the second, printing both sides so you can see what would have overwritten what. From there you have four choices: adopt the incoming decision, keep the existing one, supersede both with a project-level decision of your own, or pin the conflict to an existing project ADR. The choice is always yours, and nothing resolves silently. Whichever route you pick, the outcome that lands on the chain is a real decision record, so a later blueprint bump can be checked back against it rather than replayed in the dark.
Removal is guarded the same way. A blueprint cannot be dropped while any document you authored still references its contributions; your agent tells you which ones stand in the way, so removal is a conversation about what you are giving up, not a surprise.
Companion suggestions
A service blueprint can name the infrastructural roles it wants alongside it: authentication naming a persistence layer, an app naming a delivery target. When you add the service, your agent walks the recommended roles and prints one line per role in a "Suggested companions" block, ordered from what your project already has, through your prior pins, to the packaged shelf.
Adopting a companion is your call, not the tool's. Once you pick one, your agent records the pin so future adds resolve the same way without you having to say it again.
Discovering what is on the shelf
Use the stock blueprints reference to browse the packaged shelf by category and see what each blueprint gives you: the reference page is the authoritative shelf listing. rcf define blueprint list is a project verb: it lists what has already been applied to your project, printing category, slug, version, appliedAt and contribution count per applied blueprint, and prints an empty list on a project with no applied blueprints. There is no CLI verb today that pretty-prints the packaged shelf itself grouped by category.
What ships today, and what is in build
The compose mechanism ships in rcf-lite today: add, list, remove, supersede, diff and companions are all live verbs, and the built-in help prints the surface for you. The stock library is an active build. Thirty-six blueprints exist today across twelve categories (application, security, email, persistence, object-storage, messaging, jobs, platform, edge, delivery, observability, deploy); they are listed, with what each gives you and how to apply it, on the stock blueprints reference.
A blueprint can ship a Playwright probe pack that a browser-verify run reads and folds into the report the finalise gate reads. The shelf also carries node-only probes that drive real engines locally (Postgres, MinIO, wrangler dev and friends); probes that would need a real vendor account record skipped with a stable reason so the aggregate verdict counts honestly. As with everything on this site, the status page is the honest map of built versus building.