The ticket is back a third time. Built, reviewed, returned. The code was never the problem. Nobody wrote down what done meant, so the engineer shipped the export, the reviewer expected the export plus the empty state, and the PM was waiting on the notification email. You can date the failure to the minute: sprint planning, two weeks ago, when a one-line issue went up on the screen, everyone nodded, and each person in the room signed off on a different feature.
Acceptance criteria would have caught it, and everyone in that room knows it. Writing them is the part nobody budgets for. A real refinement conversation can run 15 to 30 minutes per story, the upcoming cycle holds 30 issues, and no team consistently spends a day of meetings on it, so the first few issues get criteria and the rest get nodded through. Sharpening a draft is faster than facing a blank field, and that asymmetry is the whole page: pull the project into local files, let your AI draft a testable criteria block for each issue from its own description, the project doc, and its sibling issues, then have the tech lead review every block as a diff before it lands in Linear.
Your options
Writing them by hand in planning
The best acceptance criteria come out of a conversation. Product, engineering, and QA walking a story together is where misunderstandings die before any code is written, and nothing below replaces it. The trickiest 3 issues in any cycle should still get that room. The arithmetic is what breaks: 15 to 30 minutes per story, 30 stories, and refinement becomes a day-plus of meetings every cycle. Teams that enforce it with a Definition of Ready, a checklist an issue must pass before it enters the sprint, meet the other failure mode: a stage gate where work sits blocked over paperwork. So coverage decays, and the bounced ticket comes back.
Linear issue templates
Templates earn their place. Set a team default with an "Acceptance criteria" section and every new issue opens with the skeleton in place; form templates structure what non-members file. Two gaps. A placeholder is not content: the template gives you the heading, and the heading sits empty unless someone does the thinking. And templates apply when an issue is created, so the backlog and the cycle you already planned are untouched. Nothing checks whether the section under the heading ever got filled in, either. The skeleton is worth having. It is not criteria.
A chatbot per ticket
Paste a description into a chatbot, or one of the standalone criteria generators, and a plausible checklist or Given/When/Then block comes back in seconds, free. The drafting is genuinely useful. The context and the unit are the limits. The model sees exactly what you pasted, so the criteria restate the ticket rather than the spec, and the edge case living in a sibling issue never makes it in. And "ready to paste into Linear" means you are the integration: 30 issues is 30 round trips of copy, generate, read, paste, and by the 12th the tab-switching is the job.
An agent on Linear's MCP server
Linear's official MCP server can reach everything this job needs: list the cycle's issues, fetch the project doc, save a new description per issue. Put an agent with judgment in the middle and the capability is real. Two costs. Reads run call by call, one issue per fetch, with every response landing in the agent's context window as raw JSON, crowding the spec it is supposed to be drafting from. And writes land in the live workspace the moment they run, with no diff queue; any approval your client offers is a raw JSON tool call, not a word-level diff of the description. Linear keeps per-issue version history you can revert, about 10 minutes after each edit, but that is recovery after teammates have read the guess, not review before.
Scratch
Scratch gives the agent the same reach as files. The project's issues land as local files with the project doc beside them, read-only. The agent reads the spec and every sibling issue, then appends a criteria block to each issue description. Status, labels, assignees, and cycles have no write path, and a validator, if you set one, can require the block on every issue in the folder and ban filler like "works correctly". Every block comes back as a word-level diff for the tech lead to approve, sharpen, or reject. The cost is concrete: 30 blocks is 30 real reads, and Scratch leaves that to the tech lead on purpose. The criteria are a draft a human finishes.
| Option | Criteria, not placeholders | Spec and sibling context | Whole cycle at once | Reviewed before it lands |
|---|---|---|---|---|
| Hand-written in planning | Yes, the gold standard | Yes, the room has it | A day of meetings | It is the review |
| Issue templates | No, empty headings | No | New issues only | Nothing to review |
| Chatbot per ticket | Drafts | Only what you paste | 30 round trips | You are the pipeline |
| Agent on Linear MCP | Drafts | Fetched call by call | Yes, slowly | No, writes land live |
| Scratch | Drafts a human sharpens | The whole project folder | Yes, as files | Every block, as a diff |
How the loop works on your cycle
- Scratch pulls the project into files. Each issue lands as its own file: title, description, and its cycle and project as read-only metadata, with the project doc in the same folder. Status, labels, assignees, and cycles stay read-only. Nothing in Linear has changed, and the agent never holds a Linear credential.
- Your AI drafts a criteria block per issue. Point Claude, Codex, Cursor, or Copilot at the folder and give it the brief. For every issue in the upcoming cycle, append an "Acceptance criteria" section: 3 to 6 testable statements a reviewer can check, drawn from the issue, the project doc, and any sibling issue touching the same feature. Cover the empty state and the failure path. If a description already has criteria, leave them or propose edits, never replace them. If an issue is too thin to support criteria, write open questions instead and flag it for planning. The agent greps the folder, maps which issues touch which section of the spec, then drafts. Reading 30 issues and a spec as files takes it seconds; the same read through an API is a call per issue. This is the 99%: the day of refinement meetings nobody was going to book.
- The tech lead reviews each diff and publishes. Every block appears as a word-level diff under the untouched original description. Validators run first, if you set them: the block must exist on every issue in the cycle, and banned filler like "works correctly" is rejected. Approve per issue, sharpen the lines the agent got almost right, reject the guesses. Scratch writes only approved issues back through Linear's GraphQL API, at the API's own pace, one at a time. Rejecting a published block later puts the old description back. The last 1%, deciding what done actually means, stays with the team.
Run the trickiest 3 issues first. If those blocks read like your team wrote them, the other 27 are the same brief.
Where this pays off
- Before planning, not during. Criteria arrive drafted, and the meeting argues about the 4 blocks that deserve argument instead of writing 30 from a blank field.
- Delegating to coding agents. An agent assigned a Linear issue builds against the issue text, and criteria are the difference between a delegable ticket and a guess.
- Review stops re-litigating scope. The bounce dies because the reviewer checks boxes the whole team already approved.
- Thin tickets surface early. The issues that come back with open questions instead of criteria are the ones that needed the conversation all along.
Questions people ask
Will the AI overwrite what is already in a description?
No. The block is appended, everything above it stays as written, and the diff proves it. If a description already has criteria, the brief tells the agent to leave them or propose edits, and either way the change sits next to the original, word by word, before it lands.
Can Scratch create issues or apply templates in Linear?
No. Scratch's Linear connector edits issue titles and descriptions and project names and descriptions, nothing else. No issue creation, no status changes, no labels or assignees. If you want issue creation inside the reviewed loop, tell Curtis.
Will the AI just restate the ticket in bullet points?
It can. That is the failure mode of criteria written from the ticket alone, which is why the brief points it at the project doc and the sibling issues: the empty state, the permission case, and the failure path usually live there, not in the one-liner. The review catches the rest: a block that only re-bullets the title sits next to the original and dies in 5 seconds.
Can a validator require criteria on every issue in the cycle?
In Scratch, yes. A validator can fail any issue file in the cycle that is missing the block, and ban untestable filler while it is at it. The boundary is worth naming: it checks the issues Scratch pulled, it does not gate new issues created in Linear tomorrow. Pair it with a default template so new issues at least start with the heading.
What happens when an issue is 2 lines long?
Questions, not criteria. The brief tells the agent that an issue too thin to support testable statements gets open questions and a flag instead. Those flagged issues are your planning agenda: the 4 tickets that genuinely needed the conversation, found before the cycle starts instead of at review.
Are acceptance criteria the same as a Definition of Done?
No. Acceptance criteria are per-issue, the conditions this specific story must satisfy. A Definition of Done is the universal bar every piece of work clears: tests pass, docs updated, deployed. This page is about the per-issue layer, the one that goes missing 30 times a cycle. Keep the Definition of Done in your team standards, not pasted into every ticket.
Do AI-drafted criteria replace the planning conversation?
No. They are a starting point a human sharpens, not a substitute for product judgment. What changes is what the meeting spends itself on. Instead of writing 30 blocks from nothing, the room argues about the 4 the agent got wrong, which is the argument worth having.
Can I undo a published criteria block?
Yes, per issue. Reject a published change in Scratch and the previous description comes back. Linear also keeps its own per-issue version history, available about 10 minutes after an edit, as a second way back.
What format should the criteria take?
Your call. Checklist statements and Gherkin-style Given/When/Then both work. The brief sets the format and the agent applies it to all 30 issues identically, which is the part no group of humans manages by hand. Pick the one your reviewers actually read.
See it on your own cycle
The fastest way to judge the drafts is to read them against issues you wrote. See it run on your Linear workspace →, or download Scratch free, pull one project tonight, and run the brief on next cycle's 3 hardest issues before planning.