Acceptance criteria
Where Limn finds a ticket's acceptance criteria on each tracker, how the story check judges each one, and what every status means.
Acceptance criteria are the testable parts of a ticket: “a partial refund keeps the order open”, “no refunds after 30 days”. The story check judges the code against each one. This page says where Limn reads them from, what it does when a ticket has none, and what each status on a criterion means.
#Where Limn finds them
| Tracker | Where the criteria come from |
|---|---|
| Jira | The acceptance criteria field you choose for each issue type. "Limn picks" uses the field whose name best matches "Acceptance Criteria". |
| GitHub Issues | The issue's sub-issues, else a task list in the body, else an "Acceptance criteria" heading in the body. |
| Linear | The issue's sub-issues, else a task list in the description, else an "Acceptance criteria" heading. |
| Notion | The property you map as Acceptance criteria, else a task list or an "Acceptance criteria" heading in the page. |
The story check’s ticket block says where the criteria came from, for example “Criteria from: Acceptance Criteria · Change in Settings”. On Jira, choose the field in Settings → Integrations → Ticket fields. A change applies at once to every stored ticket of that type.
Criteria can be written any way: bullets, a numbered list, Given/When/Then scenarios, a table or prose. The check makes one entry per testable requirement.
A ticket with no criteria
When a ticket has no criteria written, AI works out a short numbered list from the title and description. Limn marks these “Worked out from the description” so nobody mistakes them for the ticket’s own. It is better to write the criteria in the ticket: the check is only as good as the ticket.
#What each status means
- Met: a pull request delivers it. The check names the pull request (“Done in #612”) and the evidence.
- Met outside code changes: no pull request delivers it and none needs to, because a person’s comment on the ticket says plainly it was done another way: a setting, content, a manual step or a decision. The criterion shows “Per Dana Wu’s comment, 4 Mar”, which opens that comment. See Ticket comments.
- Partly met: part of it is in the code; the check says which part is not.
- Not met: it is not in the code. The check says which pull request it belongs in (“Code in” or “Where this belongs”), so you can post it there as a gap.
- Can’t tell from the code: the code cannot answer it (a wording decision, a visual detail), or one of the pull requests could not be read. Limn never turns “could not look” into “not met”.
- Not checked: no check has run since the criterion appeared.
#How the counts work
“Met” and “Met outside code changes” both count as done, but they are counted apart, for example “4 met + 1 outside code of 6”. Partly met, Not met and Can’t tell all count as not done. The number on a This Sprint card comes from the same latest check.