Use AI to Turn Requirements Into Acceptance Criteria
Hand AI a vague requirement like "improve onboarding" and it fills the blanks with its own guesses — nobody said what "done" means. Here's how to turn a requirement into observable, testable acceptance criteria you can review before any implementation.
Structure a Requirement Into Acceptance CriteriaWhen "improve the onboarding" turns into work nobody can check
A requirement lands in your lap: "improve the onboarding flow," "make the export easier," "build a better search filter." You paste it into the AI and ask for a plan, or straight for the code. It answers fast and confidently — a redesigned flow, a tidier export, a new filter UI — filling every blank the requirement left with its own guesses. It looks like progress. Then you try to tell whether it is right, and you can't, because nobody ever said what "right" would look like. "Better" was never defined, so the AI defined it for you, quietly, and its definition may not be the one the person who wrote the requirement had in mind.
The missing step is turning the requirement into acceptance criteria first. A requirement says what someone wants; acceptance criteria say how you will know it has been delivered — the specific, observable conditions that separate "done" from "not done." Getting those written before any implementation is what makes the AI's output reviewable instead of just plausible. This guide is how to use AI to turn requirements into acceptance criteria: give it the requirement and the context, ask for the done-conditions rather than the solution, and keep the parts nobody has decided as questions instead of guesses. NewPrompt helps you build that prompt — the Product Requirements Assistant gives it a structure, from problem statement to testable criteria to what is out of scope — and it is honest about the limit: it doesn't validate the requirement, get anyone's approval, or create tasks in your tracker. You run the prompt on your requirement in your own AI tool, and what comes back is a candidate draft you review and confirm, not the definition of done itself.
Why a requirement doesn't tell the AI when it's done
A requirement is a statement of intent, and intent leaves out the one thing implementation needs most: a way to know when it has been met. Hand a model "make the export easier" and watch what the gap costs you:
- It states a wish, not a condition. "Easier" is a direction, not a test — there is no sentence in it you could hold the result up against and mark pass or fail.
- Quality adjectives measure nothing. "Better," "cleaner," "more intuitive" feel like requirements but check nothing; two people reading "intuitive" picture two different screens.
- It invites an early jump to the solution. With no done-condition to aim at, the model does the natural thing and starts building — you get an implementation before you have agreed on what it is supposed to achieve.
- The edge cases are invisible. A requirement rarely says what happens on an empty state, a long input, or a slow network; without them named, they get decided by accident, in code.
- Out-of-scope is unstated. "Improve the filters" doesn't say "don't redesign the cards," so the model is free to expand, and you find out from the diff.
- Review becomes an argument. When "done" was never written down, "is this what we wanted?" has no reference to settle it, and the answer depends on who is asked.
Step 1: Ask for the criteria before the implementation
The move is to insert one step between the requirement and the build: ask the AI to turn the requirement into acceptance criteria first, and tell it not to propose code or tasks yet. That single instruction — "before proposing an implementation, write the conditions that would make this requirement met" — changes what you get back from a guess at the solution to a draft of the target. It also front-loads the disagreements: it is far cheaper to argue about a criterion than about a finished feature built against the wrong one.
The Product Requirements Assistant is a ready structure for this: it reframes a request into a problem statement (the user problem, not the solution), a set of testable acceptance criteria, an explicit out-of-scope list, and the open questions that need a human answer — and it bars implementation details on purpose. If you would rather build the prompt yourself, the System Prompt Generator is where you set that structure and the rules around it. Either way, it produces a prompt you run in your own AI tool; NewPrompt writes the structure, and your own model drafts the criteria, which you then review.
Step 2: Make every criterion observable and testable
A criterion earns its place only if someone can check it. So the test for each one is simple: could a person, or a test, look at the result and say pass or fail without arguing? "The system should be faster" fails that test; "the results list appears within one second of applying a filter" passes it. Push each criterion into an observable shape — often "when [situation], the user can [action], and [visible result]" — so it names the trigger, the behavior, and the evidence. Ban the quality adjectives outright: every "easy," "clean," or "intuitive" is a criterion that hasn't been written yet.
The Add Success Criteria to a Prompt resource is the same discipline in miniature: it turns "make it good" into a definition of done you could evaluate the output against — a criterion is "a sentence you could check the result against," not an adjective. That rule travels to any requirement: if you can't state the condition as something checkable, you haven't defined it yet, you have just named a feeling. The format is secondary — Given / When / Then, a numbered list, a table all work — as long as each line is a check, not a hope.
Step 3: Separate what's decided from what's a guess
The most dangerous acceptance criterion is the one the AI invented to fill a decision nobody actually made. "Improve the filters" doesn't say what happens to a selected filter when the screen rotates — so a model completing the pattern will pick an answer and write it as a criterion, and it will read exactly as authoritative as the ones grounded in the requirement. Stop that by telling it to split its output: what the requirement supports goes in acceptance criteria; what it assumed goes in a labeled assumptions list; what it genuinely can't tell goes in clarifying questions, or a plain "cannot be determined from the requirement." A guess marked as a guess is useful; a guess dressed as a requirement is a trap.
This is also where the requirement's missing product decisions surface while they are still cheap. The clarifying questions are the model handing you the choices only a person can make — which behavior is intended, which case matters, where the line sits — instead of quietly choosing for you. You answer them, or route them to whoever owns that decision, and the answers become real criteria. The point isn't for the AI to resolve the ambiguity; it is for the AI to make the ambiguity visible so a human resolves it.
Step 4: Draw the boundary — out of scope and edge cases
Criteria say what "done" includes; a good draft also says what it doesn't. Ask for an explicit out-of-scope list — the related things this requirement is not asking for ("don't redesign the cards, don't change the search ranking") — because the space you leave unmarked is the space the AI, and later the implementation, will wander into. Add the edge cases the requirement is silent on but the build has to handle: the empty state, the long value, the error, the slow connection. Each one you name is a criterion you get to decide on purpose instead of discovering in production.
Then ask for test ideas alongside the criteria — the concrete checks that would confirm each one. They do double duty: they force the criteria to be specific enough to test (a criterion you can't imagine a test for is still too vague), and they give whoever builds and reviews the feature a head start on proving it is done. The criteria, the out-of-scope list, and the test ideas together are the shape of the agreement — what is in, what is out, and how you will know.
Step 5: Review the criteria, and get them agreed before you build
What comes back is a draft, and the word matters. The AI produced a candidate reading of the requirement, not the requirement's true meaning — it was not in the room when the request was made, and it can't know which of its assumptions the requester would accept. So read the criteria back against the source: does each one actually follow from what was asked, or did a plausible-sounding line slip in that nobody wants? Answer the clarifying questions, cut the invented criteria, and fix the ones that are close but not quite what was meant.
Then get them confirmed before they turn into work. Acceptance criteria are a shared decision, and a decision one person drafted with an AI isn't shared until the requester — the stakeholder, the client, the person who wrote the ticket — has seen it and agreed. Once they are agreed, the criteria earn their keep: they become the target for a coding prompt, the checklist for a review, the basis for the tests. But the AI's draft is where that process starts, not where it ends; the definition of done is a decision your team owns, and on anything carrying real product, legal, or compliance weight, the person who owns that domain signs off on the criteria before anyone builds against them.
Common mistakes
The habits that leave "done" undefined:
- Asking for the build before the criteria. Straight to code or a task list means the AI decides "done" for you — ask for the acceptance criteria first, implementation later.
- Keeping the quality adjectives. "Better," "easier," "intuitive" pass review only until someone checks them; rewrite each as an observable condition someone can mark pass or fail.
- Letting the AI invent the missing decisions. A criterion for a decision nobody made is a guess in disguise — send the unknowns to assumptions and questions, not into the criteria list.
- Skipping the out-of-scope list. Unmarked scope is open scope; name what this requirement is not asking for, or the build will expand into it.
- Treating the draft as the decision. AI-written criteria are a candidate reading, not the definition of done — the requester still has to see and agree to them.
- Never writing the edge cases down. The empty state and the long input get decided somewhere; name them in the criteria so they are decided on purpose.
A worked example: a one-line requirement, made checkable
Watch a one-line requirement that no one can check become a criteria draft you can.
"Improve the filters" gives the AI nothing to check against, so it jumps to a vague solution; asking for criteria first — observable, scoped, with the unknowns kept as questions — turns it into a draft you can review and agree onTHE REQUIREMENT (as it arrives):
"Improve the resource filters on mobile."
WHAT THE AI DOES WITH IT (jumps to a solution):
"Add a better mobile filter UI with improved usability and responsive design."
the problem:
- "better," "improved usability" -- still no measurable done-condition
- never says what's wrong now, or at which screen widths
- no out-of-scope, no test to run -- you can't check it
A CRITERIA-FIRST PROMPT (no code yet):
Turn this requirement into acceptance criteria before proposing any code.
Requirement: Improve the resource filters on mobile.
Context: on small screens the filter chips stack vertically and push the
cards down; the goal is usable filters without making the page longer.
Output:
rewritten requirement | assumptions | clarifying questions |
acceptance criteria | out of scope | test ideas
Rules:
- Do not invent missing product decisions -- ask instead.
- Every criterion must be observable and testable.
A DRAFT YOU CAN CHECK:
Rewritten requirement:
On mobile, filter controls stay easy to reach without adding page height.
Acceptance criteria:
1. At <= 640px, filters show in one horizontal scroll row, not stacked.
2. The filter row does not cover the resource cards.
3. Selecting a filter updates results without changing sort or search.
4. Long labels truncate with an ellipsis on one line -- no wrap or overflow.
5. The desktop filter layout is unchanged.
Out of scope:
- card redesign, filter taxonomy, search ranking.
Clarifying questions:
- Show a scroll affordance? Keep selected filters pinned or scrolling?
Test ideas:
- 390 / 375 / 320px checks; long-label check; selected-state check.
NEXT: check the draft against what the requester actually meant, answer the
clarifying questions, and confirm the criteria before anyone writes code.
These are a draft to agree on, not a decision the AI made for you.Where this fits in NewPrompt
Turning a requirement into acceptance criteria is a product-and-prompt-craft step that sits before the building, and NewPrompt gives you the structure for it, not a stamp of approval. The Product Requirements Assistant reframes a rough request into a problem statement, testable criteria, and an out-of-scope list; the Add Success Criteria to a Prompt resource is the same "make done checkable" move at the level of a single prompt; and the System Prompt Generator is where you build your own version with the rules you want. Each hands you a prompt you run in your own AI tool; the criteria come back as a draft you and the requester decide on.
A few neighbors sit close to this step. Making the AI follow acceptance criteria works once you have criteria — it steers the output to satisfy them; this guide is the step before, where you produce the criteria from a requirement that didn't have any. Turning requirements into an execution plan answers "how will we build it," while acceptance criteria answer "how will we know it is built right" — you want the second before the first, so the plan has a target and the result has a test. And getting the model to ask clarifying questions is one move inside this step, not a rival to it: here the questions are a byproduct of drafting the criteria — the decisions the requirement left open — not the whole goal.
A requirement names the goal; acceptance criteria draw the finish line. Without a line drawn, the AI picks its own and starts running, you end up reviewing against a line only you can see, and "is this done?" turns into an argument nobody can settle. Writing the criteria first — each one checkable, the scope named, the unknowns parked as questions — is drawing the line where everyone can see it, before the race is run. The AI can draft where the line goes; whether it is in the right place, and whether it is the line the requester actually wanted, is the call you and they keep.