Boards

A board holds issues that should run in an order you choose instead of the moment they’re found. A trigger set to Add to a board drops each issue it finds into the board’s Inbox. You drag the cards into To do, which is split into ordered groups, and press Play. Jimothy then works through the groups from top to bottom, one card at a time or all at once per group, and stops after each card so you can review it.

Use a board when the order matters: a migration that has to land step by step, a batch of tickets that touch the same files, or a backlog you want to release a few at a time.

The columns

Column	What’s in it
Inbox	New cards. Issues a board trigger finds, and cards you add without a group. Nothing here runs.
To do	The groups, top to bottom, each with its cards still waiting to start, in order. Each group is marked in order or parallel.
In progress	Cards whose run is queued, running or waiting for a pipeline approval. Also failed or cancelled cards that are holding the board.
Review	Cards whose run succeeded. They wait here until you approve them.
Done	Approved and skipped cards, newest first. On a board set to carry on past failures, failed and cancelled cards too.

Creating a board

Click New board on the Boards page (sidebar → Boards), or use New board in the ⌘K palette. Inside a project, the palette offers New board in project first, and boards created from the project’s Boards tab go into that project.

The New board dialog (later Board settings, the gear on the board) has:

Field	Notes
Name	Required.
Jimothy project	Optional. Where the board shows in the sidebar’s project tree. No project puts it under No project.
Pipeline for cards you add	The pipeline for cards you add by hand. Cards a trigger finds use the trigger’s Runs pipeline.
When a card fails	Pause the board (default): the board stops until you retry or skip the failed card. Skip it and carry on: the failed card moves to Done and the next one starts.
To do groups · run top to bottom	One row per group: its name, In order or Parallel, and a pipeline. Each card’s pipeline (the default) runs every card with its own pipeline; picking a pipeline runs every card in the group with that one instead. The arrows reorder groups, and the trash button removes one.

A new board starts with one in-order group, Group 1. Add group (in the dialog, or under the groups on the board) adds another. Removing a group sends its cards back to the Inbox. You can’t remove a group while one of its cards is running.

Create board saves it and opens it.

Getting cards onto a board

From a trigger

In the trigger editor, set When it finds an issue to Add to a board and pick the Board. (Create the board first; with no boards the field says so.) Every trigger type has this option: Linear, Jira, GitHub, Slack, Todoist, TickTick, webhooks and schedules.

1. Open the trigger: the project’s Triggers tab, or All triggers in the ⌘K palette.
2. Set When it finds an issue → Add to a board.
3. Choose the Board and save.

Each matching issue becomes a card in the board’s Inbox, set to run with the trigger’s Runs pipeline. Then:

• An issue that’s already on the board isn’t added twice. Its card is updated with the latest title and description. If the card had finished (done, skipped, failed or cancelled), it goes back to the Inbox to wait for you.
• While a card is waiting, running or in review, the trigger treats the issue as in progress and doesn’t add it again, even with Run again when a processed issue is updated on. See Polling & dedup.
• A claim label is added when the card is added. The trigger’s on-start write-back happens when the card’s run starts, and the on-success and on-failure write-backs when it ends, as for any run the trigger started.
• If the card can’t be added (for example the board was deleted), the trigger records the error: Couldn’t add ENG-123 to its board: ….

The Boards page shows which triggers feed each board (fed by …).

By hand

Add card in the board header opens a dialog with Title (required), Description (available to the pipeline as {{issue.description}}) and Pipeline (default: the board’s Pipeline for cards you add). The card goes into the Inbox. The + on a group’s header adds the card straight into that group instead. Cards added by hand get a key like CARD-3-K2QF.

Putting cards in order

Drag cards to schedule them:

• from the Inbox into a group, or back;
• within a group, to change the order (cards run top to bottom);
• from one group to another;
• onto Done: a card in review is approved; a waiting, failed or cancelled card is skipped.

A running card can’t be dragged. A finished card dragged back into a group runs again when its turn comes.

Running a board

Play starts the board and Pause stops it from starting anything new. Runs already going keep going. The board header shows where it is: Paused, Running · group, Waiting for your review, or Running · waiting for cards, plus whether it pauses or carries on when a card fails.

While a board is playing, Jimothy works on the first group that still has unfinished cards:

• In order: the group’s first waiting card starts. The next one starts only when nothing in the group is running or in review, so each card waits for the previous one to be approved.
• Parallel: every waiting card in the group starts at once. Runs still respect Max concurrent runs (in Settings → General) and the pipeline’s own limit, so extra ones queue.

A group is finished when all its cards are approved or skipped (or, on a board that carries on, failed). Then the next group starts. Cards in later groups show Waiting for group until then. You can keep adding cards to a group that’s running; they’re picked up in turn.

Reviewing

A card whose run succeeds moves to Review and holds up the cards after it. Look at the run (click #number on the card), then click Approve on the card or drag it to Done. The next card, or the next group, starts. Run again (↺) on a card in review queues it to run again instead.

Approval steps inside the pipeline are separate: a card whose run reaches one shows Needs approval and stays in progress until you approve the step on the run page. See Approvals.

Building on the cards before

By default every card’s run branches from the pipeline’s base branch (usually main), so a card doesn’t see the work of the cards before it until their pull requests are merged. To have an in-order group build up one branch instead, open Board settings, click Merge cards into a group branch under the group, and keep or edit the suggested name (jimothy/<board>-<group>).

With a group branch:

• The branch is created from the pipeline’s base branch, and pushed, when the group’s first card starts.
• Each card’s run branches from the group branch, and {{run.baseBranch}} is the group branch, so the default pull request step opens its PR against it and review steps diff against it.
• Approve merges the card’s branch into the group branch and pushes it, then the next card starts from there. If the merge conflicts (say someone pushed to the group branch meanwhile), the card stays in Review with the error. Merge it yourself or run the card again, then approve.

When the group is done, open one pull request from the group branch to main. The board shows the branch under the group’s name. Group branches need a pipeline whose workspace is a worktree or a clone, and work only with in-order groups: parallel cards all start from the same commit, so there’s nothing for them to build on.

When a card fails

With Pause the board, a failed or cancelled card stays in In progress and the board pauses, with a banner: ENG-123 failed in Group 1. Run it again or skip it, then press play to carry on. Click Run again (↺) or Skip (⏭) on the card, then Play.

With Skip it and carry on, the failed card moves to Done and the board goes on with the next card.

A card whose run couldn’t start at all (its pipeline was deleted or has validation problems) fails with the reason, for example Can’t start: …, and is handled the same way.

Retrying the run from its own page also works: the card follows the run’s status.

Cards

Each card shows:

• the issue key and, for cards a trigger found, the trigger’s name, with a link to the issue;
• the title;
• a status: Waiting, Waiting for group, Queued, Running, Needs approval, Needs review, Done, Failed, Cancelled or Skipped;
• the run number, linking to the run;
• while running, a dot per step and how far it is, like 2/3 · Implement (with parallel steps joined: 3/5 · Unit tests + Lint);
• the error, if the card failed.

Buttons on a card, depending on its state:

Button	Shown for	Effect
Approve	Cards in review	Marks the card done so the next one can start.
Run again (↺)	Failed, cancelled and review cards	Puts the card back to waiting; it runs again when its turn comes.
Skip (⏭)	Failed and cancelled cards, and waiting cards in a group	Sets the card aside (to Done) so the cards after it can go.
Remove from board (×)	Any card that isn’t running	Deletes the card. Its run, if any, is kept.

Boards in the sidebar

Boards in the sidebar opens the list of every board. Its count shows how many boards are running (or, when none are, how many boards there are). The Boards page lists each board with running or paused, how many cards are in each column, the triggers that feed it, and Play / Pause and Open buttons. Use the project filter in the header to narrow it.

Boards in a project are also listed under the project in the sidebar tree, in a Boards section. A running board shows how many of its scheduled cards are done, like 3/7 (Inbox cards don’t count).

Rules and limits

• Deleting a board (trash button in the board header) removes it and its cards. Runs it started are kept. It’s refused while a trigger still adds issues to the board (A trigger still adds issues to this board. Delete or re-point it first.) or a card is running.
• A pipeline can’t be deleted while a board uses it, as its default pipeline, a group’s pipeline, or the pipeline of cards still waiting or running.
• Deleting a project moves its boards to No project.
• If Jimothy quits while cards are running, their cards catch up with the runs’ final status on the next launch, and running boards carry on. A card whose run was deleted fails with Its run was deleted.

Tip

A board set to Pause the board with one in-order group is the most careful setup: one issue at a time, each reviewed before the next starts, and nothing more runs after a failure until you’ve looked at it.