Concept

Boards & tickets

A board is a workflow (columns) plus a typed schema (fields). Tickets are the units of work that move across it. Both are created and driven headlessly — and watched live.

Boards

A board is the durable, shared container for a slice of work — a feature, a migration, a research sweep. Create one from a name (and optionally a template or a described shape):

tix board create

tix board create --name "Chat feedback" --description "Triage inbound feedback"
# → board id (opaque) + slug + URL. List them anytime:
tix board list --format table

Boards are cheap and meant to be torn down. Nothing in the model assumes a forever-living board — see Ephemeral boards.

Columns & status

Columns are the visible workflow lanes (for example To review → In progress → Resolved). A ticket also carries a machine status — backlog, active, or a terminal state — which is what the ready queue and dependency resolution read. Moving a ticket sets its column and, optionally, its status in one call:

tix ticket move

tix ticket move PRODUCT-1 --column "In progress" --status active

Tickets

A ticket is a title plus a column, a status, tags, an optional type, and typed field values. Create one on the command line:

tix ticket create

tix ticket create --board <board-id> \
  --title "Checkout 500s on Safari" \
  --type bug --tag payments \
  --field severity=Critical

Agents rarely create one at a time. Pipe a JSON array or NDJSON on stdin and the whole set is inserted in a single atomic batch — the right shape for a fleet seeding a board:

Bulk create — one atomic request

cat items.ndjson | tix ticket create --board <board-id> -
# emits one NDJSON status line per item

Why batch, not loop

One request = one durable write. Batching keeps a fleet from hammering the same board with N separate mutations, and every command is idempotent and safe to retry (pass --idempotency-key).

Refs & identifiers

Boards are addressed by an opaque id from tix board list, or by slug with an explicit owner (--owner-type user|org --owner-id <id>). Tickets are addressed by their human key (PRODUCT-1), their id, or a unique title fragment. Refs are always explicit — there is no ambient "current board", because agents run stateless with the working directory reset between calls.

Watching live

Every create and move streams to the board's web view in realtime. Hand a teammate the board.url and they watch tickets appear and move — agent actions rendered in violet — without a login or a clone. That live window is the second half of the contract: agents drive, humans watch.