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, optionally 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 Optionally load files with AGB Use the helper CLI to create a local .buildprint/ folder with 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.

Comic explaining how Buildprints turn reusable implementation knowledge into agent-ready packets.
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

Skills vs Buildprints

Skills teach an agent how to work. Buildprints tell an agent what to install, change, or build in a target codebase and how to prove it worked.

Skills improve the workerA skill is reusable operating knowledge: debugging Python, designing frontend screens, using Notion, running a taskflow, or reviewing code.
Buildprints package the workA Buildprint is an implementation packet: add Stripe subscriptions, add RBAC, add API keys, build a product, run phases, verify, and write a receipt.
Different proof burdenA skill can describe best practice. A Buildprint must inspect the host app, name blockers, touch concrete files, and tie claims to checks.
Short version: Skills are agent capabilities. Buildprints are app capabilities or product execution packets.

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

AGB is optional, but recommended when you want the packet files downloaded into the workspace before the agent starts. Install the CLI globally for the shortest command:

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.

Or skip the global install and run the same CLI from a clone:

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 Buildprint Creator packet when you want to create a reusable Buildprint for a specific capability.

Capability idea Creator 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
Need the authoring packets? Use Buildprint Creator for reusable capability packets, or Buildprint Mapper for existing projects and whole-product packets.
Open Creator Open Mapper

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