Backlog item

Use when a request, a review finding or leftover work has to become a task that a person or a Claude Code session can pick up later and finish without asking the author. Pair it with grill-before-build (decisions before the item) and department-brief (which backlog it belongs to).

Before writing

1. Look for duplicates. Search the backlog (issues, the tracker, the department's backlog file) by keywords and by the screen or file the work touches. If the item exists, add the new fact or criterion to it instead of filing a second one. If it was closed, link it and say why this is different.
2. One department. An item belongs to one backlog. Work for two departments is two items with a dependency.
3. Facts yourself, decisions from people. Look up what exists in the code and what was decided before; ask the person who asked only about choices. For anything non-trivial, interview first with grill-before-build.

The parts

• Title: what changes, in a few words ("Refund button on the order page"). Not "Fix bugs" or "Improve billing".
• Why: one or two lines on the problem and who has it, with a link to the report, finding or decision.
• Acceptance criteria: three to seven lines anyone can check without asking the author: an input and the visible result, a command and its output, a screen in a given state. Include the unhappy path and where it must work (phone width, both themes, staging).
• Out of scope: what not to do here, so the agent does not gold-plate and the reviewer does not ask.
• Dependencies: what must exist first (another item, a decision, access, a human approval) and what waits on it.

Checkable criteria

Too big? Split it

Signs: more than seven criteria; criteria for different departments; "and" in the title; a decision nobody has made yet; it cannot be finished and reviewed in one session and one pull request.

Split by a result someone can see, not by layer: each slice ships and is reviewed on its own. Example, "Refunds":

1. full refund from the order page; 2. partial refund with an amount; 3. refund email to the customer (its wording needs approval); 4. refunds in the monthly export. Group them under one epic and note the order. A "backend" item and a "frontend" item that are useless alone are not a split.

Example item

Title: Partial refund on the order page
Why: support refunds part of an order by hand in the payment provider today; mistakes are not visible in the order.
Acceptance criteria:
- An "Amount" field under Refund accepts 0.01 up to the unrefunded total; anything else shows the reason inline.
- After a refund the order shows "partly refunded" and the amount, and the history row names who refunded it.
- A failed refund leaves the order unchanged and says "Nothing was refunded. Retry".
- Works at phone width in light and dark; `npm test` passes.
Out of scope: refund emails (separate item), refunds in the export.
Depends on: "Full refund on the order page" (done).

When filing

• Filing is a proposal: the department lead orders and approves the backlog. Do not start an item you filed unless you are asked to.
• No secrets, customer data or private conversations in an item; summarise and link.
• Report: the item or its link, duplicates you found, any split with its order, and questions still open.