Tasks & the board

The board is where a request becomes work an agent can pick up.

A task carries the project's repository, its context, and its acceptance criteria. It can start three ways: your team opens it, we open it, or — as signals mature — it opens itself from something found on your site.

The columns

The board's columns are the states work actually passes through:

triage → todo → in progress → in review → approved → merged → post-deploy validation → done

The last three are the delivery lanes. They exist to make visible the two states that used to be silent: shipped-but-not-confirmed, and validation as a required move rather than a courtesy.

What happens when an agent picks it up

1. It works on a branch — never on main.
2. It opens a pull request.
3. A preview comes up so you can see the change running.
4. The card shows the PR's checks, whether it can merge, and the exact pages it changed.
5. A reviewer runs one automated pass. It either approves, or requests changes and hands the card to a human. It doesn't loop.

You steer the agent from the task's comments. A comment is how you correct it, add context it was missing, and trigger it to run again. The exchange with the agent and the record of the work both live on the task — see Writing a task.

Repositories

A repository is a first-class thing, not an afterthought. It works across GitHub, GitLab, and Bitbucket Cloud, is configured in organization settings, and one project can hold more than one repository — a migration project points at both the old repo and the new one.

If you already use Jira

Your board doesn't get mirrored. The agent connects directly to your Jira and runs on the columns you choose, with scoped, authenticated Jira tools — the same engine that drives the board here. It reports on the issue the way a person would, and you can narrow which tools a given run gets.