Board

The board is where a project’s tickets live. What sets it apart from other task tools is that humans and minions share the same board: a ticket you raise can be picked up by a minion on its own, worked on, and left waiting for your review.

The board is opt-in per project. Turn it on in the project’s Settings tab and it appears under Board in the sidebar. If several projects have a board, the project name in the header doubles as the switcher.

Tickets

A ticket moves through five statuses.

Status	Meaning
Backlog	Not yet committed to
To Do	Committed to (pulled into a sprint)
Doing	Started
Review	Finished, waiting for approval
Done	Approved

Parent/child nesting goes two levels deep. A ticket with children gets an EPIC badge and a progress bar showing how many of its children are done. There are no grandchildren
The assignee is either a person or a minion, never both — setting one clears the other
Acceptance criteria (a checklist) are what a minion treats as the definition of done. See Handing work to minions
Priority (low / normal / high / urgent) is for display and filtering. It does not decide execution order — the order on the board does
To refer to a ticket in chat, use the [task:UUID] tag. Hover a card to get the copy button

Three views

Switch with the tabs in the header. These are the same tickets seen for different purposes — you are not meant to pick one and stay there.

View	Question it answers
Kanban	What is moving right now?
Planning	What goes into the next sprint?
Table	What should I work on first?

Kanban

The five-column board. Drag cards between columns, and reorder within a column — that order is also the order minions pick work up in.

⚙ Display chooses what each card shows (priority, milestone, sprint, subtask count, due date, assignee). The choice is remembered per project in your browser
Only tickets in the sprint narrows the board to the running sprint. It turns itself off when no sprint is running
Rest the pointer on a card and its family (epic and children) lights up

Planning

Two stacked lists: the selected sprint on top, the backlog below. Drag a ticket up and it joins the sprint. You can select several and move them together.

Table

A spreadsheet-style grid — one row per ticket, one column per field, cells edited in place. A card can only carry a few pieces of information, so when you want to compare everything side by side, use this view.

Click a column header to sort (ascending → descending → off). Turning it off returns to the manual order
Drag the right edge of a header to resize a column. Widths are remembered per project in your browser. Double-click a divider to reset that column, or Reset column widths in the toolbar for all of them
The title column stays put while you scroll sideways
Group by status, assignee, or any option field. Each heading carries a count, so “how much is piled up in this bucket” reads straight off the page
Select rows and a bulk edit bar appears — set the same value on every selected ticket at once
Export CSV writes out the current filter and sort, with formula columns exported as their calculated values

Custom fields

You can add your own fields to tickets. The main use is declaring rating fields — “user impact”, “business impact”, “estimate” — and letting a combined score decide the order.

Fields are shared across the workspace and set up from Edit fields in the Table view. A workspace that has not set any up sees nothing — no extra columns, inputs or filters — so the feature stays out of the way when you do not want it.

Drag the ⋮⋮ handle to reorder fields. That order is what the table’s columns, the chips on cards and the filter bar all follow.

Field types

Type	Used for
Options	Ratings, categories. This is what a rating field is
Number	Estimates, reach (can carry a unit)
Checkbox	Yes/no
Date	A date other than the due date
Text	A one-line note
Formula	A read-only value calculated from other fields

Build rating fields as Options. A number field would work, but options let “3” and “medium” be the same thing, which keeps entry, filtering and grouping straightforward. A new option field starts life with a ready-made 1–5 scale, so naming it is all it takes.

Each option can carry a score — the number a formula reads. Giving options colours makes them readable at a glance on both the board and the table.

Turning axes into one number

Combine axes with a Formula field. Create one called “Priority Point”, pick Sum, tick “user impact” and “business impact”, and it fills itself with their total. Pick Product and it multiplies instead.

A formula column behaves like any other: click its header to sort by score, or show it on cards. The value is never stored — it is calculated every time it is displayed, so changing the weights or the operation reorders every ticket immediately.

Formula columns cannot be edited by hand. If you want to type a value, use a number field.

Not rated is not zero

If any field a formula reads is empty, the formula shows ”—”, not 0. Treating an unrated ticket as worthless would defeat the point of having rating fields at all.

Unrated tickets always sort to the bottom, ascending or descending. To find them, use “Not rated only” in the filter bar.

Filtering

Option, checkbox and formula fields can be filtered from the filter bar. This is not table-only — the same filters apply to the Kanban board.

For formula fields the only choice is “Not rated only”. To narrow by value, sort instead.

Showing fields on cards

Tick Show on Kanban cards in a field’s settings and it appears as a chip on the board. Fields with no value are left off.

Show too many and the board stops being readable, so keep it to what you need at a glance. The place to see everything is the Table.

Sprints

A sprint moves through planned → active → completed. Only one sprint can be active per project.

To start a sprint, every ticket in it must have:

an assignee
at least one acceptance criterion

If something is missing the sprint will not start, and you are shown exactly which tickets fall short. This gate exists to confirm the sprint is something minions can actually pick up: with no assignee nobody claims the work, and with no acceptance criteria there is no way to tell when it is finished.

When completing a sprint you choose what happens to unfinished tickets — back to the backlog (the default) or carried over to the next sprint.

Handing work to minions

A ticket in the active sprint, assigned to a minion, sitting in To Do or Doing, gets picked up by that minion on its own. Nobody has to tell it to start.

It receives the ticket’s title, description, priority, due date and acceptance criteria, along with the project context and the member list. The work runs in its own terminal session, which you can watch from the workspace terminal.

A minion only moves a ticket To Do → Doing (when it starts) and Doing → Review (once every acceptance criterion is met). It never moves anything to Done — approval stays with a person, or with a reviewing minion.

When it is unsure, it does not guess: the ticket stays in Doing and it raises a thread.

Custom fields and minions

Minions can read and write field values. “Fill in the estimate on this ticket” is a reasonable thing to ask.

They cannot change the field definitions — adding axes or editing options. Changing a rating field silently changes what every ticket’s priority means, so that decision stays with people.

Working across projects — assigning one minion to several boards
Core concepts — how the board relates to projects, workflows and routines