Cards and card templates

The card is the brief. Everything on it reaches the worker that picks it up, so the shape of your cards decides the quality of your runs more than any other single thing.

What a card can hold

• Title and description — the story itself.
• Fields you define: text, long text, numbers, dates, dropdowns, checkboxes, people, progress, tags, status.
• Priority, assignee, due date, labels and story points.
• Checklists — tasks with their own completion state.
• Attachments — files, images, links.
• Links to other cards — including the card in another workflow that this one was sent to, or came from.
• The discussion — see Discussion.

Card templates

A card template is a reusable card shape, set from the workflow's menu. Build one for the kind of work the workflow carries and the fields stop being optional in practice. (A card template shapes a card. A workflow template sets up a whole assembly line.)

Two examples worth copying:

Bug Environment (dropdown: production / staging / local) · Browser · Build · Steps to reproduce (long text) · Expected · Actual · Evidence (attachments)

Story User (who it is for) · Outcome (what changes for them) · Acceptance criteria (long text) · Out of scope · Design reference (link)

A QA agent given the first template can reproduce something. Given a title and a paragraph, it has to guess — and guessing is where the plausible-but-wrong runs come from.

Why fields beat prose

A dropdown with three environments cannot be ambiguous. A sentence saying "it happens on the live site sometimes" can be read four ways, and a worker will pick one.

Fields also make the workflow searchable and filterable, which is what turns a pile of cards into something a person can steer.

Checklists

Checklist items are visible to the worker and are a good way to express "all of these, and say which ones you did". A QA station whose cards carry a checklist of the flows to cover gets reports that walk the list.

Scheduled cards

A card can be scheduled. A scheduled card on a station that starts on create is a standing job: a weekly dependency audit, a nightly regression pass.

Next

• What the worker reads — exactly what is sent when a run starts.
• Discussion.

Evidence: what was actually checked

"QA passed" is a claim. A card's Evidence shows what the claim rests on, gathered from what each part of CodeBook recorded:

• Pull requests — state, size, what your repository's own checks said, the risk score with its reasons, and the deploy result.
• Commands run on your runner — which command, against which commit, how it ended, and the end of the output when it failed.
• Browser checks — a recording of what the browser did that you can play on the card, each step in words and whether it passed, the page's console errors and failed requests, and the screenshot.
• Reviews — each reviewer's verdict, score and reasons.
• Factory scores — what a scorer gave the run, and why.
• Production — incidents worked on the card.

What was typed into a form field during a browser check is never shown.