Portable
The packet is just files. It can live in a repo, be reviewed in a pull request, copied into another project, or loaded by tooling.
Buildprint packet format
A runnable handoff for agent work.
A Buildprint gives a coding agent the context it usually has to infer: what to build, what to preserve, which files to read, which phases to run, and what proof is required before success.
product-buildprint/ phase-driven
product-buildprint/
├── BUILDPRINT.md
├── 00-questions.md
├── 01-project-setup.md
├── 02-ui-identity.md
├── blueprint.yaml
├── 03-phases/
│ ├── phase-index.yaml
│ ├── phase-flow.md
│ └── 01-...md
├── README.md
└── HANDOVER.md What it is
Not a prompt. Not a framework. A handoff format.
Agent-readable
The start file, contracts, and checks tell an agent where to begin, what to preserve, and how success will be verified.
Proof-aware
Claims stay tied to evidence: fixture tests, real-app patches, receipts, QA reports, or explicit limits when proof is not available yet.
Two packet shapes
Use a Product packet for a whole system, or a Capability packet for one bounded integration.
Product Buildprint
Starts from a product goal, setup file, UI identity, machine-readable blueprint, and ordered phase flow. Use it when the agent is building a complete system or major product surface.
Capability Buildprint
Starts from host assessment, compatibility rules, capability contract, apply plan, verification plan, and implementation phases. Use it when the agent is adding one reusable power to an existing app.
Proof rule
Both shapes must name the checks that prove success and the limits that remain unproven. A Buildprint is not complete just because the agent says it is.
Trust levels
Proof can grow without pretending everything is finished.
Draft
Packet shape exists. Claims are still mostly author intent.
Fixture
Behavior is exercised in a small controlled project or test harness.
Real-app fixture
The Buildprint is applied against a pinned real application with public patch or receipt.
Live integration
The result is verified inside a running production-like integration path.
Use it
Give agents a packet they can run, inspect, and improve.
Start with the closest Buildprint, then adapt the contracts, phases, and proof checks to the host repo before implementation begins.