Boole - Acceptance Criteria Generator
Turn a rough feature idea into Given/When/Then criteria, edge cases, non-functional requirements and a definition of done, plus a version written for an AI coding agent.
Named after George Boole, whose algebra reduced logic to true and false. Every acceptance criterion should pass or fail just as cleanly.
Acceptance criteria are the conditions a feature has to satisfy before anyone can call it done, written precisely enough that two people reading them would build and test the same thing. The usual format is Given/When/Then, the Gherkin syntax from behaviour-driven development (BDD): given some starting state, when the user does one specific thing, then this observable outcome happens. Good criteria cover the unhappy paths as well as the happy one, put numbers on the non-functional constraints, and name the decisions the brief left open instead of quietly guessing them. Describe a feature in the tool below and it writes the user story and all of that, plus a version aimed at an AI coding agent. The scenarios also download as a .feature file, next to the PDF and Markdown.
When a free tool is not enough
Vague tickets are the most expensive thing in your backlog.
We run engineering teams as fractional CTOs and build software with them. The first thing we usually have to fix is the gap between what someone asked for and what actually got written down.
How to use Boole, the Acceptance Criteria Generator
Describe the feature
A user story, a paragraph from a brief, or rough notes from a conversation. Two sentences is enough to start. More detail gives sharper criteria.
Set the context
Choose the work type and who the criteria are for: a development team, an AI coding agent, or both. The output changes shape accordingly.
Read the open questions first
These are the decisions your description left open. Answering them before anyone writes code is the whole point of the exercise.
Take the criteria into your tracker
Copy the Given/When/Then scenarios and the non-functional requirements into the ticket. Keep the definition of done stable across tickets rather than regenerating it each time.
Hand the agent spec to your coding agent
If you work with Claude Code, Cursor or Copilot, the agent-ready block is written to paste straight in, with the constraints and unknowns stated rather than assumed.
What separates useful acceptance criteria from ceremony
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.
- Observable. A tester can see the outcome without reading the implementation.
- Binary. It happened or it did not. "Works well" is not a criterion.
- Specific. Thresholds, limits, timeouts and formats are written down, not implied.
- Independent. Each criterion can fail on its own, so a failure tells you where the bug is.
- Complete on the unhappy paths: empty, invalid, duplicate, expired, unauthorised, too large, concurrent, offline.
- Honest about the unknowns. Anything the brief did not decide goes in writing as an open question instead of getting guessed at in code.
Given / When / Then, and when to use something else
Given/When/Then acceptance criteria come from behaviour-driven development (BDD), and the syntax they are written in is called Gherkin. 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.
The tool works as a Gherkin generator too. Every scenario it writes is ready to copy from the Scenarios tab, or to download as a .feature file alongside the PDF and Markdown. A developer still has to write the step definitions before Cucumber, or a similar tool, can run them as tests.
- Given: the world before the action. Who is logged in, what exists, what state the record is in.
- When: exactly one action, described from the outside.
- Then: the observable outcome, including what the user sees and what the system records.
- And: more setup or more assertions. Never another action.
Spec-driven development: writing acceptance criteria for AI coding agents
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. Agree the spec first and let the agent build to it. That is spec-driven development in practice.
- State the observable contract, not the implementation. An agent will happily rewrite your architecture if the ticket reads like a design document.
- Name the verification command. Done should mean a specific test command exits zero.
- List the constraints: files and modules that must not change, patterns to follow, dependencies not to add.
- Put the unknowns at the top with an explicit instruction to ask rather than assume.
- Keep the scope narrow. A broad ticket produces a broad diff, and a broad diff is one nobody reviews properly.
Acceptance criteria vs test cases vs a definition of done
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.
Test cases are the third thing people mix up with both. A criterion says what must be true, and a test case is how someone checks it: the steps, the data and the expected result. One criterion often needs several. Given/When/Then narrows the gap, because a scenario written as a criterion can run as an automated test once a developer writes its step definitions.
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.
What this tool cannot do
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.
The description from your first run travels with your name, work email and company to our CRM, inbox and team chat, so a person can read it and reply. After that, what you paste goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Either way, describe the feature rather than pasting proprietary code or customer data. It does not need either to do the job.
Frequently asked questions
Acceptance criteria are the specific, testable conditions a feature must meet to be accepted as complete. You write them before the work starts, agree them between whoever asked for the feature and whoever builds it, and use them afterwards to decide whether it is done. If a criterion cannot be checked by someone who has not read the code, it is not a criterion.
Whoever owns the problem drafts them, usually the product owner or product manager. The developers and testers then sharpen them, because they are the ones who spot the missing edge cases. Write them before the work is estimated, and at the latest before anyone starts building: criteria written after the code just describe whatever got built. A generated first draft is useful here. It lists the edge cases and the open questions, so the refinement session can go straight to the decisions.
A scenario structure from behaviour-driven development. Given sets the starting state, When is the single action being tested, Then is the observable outcome. For example: given a user with an expired session, when they submit the form, then they see a re-authentication prompt and no data is saved. One action per scenario. Two Whens means two scenarios.
There is no correct number, but there is a useful signal. Past eight or nine scenarios, the story is probably two stories, and splitting it will give you better estimates and smaller pull requests. Under three usually means nobody has thought about the unhappy paths yet.
The same rules apply, except that whoever observes the outcome is usually another system. For an API, write the criteria against the contract: request and response shapes, status codes, validation errors, authorisation, idempotency, pagination limits, rate limits and what happens to existing consumers. A bug fix starts with a failing reproduction of the fault and ends with a regression check. An infrastructure change needs its rollout, rollback, monitoring and blast radius spelt out. Choose the matching work type in the tool and it writes the criteria around those checks.
It is faster at the mechanical part and better at the part people skip. Most hand-written criteria cover the happy path well and the edge cases inconsistently, because listing failure modes is tedious. The generator does not get bored, so it lists them and you edit down instead of starting from a blank ticket.
Because a ticket written for a person assumes shared context an agent does not have, and an agent missing context does not ask. It guesses plausibly. The agent-ready spec states the conventions, the files not to touch, the verification command and the open questions, so the guessing has nowhere to happen.
Free, with three runs per person and no paid tier. Before the first result we ask for your name, work email and company, and for you to accept the terms. The description from your first run travels with those details to our CRM, inbox and team chat, so a person can read it and reply. After that, what you paste goes to the model. We keep each result, which can quote what you put in: it is emailed to you as a PDF and saved in our CRM. Keep personal data and anything confidential out of it.
Yes, with no attribution required. Read it before you ship it, as you would anything a model generated.
Related from Metamindz
- CTO-led software developmentTeams that ship, with the specification discipline that makes shipping repeatable.
- Fractional CTOSenior technical leadership on a retainer, including ownership of how work gets defined and delivered.
- AI adoption for engineering teamsReal throughput from AI coding tools, which starts with tickets an agent can actually execute.
- All free tools
Also known as: Gherkin Generator, User Story Generator, BDD Generator.
Published