Acceptance Criteria Generator

Acceptance criteria are the contract, not the code

Acceptance criteria define what 'done' means for a piece of work before anyone writes a line of code. They answer one question with no ambiguity: how will we know this feature actually works? Good criteria are testable - each one can be checked as pass or fail with no judgment call. Vague goals like 'the login should be fast' are not criteria; 'the login page responds within 500ms at the 95th percentile' is. The whole point is to remove the gap between what was asked for and what was built.

This generator produces criteria in two proven formats. Given/When/Then is Gherkin, the structure behind behavior-driven development and tools like Cucumber - it forces you to state a precondition, an action, and an expected outcome for every scenario. The checklist format is lighter weight for smaller tickets. Both emit clean Markdown with a definition-of-done block, and both are designed to be pasted directly into Claude Code as the specification to build against.

The Given / When / Then structure

• Given - the starting state or precondition. 'Given a registered user is on the login page.' This sets up the world before anything happens.
• When - the single action the user or system takes. 'When they submit a valid email and password.' Keep it to one action; multiple whens are a sign the scenario should be split.
• Then - the observable, checkable outcome. 'Then they are redirected to the dashboard.' If you cannot observe it, it is not a valid Then.
• And / But - optional extra conditions or outcomes, but use them sparingly. A scenario that needs four Ands is usually two scenarios.

Cover the edges, not just the happy path

The happy path is the easy 20% of the specification. The value of acceptance criteria lives in the edges: what happens with invalid input, with an expired token, when the network drops mid-request, when two users act at once, when a limit is hit. Most production bugs are edge cases that nobody wrote a criterion for, so nobody built for them and nobody tested them. Before you consider criteria complete, walk the list and ask for each scenario: what is the failure mode, and is there a Then that describes it?

The definition of done catches the invisible work

Acceptance criteria describe behavior; the definition of done describes the non-negotiables that apply to every ticket regardless of behavior - tests written, docs updated, no new linter errors, security-sensitive paths reviewed, accessibility checked. Keeping these in a separate block means they never get forgotten in the rush to ship the visible feature. A feature that works but ships with no tests and a broken screen reader is not done; the definition-of-done block is where you encode that standard once and reuse it everywhere.

Handing acceptance criteria to Claude Code

Acceptance criteria are close to the ideal input for Claude Code, because they are an unambiguous specification. Paste the criteria in and ask it to implement against them, then paste them again and ask it to write the tests that prove each scenario. Because each Given/When/Then maps almost one-to-one onto a test case, the model can generate a test suite that mirrors your criteria exactly - which means your tests and your spec stay in sync by construction.

1. Write the criteria first, using this tool, before asking for any implementation.
2. Paste them into Claude Code with 'Implement exactly these acceptance criteria, and stop if any is ambiguous.'
3. Then ask 'Write one test per scenario above, named after the scenario, and show me which criteria are not yet covered.'
4. Use the definition-of-done block as a final gate: 'Confirm each item in the definition of done is satisfied before you call this complete.'

Signs your criteria need more work

• A criterion uses a subjective word - fast, easy, intuitive, clean - with no measurable threshold behind it.
• There is only a happy path and no failure or edge scenarios at all.
• A single scenario has three Whens, which means it is really three scenarios wearing one hat.
• The Then describes an internal implementation detail rather than an observable outcome the user or a test can see.
• No definition of done, so 'done' silently means 'the code compiles' rather than 'it is tested, documented, and safe'.