Three-Part Prompt
Goal, constraints, acceptance criteria. Miss one and it drifts.
Goal, constraints, acceptance criteria. Write all three and your rework drops noticeably.
What you'll run into:
- It runs, but it's not the direction you wanted
- It quietly adds a pile of features you never asked for
- When the result arrives, you can't tell whether to say "done" or "change it"
What each part says
| Part | How to write it | Common mistake |
|---|---|---|
| Goal | What state the user can reach, and why | Writing it as a technical task: "add a useEffect" |
| Constraints | Stack, existing components, must-follow conventions, and what's explicitly out of scope | Only listing what to do, never what not to do |
| Acceptance criteria | A checklist you can tick item by item, ideally with edge cases | Writing something unverifiable like "make it better" |
Writing the goal as a technical task is the most common failure. Say "add a useEffect" and you've given up the chance for it to propose something better; say "automatically load recent records when the page opens" and it may hand you a more fitting approach. The structure principle in the official prompt engineering guide is the same: state the outcome you want clearly instead of prescribing the implementation path. prompt-guide
The three parts are progressive: the goal says what you want, the constraints say what you must not touch, the acceptance criteria say how you'll know it's done. Writing the goal you think about the user; writing constraints, about the project; writing acceptance, about testing. Miss any of these perspectives and the output drifts that way.
Whether criteria are good has a simple test: hand them to someone else and ask whether, from that line alone, they can tell if it's done. If yes, it qualifies; if no, it's still too vague. And write only observable outcomes — don't prescribe the implementation.
How to write acceptance criteria
This part is the most valuable and the easiest to skip — skip it and you can only say "done" by feel. It does two things: gives the AI a self-check list, and gives you a basis for acceptance.
- Write it as sentences you can check item by item. "After clicking submit, the button becomes disabled" is verifiable; "smooth experience" is not.
- Include edge cases. Zero records, extra-long content, network failure. Write these three and the four states get covered automatically.
- State what doesn't count as done. Reverse criteria like "the console must have no errors" and "no unused dependencies added" are very useful.
- Have it self-check and report when done. Item by item, stating which passed and which deviated. The cost is tiny and it can save a round trip.
For example, "show an empty state with a guiding button when there's no data" — the implementer builds the empty state and the button, and you check exactly that row; both sides are talking about the same thing. With "smooth experience," both sides interpret it differently and acceptance turns into an argument.
A template you can edit directly
Replace every bracketed slot with your actual content; don't paste the template verbatim.
PROMPT · three-part
## Goal
[What state the user can reach]. The problem this step solves is
[the specific blocker].
## Constraints
- Tech: [framework, language, existing libraries]
- Reuse: prefer existing components and design tokens under
src/components/ui; don't create lookalike components, don't
hardcode colors and spacing
- Conventions: [the rules this project must follow]
- Explicitly out of scope: [list them, including the obvious ones]
## Acceptance criteria
- [ ] [a behavior you can judge item by item]
- [ ] Shows an empty state with a guiding button when there's no data
- [ ] Shows the reason and a retry button when a request fails
- [ ] Extra-long content never breaks the layout
- [ ] No console errors, no unused dependencies added
First describe your implementation plan; write code only after I
confirm. When done, self-check against the acceptance criteria
item by item and report the results.
This template works best alongside the project's constraints file: the general rules live in the file, and here you only write what's specific to this round (see Spec, Prompt, Constraints: Who Does What). For larger tasks, add Spec Before Code before the goal to lock down the whole scope, then use this three-part structure to implement one piece of it. And if the AI's report can't say which acceptance criteria it met, the third part was too vague — fix the criteria, don't haggle over code.