Acceptance Criteria Generator

Most acceptance criteria fail the same way. They restate the title of the ticket in the passive voice and stop. "The user can reset their password" gives you nothing to test, and two developers will build two different things from it.

A criterion earns its place when it is observable, binary and specific. Observable means someone outside the code can see whether it happened. Binary means no partial credit. Specific means the numbers are in it: how many characters, how many seconds, how many attempts before lockout.

The other common failure is scope. Criteria that cover only the happy path get signed off and then reopened, because the interesting half of any feature is what happens when something is missing, duplicated, expired, too large, offline or concurrent.

Given/When/Then comes from behaviour-driven development. Given establishes the starting state, When is the single action under test, Then is the observable result. Its value is that it forces you to state the state, which is where most ambiguity hides.

One action per scenario. The moment a scenario has two Whens it is two scenarios, and a failure will not tell you which half broke.

It is the wrong shape for some things. Latency, throughput, accessibility and data retention read better as plain constraints with numbers than as a contrived scenario. This tool produces both and puts each requirement in whichever form suits it.

A ticket written for a person leans on shared context. The developer knows the codebase, knows which conventions apply, and knows who to ask when something is unclear. Hand the same ticket to Claude Code, Cursor or Copilot and none of that holds. An agent that hits a gap does not ask. It picks something plausible and carries on.

So a spec for an agent has to say what a person would have inferred. Where the code goes. Which patterns to follow. What must not change. What done looks like as a command that either passes or fails. And an explicit instruction to stop and ask rather than invent when a decision is missing.

The agent-ready output from this tool is that spec: the same criteria with the implicit context made explicit, and the open questions moved to the top where they cannot get skipped.

They answer different questions. Acceptance criteria belong to one piece of work and describe what it must do. A definition of done is the same for every piece of work and describes the standard it has to meet: tested, reviewed, documented, observable, accessible, deployed.

Teams that run the two together end up relitigating whether something needs tests on every single ticket. Teams that keep them apart argue about the standard once and then stop.

This tool writes a definition of done alongside the criteria, tuned to the kind of work you described. Take the parts that fit and keep them stable across tickets. The value is in the consistency rather than in any one line.

It has never seen your codebase, your users or your compliance obligations. It works from the description you paste, and a thin description produces thin criteria. The quality of the output tracks the quality of the input more closely here than in most AI tools.

It will invent plausible detail if you let it. That is exactly why the open questions section exists. Read it first, because those are the places it would otherwise have guessed on your behalf.

Run the tool and nothing you paste is stored: it goes to the model, the result comes back, neither is written to a database. Submit the form to unlock more runs or to download the report and what you typed comes to us with your address, which is what the tick box on that form says. Either way, describe the feature rather than pasting proprietary code or customer data. It does not need either to do the job.