How to write prompts that actually ship features

The five-part structure behind every prompt in our library — and the acceptance criteria that stop an agent improvising.

Most failed AI builds are not model failures. They are briefing failures: a request with no scope, no constraints and no definition of done. This is the structure we use for every prompt in the library.

1. Context before instruction

Name the product, the audience and the single action the user should take. Two sentences is enough, and it removes an entire category of generic output.

2. Scope, stated as a boundary

Say what to build and, just as importantly, what not to touch. 'Do not add routes I did not ask for' saves more time than any clever phrasing.

3. Structure as an ordered list

Number the sections or steps. Ordered lists survive long conversations far better than paragraphs, and they give you something to point at when the result drifts.

4. Rules that encode your taste

Design constraints, data rules, security rules. This is where your standards live: 'semantic tokens only', 'row-level security on every table', 'no mock data in the final build'.

5. Acceptance criteria

Finish with the checks you will actually run: works at 360px, keyboard reachable, typecheck passes, empty states exist. An agent that has been given a definition of done will usually meet it.

The review loop

Ask for one flow, review it, then ask for the next. Long unattended runs feel efficient and are the most reliable way to produce something you have to throw away.