Anatomy of a good ticket

A ticket is the unit of work the agent picks up. What you put in it is the single biggest factor in whether the result is what you actually wanted, more than the model, the effort level, or anything in Settings.

The fields

• Title: short, like a commit subject.
• Description: markdown. Explain the change the way you'd explain it to a new hire: what, and why.
• Acceptance criteria: a checklist of specific, checkable statements. This is required: a ticket can't move to Ready without at least one item.
• Labels, priority, and dependencies: labels for filtering and routing, priority for ordering within Ready, and dependencies so a ticket waits until the ones it needs have shipped.

Why the acceptance checklist matters so much

Every ticket goes through two independent checks against that list: a reviewer that has to cite file:line evidence for each item, and a separate verifier, in a fresh session that never saw how the code was written, that re-derives whether the ticket is satisfied from the diff and the ticket text alone, with no access to the reviewer's reasoning.

Both of them are only as good as the list you gave them. "Add CSV export" is a guess about what you meant. This isn't:

• Adds a Download CSV button to the invoices list page
• Clicking it downloads all currently filtered invoices, not just the visible page
• The CSV includes columns: date, customer, amount, status
• Existing invoice tests still pass

If a ticket can't be checked off, the reviewer can't cite evidence for it, and the verifier can't confirm it, so it won't ship silently wrong. It ends up in Needs review instead, with a report of what was tried.

Getting started

The ticket form has inline guidance (a How to write a ticket the agent can ship link) if you want a reminder without leaving the page.