Docs Start here

Documentation

Run, load, and author Buildprints.

Buildprints are reusable implementation packets for coding agents. This guide covers the three jobs: run a maintained packet, load its exact files with AGB, or author a new one.

Open registry Packet format GitHub

Start here

Pick a path. They are ordered from the fastest to the most hands-on.

01 Run a ready Buildprint Pick from the registry, copy the agent prompt, and run it in your project. 02 Load exact files with AGB Create a local .buildprint/ folder with the packet snapshots. 03 Create a Buildprint Use the author packet to generate a reusable capability packet.

Why Buildprints

A coding agent usually has to rediscover the job from a short prompt: what to build, what to preserve, which files matter, and what counts as done. A Buildprint makes that explicit and reusable, so a fresh agent can start without you re-explaining it.

Less rediscoveryScope, read order, and constraints travel with the packet instead of living in your head.
ReviewableIt is just files, so it lives in a repo, ships in a pull request, and diffs like code.
Proof-boundEach packet names the checks that prove success and the limits that remain unproven.
Read the full packet format The Standard page documents both packet shapes, files, and the proof ladder.
Open the Standard

Run a ready Buildprint

This is the fastest path. The registry detail page carries the maintained agent prompt for each packet.

  1. Open the registry.
  2. Choose a packet, for example RBAC Permissions.
  3. Click Copy Agent Prompt on the Buildprint page.
  4. Paste it into your coding agent from inside the target repo.
  5. Review the changed files, verification evidence, and handover.
Registry prompts Each Buildprint detail page has the ready agent prompt and package URLs.
Open registry

Load exact files with AGB

Use AGB when you want the packet files downloaded into the workspace before the agent starts.

npm install -g agent-buildprint
mkdir rbac-build
cd rbac-build
agb start https://agent-buildprint.com/buildprints/rbac-permissions/package.json .

Expected output:

.buildprint/
|-- next-agent.md
|-- source.json
|-- state.json
|-- progress.md
|-- decisions.md
|-- blockers.md
`-- snapshots/
Next step: Tell the coding agent to read .buildprint/next-agent.md. That file points it at the required packet files and read order.

No global install:

git clone https://github.com/DomEscobar/agent-buildprint
node agent-buildprint/bin/agb.js start \
  https://agent-buildprint.com/buildprints/rbac-permissions/package.json .

Create a Buildprint

Do not start with a blank folder. Use the Capability Buildprint Author packet when you want to create a reusable Buildprint for a specific capability.

Capability idea Author packet Generated files Review Publish 
mkdir author-stripe-buildprint
cd author-stripe-buildprint
agb start \
  https://agent-buildprint.com/buildprints/capability-buildprint-author/package.json .

Then give the coding agent a specific target:

Create a Capability Buildprint for Stripe Checkout subscriptions
with webhook-verified entitlement state in compatible Next.js apps.

Expected packet shape:

my-capability-buildprint/
|-- BUILDPRINT.md
|-- README.md
|-- capability.yaml
|-- compatibility.md
|-- apply.md
|-- verify.md
|-- 00-host-assessment.md
|-- 01-integration-plan.md
`-- 02-implementation-phases/
    |-- 01-contract-and-config.md
    |-- 02-core-integration.md
    |-- 03-host-wiring.md
    `-- 05-verification-and-receipt.md
Ready to publish? Submit a finished packet to the registry from the Create page.
Open Create

Packet anatomy

The exact files vary by packet type, but every good packet has a start file, machine-readable route, ordered work, and proof requirements.

BUILDPRINT.mdcanonical start *.yamlmachine route phase filesordered work verify / handoverproof and receipt 
example-buildprint/
|-- BUILDPRINT.md       # canonical start file
|-- README.md           # human overview
|-- blueprint.yaml      # product packet route
|-- capability.yaml     # capability packet route
|-- 00-questions.md     # hard-stop questions
|-- 01-project-setup.md # setup, commands, constraints
|-- 03-phases/
|   |-- phase-index.yaml
|   |-- phase-flow.md
|   |-- 01-contracts.md
|   |-- 02-implementation.md
|   `-- 03-verification.md
`-- HANDOVER.md         # final receipt

Both packet shapes and the proof ladder are documented in full on the packet format page.

Agent-readable packets

A Buildprint is more than a prompt. It makes the work explicit enough that a fresh coding agent can start without rediscovering the job from scratch.

Canonical startBUILDPRINT.md tells the agent what to read first.
Explicit boundariesGoals, non-goals, compatibility, and host assumptions are named.
Ordered phasesThe packet gives implementation order instead of one giant instruction blob.
Proof requirementsThe agent knows which checks must pass before claiming the work is done.
Browsing as an agent? Fetch /llms.txt for machine-readable navigation instead of scraping the UI.

Proof and handover

Done means the agent can show evidence, not just describe the patch.

Expected handover
  • What changed
  • Files touched
  • Commands or tests run
  • Evidence that required checks passed
  • Known gaps or follow-up work

Publish checklist

Before a Buildprint goes into the registry, check it like a packet another agent will run without you in the room.

  • BUILDPRINT.md is the canonical start file.
  • Read order is explicit.
  • Scope and non-goals are clear.
  • Compatibility and host assumptions are stated.
  • Implementation phases are ordered and bounded.
  • Verification has concrete checks.
  • README helps humans but does not override the packet authority.
Submit to the registry When the checklist passes, publish the packet from the Create page.
Open Create