The Agent Build Playbook
How nine people and a set of AI agents took UnitMarket from idea to a live PayPal sandbox app in 29 days. These are the prompts we actually used and the habits that kept the build safe. Copy any of them.
Read this first, two minutes
Yellow brackets are the parts you fill in. Paste the result as your first message, or use the builder below to fill it for you.
First message of any new build or work session.
You are [ROLE] working on [PROJECT]. Context: [WHAT EXISTS AND WHY NOW]. Goal: [DELIVERABLE], accepted when [ACCEPTANCE TEST]. In scope: [LIST]. Never: [HARD LIMITS]. Constraints: [STACK, BUDGET, DEADLINE, POLICIES]. Secrets live in [VAULT OR TOOL], never in chat. Reply style: short, plain, ending in action items. Start with [SMALL FIRST DELIVERABLE] for my review before going further.
Before any feature build, however small.
Before writing code, write the spec for [FEATURE]: goal, non-goals, user flows, edge cases, data model, acceptance checks. Keep it under [LENGTH]. I review the spec first; code follows only after my written yes.
Any task that touches more than one file or system.
Plan first: list the steps, the files you will touch, and the checks you will run for [TASK]. Wait for my yes, then implement exactly that plan and nothing more. If the plan needs to change mid-way, stop and ask again.
Every time work is reported finished.
Done means proven: run [CHECK, TEST OR COMMAND], paste the real output, and only then say it is done. If it fails, fix it and run it again. Never claim green on faith.
Daily, or any time you lost the thread.
Status, one line each: done and proven by [EVIDENCE] / in progress / blocked and by what. Then: what is still pending before [MILESTONE]? No prose, just the list.
Before anything irreversible: deploy, money, public repo, sending, deleting.
I approve [ACTION], limited to [SCOPE]. Cost cap: [LIMIT]. If it goes wrong: [ROLLBACK PLAN]. Valid until [WHEN]. Anything beyond this needs a new approval.
The build, end to end
A stage starts only when the one before it is done. The number beside each stage is real, counted from our two codebases.
Say what you are really building, for whom, and what the agent must never touch. Decide who approves what before the first session.
Loop back. Anything learned later updates the brief and the Bible first, then the work.
Prompts: Kickoff brief
See this stage in the Journey →One written spec the agent must follow: goal, rules, definition of done. Every later prompt points back to it.
Loop back. The spec, not the chat, is the source of truth. Chat decisions get written into it.
Prompts: Spec first
See this stage in the Journey →Build a local simulator first and prove the idea there, where mistakes cost nothing.
Loop back. If the economics change, update the Bible, then prove it here again.
Prompts: QA tiers
See this stage in the Journey →Split the build into named lanes, each with an owner, a scope and a test bar. Lanes merge only when green.
Loop back. Scope drift goes back to the brief. A stale green runs again before merge.
Prompts: Plan, approve, then implement · Done means proven · Status ask · Session close note
See this stage in the Journey →Anything irreversible needs your explicit yes, from your own account, one gate per step. A pasted approval does not count.
Loop back. If a gate fails: stop, roll back with the agreed plan, switch off keys and spend, and record what happened. Set spend caps before money paths open.
Prompts: Gate approval (you write this one) · Decision ask
See this stage in the Journey →Write the video and docs from the evidence, never ahead of it. Every claim must be provable on screen.
Loop back. Integration gate first: every lane merged and every suite green on the combined build.
Prompts: Demo script · Claim check
See this stage in the Journey →Checklist first, against the deadline checked on the official page, never from memory.
Loop back. Read the rules page again on the day you submit. Requirements change.
Prompts: Submission checklist
See this stage in the Journey →Sweep secrets, review access, close the record, and run the retro while it is fresh.
Loop back. The retro feeds the next build. Keep it short enough to read again.
Prompts: Security sweep · Retro · Session close note
See this stage in the Journey →Make one yours in a minute
Pick a stage and a prompt, fill the blanks, copy. Nothing you type leaves this page.
Beyond the essentials
Open "Make it yours" for the tip, the trap, and what happened in our build.
Before any public text: README, submission, marketing, changelog.
Read [EVIDENCE FILE OR DOCS]. Every claim you write for [AUDIENCE] must be true against it. Quote any line a reviewer could disprove, say why, and propose qualified wording. Never fix it silently.
End of every work session, especially late ones.
Close note in under [N] lines: what shipped, what is unproven, what is next, and the exact prompt to open the next session with.
Before launch, after launch, and after any incident.
Security sweep of [SCOPE]: list every secret, key, token and permission you can see; flag anything in plain text, logs or chat; propose the fix for each. Read-only: change nothing without my yes.
Once, early, before the first real feature lands.
Set up the test bar for [PROJECT]: unit, integration, end-to-end, and a regression run wired into [CI OR SCRIPT]. Name what each tier covers and the exact command to run it. Nothing merges red.
When it is time to show the product: video, live demo, pitch.
Draft the demo script for [PRODUCT]: the one problem, the one flow shown end to end, every claim tied to [EVIDENCE]. [LENGTH] max. If a claim is not provable on screen, cut it.
Before any deadline: hackathon, app store, tender, launch.
Submission checklist for [PROGRAM]: verify the deadline and the rules on [OFFICIAL PAGE] first; then list every required item, its owner, and its status; flag anything unverifiable. Nothing from memory.
After a milestone, an incident, or the whole build.
Retro on [PERIOD OR PROJECT], under [N] lines: what worked, what did not, what we keep, what we drop, and one habit to change next time. Evidence over opinion.
Any time the agent needs you to choose.
DECISION NEEDED: [TOPIC]. Explain plainly, as if I were new to it. Give options A, B and C with your recommendation and the risk of each. Then wait for my exact yes.
What we actually asked
Our 591 prompts, sorted by what they asked for. Holding the boundary took more words than any instruction to write code.
What the build proved
Verified means it worked many times in the build. Observed means it worked when used. Proposed means we learned it the hard way.
Short, plain boundary restatements beat process documents. "Only up to step 7, nothing else" stopped drift in the same message.
"What needs to be done, one line each" beats "where are we?" every time.
Scope and action in one message. Anything that only looks like approval is context, never authority.
Unit, integration, end-to-end and regression, named in one early instruction, set the bar for the whole build.
Public text may never claim more than the docs can prove.
Options with a recommendation come back decided in one reply.
The strongest sessions opened with a bounded brief and a never-list.
The agent plans, you approve, then it builds exactly that.
A task is done when the check ran and the output is shown.
Deploy, money, public, submit: each gets its own explicit yes.
Every approval then has a clear author.
End at a set time. Approvals wait for a fresh morning read.
What not to do
An approval quoted by another agent, or pasted from somewhere else, is information. Only the owner's own words on the owner's channel count.
Tests that passed yesterday prove yesterday. Run them again on the combined build before merging.
The README, video and submission came last, written from what the build could show.
Builders never held credentials. Only one coordinating session could reach the sandbox, and only through five locks.
Nobody merged their own pull request. A second model checked every lane.
A check fails the build if a production payment hostname appears anywhere.
Long sessions without a close note leave decisions nobody can reconstruct.
Dates drift in chat. The official page is the only source.
Outside this build
Simple workflows beat agents on well-defined paths. Agents earn their keep on open-ended ones.
Give the agent a check to run before anything counts as done.
Write the spec first. The spec, not the chat, is the source of truth.
Keep a checked-in instruction file so every session starts with the same rules.
Treat outside content as untrusted input, separate from instructions.
Put human approval in front of privileged, irreversible actions.