Acceptance criteria are one of those things that looks like work but often isn't. Someone writes "user can log in," everyone nods, the ticket moves to dev, and three weeks later you're arguing about whether "log in" includes SSO, expired sessions, locked accounts, or a mobile browser on iOS 16. It doesn't. Nobody wrote that down.

AI acceptance criteria prompts can fix a lot of that friction. Not by thinking for you. By forcing you to write things down before the conversation gets expensive.

Here's the honest version of how this works: AI is fast at structure and embarrassingly bad at judgment. It'll hand you a neat Given/When/Then block with the confidence of someone who has definitely shipped software before. Some of it will be right. Some of it will be invented. You're the one who knows which is which.

That's the whole job.

Why acceptance criteria are broken before AI even enters the room

Most acceptance criteria fail at the source. Someone had a vague idea, typed a vague ticket, and called it a requirement. By the time it hits QA, the criteria have three interpretations and none of them are what the stakeholder meant.

The usual causes: tickets written in a meeting when everyone was already thinking about lunch, scope captured verbally and never reconciled, "done" defined by whoever felt like closing the ticket, edge cases discovered in production by angry users.

AI doesn't fix any of that. It just processes whatever you give it. And as Rule #13 in Don't Replace Me makes clear: garbage in, garbage out. Give AI a vague request and it returns confident fake precision. The output looks like real criteria. It has headers and bullet points and test scenarios. It's structured nonsense dressed up in a table.

The prompts below treat AI as a drafting assistant, not a product owner. You bring the judgment. It brings the structure, the edge-case questions, and the speed. If you're new to using AI for structured work tasks, the no-BS starter guide to using AI at work covers the mindset before you get into specific prompts.

What to never paste into AI tools before you start

Before the prompts: a real warning, not a legal disclaimer someone copy-pasted.

Do not put any of the following into unapproved AI tools:

Check what your organization has approved for AI use. If you're not sure, ask before you paste. "I used the free tier and it seemed fine" is not a data handling policy. The question of whether to tell your boss you use AI is related here, especially if your company doesn't have a clear AI policy yet.

AI acceptance criteria prompts: the reusable formula

Every prompt in this list follows a pattern you can adapt:

Role: You are a product requirements analyst helping a team write testable acceptance criteria.

Context: [Paste the vague request, ticket, or notes here. Remove anything sensitive.]

Task: [Specific thing you want: criteria, edge cases, test scenarios, stakeholder questions, etc.]

Constraints: [Any known limits: platform, audience, regulatory environment, done definition.]

Output format: [Given/When/Then, numbered list, table, plain prose, etc.]

The formula matters because AI responds to specificity. "Write acceptance criteria for this" gets you generic output. "Write Given/When/Then acceptance criteria for a logged-out user attempting to access a premium feature on mobile web, flagging any scope you're assuming" gets you something you can actually review.

This came from a book.

Don't Replace Me

200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.

Get the Book →

The 10 prompts

Prompt 1: Turn a vague request into testable acceptance criteria

Use this when a ticket says something like "make the checkout flow better."

You are a product analyst. I have a vague feature request: [paste request]. Convert it into 5-8 testable acceptance criteria in Given/When/Then format. For each criterion, flag any assumption you're making about scope, user type, or system behavior. Do not invent business rules. Where you're uncertain, write [ASSUMPTION: describe it] so I can verify with stakeholders.

Review everything flagged as an assumption. Those are your open questions. Answer them before the ticket moves.

Prompt 2: Convert notes into Given/When/Then examples

Use this after a meeting where someone captured requirements in a doc but they're messy.

Here are my raw notes from a requirements conversation: [paste notes, no sensitive data]. Convert these into Given/When/Then acceptance criteria. Preserve the original intent. Where the notes are ambiguous or contradictory, flag the specific conflict instead of resolving it yourself. Output as a numbered list, one scenario per item.

The goal isn't clean output. It's surfacing the conflicts before they become bugs.

Prompt 3: Find ambiguity in an existing ticket

Use this when you suspect a ticket is vaguer than it looks.

Here is a draft acceptance criterion or ticket description: [paste it]. Identify every term or phrase that could be interpreted more than one way. For each ambiguity, explain the different possible interpretations and suggest a clarifying question to ask the stakeholder. Do not resolve the ambiguities yourself.

This is one of the most useful things AI can do: play dumb in exactly the right places. If you use the AI workflow audit prompts framework to map your ticket-writing process, this prompt fits naturally into the definition-of-ready gate.

Prompt 4: Map happy paths and edge cases

Use this when you've got the main flow covered but you know there's something lurking.

Here is a user flow for [feature name]: [describe the happy path]. Generate a list of edge cases and error states that a QA team should consider. Organize by: input edge cases, system state edge cases, permission/role edge cases, timing/concurrency edge cases, and failure/error states. Flag any that might have accessibility or security implications.

Do not treat this as a complete test plan. Treat it as a starting checklist that your QA team then owns.

Prompt 5: Define done vs. not done

Use this to create a clear scope boundary before something goes into a sprint.

I'm writing acceptance criteria for [feature]. Help me define what is explicitly IN scope (done) and what is explicitly OUT of scope (not done) for this ticket. Use the following context: [paste relevant details]. For each out-of-scope item, note whether it needs a separate ticket or a stakeholder decision. Output as two lists: Done When and Not Done (Deferred or Descoped).

The "Not Done" list is often worth more than the "Done" list. It stops scope creep before it starts.

Prompt 6: Check accessibility, privacy, security, and data requirements

Use this before a ticket goes to dev, not after.

Here are the acceptance criteria for [feature]: [paste criteria]. Review them for gaps in four areas: accessibility (WCAG 2.1 AA), privacy (data collection, retention, consent), security (authentication, authorization, input validation), and data handling (PII exposure, logging, third-party data sharing). For each area, flag what's missing or unclear. Note that your output should prompt human review by qualified specialists, not replace it.

This prompt does not replace your security team, your privacy counsel, or your accessibility reviewer. It surfaces the questions so you bring the right people into the conversation earlier. For anything touching real risk, the AI risk assessment prompts cover how to structure that conversation with the right stakeholders.

Prompt 7: Create QA test scenarios

Use this to give a QA team something concrete to start from.

Here are acceptance criteria for [feature]: [paste criteria]. Generate a QA test scenario list including: positive test cases (expected behavior), negative test cases (invalid inputs, unauthorized access, system errors), boundary tests, and regression considerations. Format as a table with columns: Test ID, Scenario, Precondition, Steps, Expected Result. Mark any scenario where the expected result is unclear given the current criteria.

Every "expected result unclear" row is a ticket that will get reopened if you ship it.

Prompt 8: Prepare stakeholder clarification questions

Use this before a refinement session so you arrive with specific questions, not general confusion.

I'm preparing for a requirements conversation about [feature]. Here are the draft criteria so far: [paste draft]. Generate a list of clarifying questions to ask stakeholders, organized by: scope questions, business rule questions, user/persona questions, integration and dependency questions, and launch or rollout questions. Phrase each question plainly. I'll use these to run the conversation, not replace it.

Arriving with sharp questions is how you run a good requirements session. Arriving with AI-generated criteria as if they're final is how you run a bad one.

Prompt 9: Rewrite criteria for non-technical stakeholders

Use this when you need to get sign-off from someone who doesn't read tickets.

Here are acceptance criteria written for engineers: [paste criteria]. Rewrite them in plain language for a non-technical stakeholder review. Focus on: what the user will be able to do, what they won't be able to do, what happens if something goes wrong, and what the business impact is. Avoid technical jargon. Flag any criterion that might require a business decision before the stakeholder can approve it.

This works well alongside the AI briefing document prompts if you need to package the whole thing into a formal sign-off document for leadership.

Prompt 10: Run a pre-ship honesty check

Use this the day before you ship, not the day after.

Here are the final acceptance criteria for [feature] and the current implementation status: [paste both]. Run a pre-ship honesty check. For each criterion: mark it as Verified (evidence exists), Assumed (likely but untested), Open (still unclear), or Risk (known gap). List any open questions that need an answer before launch. List any stakeholder, team, or function that should be looped in based on risk level. Be direct. Do not soften gaps.

The output of this prompt is not a green light. It's a risk register. Someone with authority over the launch needs to see it and make a call.

What AI can't do here, and who should own it

AI will draft criteria. It will not make product decisions. It has no idea what your customers actually need, what your legal team has approved, what your SLAs say, or what "done" means to your executive sponsor.

Every prompt above produces a draft. Drafts need owners. The owner is a named human with accountability for the decision.

When the work affects real risk, escalate to the right people:

AI can prompt you to ask the right questions. It can't answer them. That's not a limitation to work around. That's the job staying human. If you want to understand where that line sits more broadly, what AI can and can't do is worth reading before you start delegating anything consequential.

For a broader framework on using AI for structured work without outsourcing the judgment, the AI project management prompts collection covers briefs, risk logs, and stakeholder updates with the same approach.

Frequently asked questions

What are AI acceptance criteria prompts?

AI acceptance criteria prompts are structured instructions you give to tools like ChatGPT or Claude to help convert vague requests, notes, or tickets into testable acceptance criteria. They work best as a drafting starting point. A human with product knowledge needs to verify every output before it's treated as final.

Can AI write acceptance criteria by itself?

AI can draft acceptance criteria quickly, but it will invent business rules, miss context, and present assumptions as facts unless you explicitly tell it not to. The prompts here are designed to surface those gaps rather than hide them. A qualified owner needs to review, correct, and sign off on any AI-generated criteria.

What's the difference between AI-drafted criteria and real acceptance criteria?

Real acceptance criteria have named owners, verified business rules, confirmed edge cases, and explicit scope boundaries. AI-drafted criteria have structure. The difference is accountability. Use AI to get to structure faster, then do the work of verification before the ticket moves.

Should I paste ticket details into ChatGPT or Claude?

Only if your organization has approved that tool for the data you're pasting. Never paste customer PII, security vulnerabilities, unreleased product details, legal content, financial forecasts, or confidential strategy into unapproved AI tools. When in doubt, describe the scenario in abstract terms instead of pasting the actual data.

What format should acceptance criteria be in?

Given/When/Then (Gherkin format) is the most common for testable criteria because it separates precondition, action, and expected outcome clearly. Plain numbered lists work for simpler requirements. The format matters less than the specificity. Vague Given/When/Then is still vague.

Any time your acceptance criteria touch data collection, user authentication, financial transactions, health information, content moderation, third-party integrations, or anything regulated in your industry or jurisdiction. If you used Prompt 6 and it flagged gaps, those flags are your escalation trigger. Don't ship past them without a sign-off from the right specialist.

If you want the full framework for staying useful while the tools get faster, Don't Replace Me is the field guide. It won't write your acceptance criteria. Neither should anything else you haven't reviewed.