The task board
How work moves on the task board — boards and columns, who moves a task, tasks that wait for others, review, failing checks, stuck tasks, merging, people's tasks, issue trackers, plans and pausing.
The task board holds the work. Each card is one task, its column says where it stands, and the agents and people on a team all work from the same board. It is kept with the repository, or at the project's home when the project shares one. You find it under Tasks.
The Tasks view opens with the same guidance as this page (How the task board works). It is also listed in Settings → Help, under Guides.
Boards and tasks
Each team has a board of its own. Work no team owns, such as a specialist working alone, goes on the Solo board. Choose a board with Task board at the top of the view.
A project has a board of its own above its repositories. A project task is handed out as tasks in each repository and shows how they are going together. Switch between This repository and Whole project to see one or the other.
A board everyone shares
Settings → Project → Where tasks live decides where the board is kept:
- Automatic: your organisation's projects share the organisation's board, and other projects keep a board in each repository.
- Each repository keeps its own board.
- Hub (Teams): every repository of the project shares one board, kept by your team's hub.
- Organisation (Enterprise): every repository of the project shares your organisation's board.
On a shared board everyone sees and changes the same tasks, and a card says which machine is working on it. When that machine has gone quiet, Take over on the card brings the task to you.
On your organisation's board, the organisation's copy is the one that counts. The first time, an empty board takes this repository's tasks as its own. After that, when two people change the same thing on a task, both are told. While the organisation cannot be reached, the board waits and nothing new is started on it.
The columns
| Column | What it means |
|---|---|
| Backlog | Work not started yet, parked or still to sort. |
| To Do | Work not started yet, queued to be picked up. |
| In Progress | Work someone is doing now. |
| Review | Work its doer says is finished, waiting for a reviewer to approve it or send it back. |
| Blocked / Human | Work that cannot go on without something or someone: an answer, a person, or a task that came back from review too many times. |
| Done | Work that is closed. Each card says how it ended. |
Who moves a task
- An agent moves its own card: to In Progress when it starts, to Review when it says it is done, and to Blocked / Human when it cannot go on.
- The reviewer, usually the operations manager, moves a task from Review to Done when it approves it, or back to In Progress with what to fix.
- You can drag a card to another column, change its Status in the task's details, select several cards and use Move to, or press Execute to start the assigned agent on it now.
Finished tasks are archived after two weeks, but never one that unfinished work still waits for, or whose work is not yet reviewed and merged. You can bring any archived task back.
Tasks that wait for others
A task's Dependencies are the tasks it waits for. It is not started until each of them is Done, and then it starts by itself if someone is assigned to it.
When a task closes, each task waiting for it is handed a short note, shown in its details under Handed on from the tasks before it:
- what it did;
- the files it changed;
- the doubts its author raised;
- what review asked for and did not get;
- its known gaps.
If the task it waited for was cancelled, refused or handed on, the note says what will not arrive, so the next one can plan around it.
A task can also wait for part of the same plan in another repository. Its card says which one and how it stands.
Tasks that change the same files
When two tasks of a plan could run at the same time and change the same files, the plan says so, and the planner is asked to make one wait for the other. Nothing is held back by it: it is a warning, kept on both tasks. If their work does clash when it is merged, whoever resolves the conflict is told what each task did.
Review
On a team with an operations manager, the manager reviews a finished task against its Success criteria, or a reviewer on the team does. The member who did the work never reviews it.
Which tasks an agent reviews is the team's choice, on the team's page:
- Every task: the most careful, and the most expensive.
- Risky tasks only: tasks the plan marks careful or risky, big changes and security-sensitive files. Other tasks merge once their own tests pass. A new team starts here.
- Once, at the end of the plan: tasks merge once their own tests pass, and the plan's whole change is reviewed when its work is done.
A task whose own tests failed is always reviewed.
Some tasks wait in Review for you instead:
- every task, on a team with no operations manager;
- a task with a label your repository's policy says a person must review;
- a task its doer finished with doubts, or asked a person to look at.
Press Approve, or write what to change and press Request changes.
A specialist working alone does what you chose for it: it merges finished work, checks its own changes first, or holds each task in Review for you.
When checks fail
When a task's work is merged together with work it did not have, the repository's own checks run on the result. If they fail, nothing is merged until it is fixed, or until you press Merge anyway.
A failing check goes back to the member whose work it was as a fix task, with the end of the failing output and how to run it again. That covers the checks after a merge, a build of the task's branch and a pull request's checks. After two tries, or when a person did the work, it comes to your Inbox instead, where Ask the member to fix this sends it back for one more.
A member is told never to weaken a check to make it pass, and a change that skips or removes a test is shown to the reviewer.
When a task is stuck
A task can be sent back as many times as the team's review rounds allow, three unless you change it. After that it may get one more try on a stronger model, and then it stops in Blocked / Human for a person.
If the team has an operations manager, it works out why the task is stuck: the environment, the logic, something it depends on, the approach, or a passing failure. Then it proposes what to do next:
- try a different approach;
- split the task into smaller ones;
- accept it with known gaps;
- change the rest of the plan;
- stop the task.
The proposal comes to your Inbox with its recommendation first. You can set the team to take the recommendation instead, and overrule it later. A change to the plan always waits for your yes.
How a task is closed
A closed task says how it ended:
| Ending | What it means |
|---|---|
| Done | The work is finished. |
| Done with known gaps | Finished, with a list of what was left out, so whoever comes next knows. |
| Cancelled | The work is no longer wanted. A task that failed is recorded as Cancelled, never as finished. |
| Refused | The work will not be done as asked; it goes back to whoever gave it, with the reason. |
| Handed on | Someone else carries it on, and the card names them. |
A task in Blocked / Human says what it is blocked on.
From a task to your branch
Each member works in a folder of its own on a branch of its own, so two agents never change the same copy of a file and your own checkout is left alone.
- A task is approved.
- Its work is merged on a shared branch first, where clashes are resolved and the checks run.
- It then goes into the branch it is for, usually the plan's own. If you have that branch checked out with changes not yet committed, it waits, and Merge now, on the board, takes it in.
- A plan's work reaches the default branch only when you merge it, or press Open pull request, in Plans.
If you work straight on a default branch that nothing protects, approved work goes there as soon as it passes review. The app tells you when that is the case. To stop it, start the work from a feature branch, or protect the branch in the repository's rules: add it to Branches agents never change directly, or turn on Work is added through pull requests. See Policies.
People's tasks
A task given to a person starts no agent. It waits for them, and nothing treats it as stalled.
They find it in their Inbox and on its card, with Start, Mark done and Blocked. On a team with an operations manager, Mark done sends it to Review like any other task; on a team without one, the button is just Done.
A person's task is never given to an agent without their say. An agent that wants to hand it on asks them in their Inbox, and it moves only when they reassign it, unless they marked it Blocked.
If the team sets how many hours to wait for a person, the operations manager is asked what to do after that, and still does not take the task over. See People on a team.
GitHub Issues, Azure Boards and Linear
Settings → Project → Task tracking can keep the board in step with GitHub Issues, Azure Boards or Linear, so a teammate can work from the tracker instead of the board.
- The board stays the working copy. It reads the tracker back every five minutes.
- What happens there comes back. Closing an item finishes the task; Not planned or Removed cancels it; reopening it puts the task back where it was. Its comments reach the board and the agent working the task.
- When both sides changed the same thing, the tracker wins for the state and who it is assigned to, and the board wins for the title and description. The task gets a comment saying what was overruled.
- One machine writes each item, the one that linked it; others only read it.
- Linear maps each board column to one of the team's workflow states. Confirm the mapping once under Task tracking; until then the board only reads Linear.
Plans and the board
A plan is the team's answer to a job: its objective, the tasks, who does each and what each waits for, and acceptance criteria for each, which become the task's Success criteria.
Its tasks go on the board as soon as the plan is made. On a team that hands planned tasks out by itself, they start at once. Otherwise the plan waits as a draft until you press Approve and dispatch in Plans. Abandoning a plan cancels its open tasks.
When every task is done, the plan is wrapped up:
- An outcome report checks what shipped against what was planned.
- Each acceptance criterion is passed or failed.
- You look over the changes and merge them, or open a pull request.
- The plan closes.
A criterion nobody confirms within a day is recorded as not confirmed when the plan closes.
Pausing the board
Pause all, on Tasks from this chat under a conversation, holds the board: whatever an agent is in the middle of finishes, but nothing new is started. Resume all sends out again the tasks that were held back. A pause lasts until you resume, even across a restart.
Teams and specialists
How to build a specialist or a team, what each member runs on and who pays for it, where people fit in, how to write instructions, and who answers what.
Ask AI where you write
How to ask AI to write or change code and text right where you are writing, in the built-in editor and the Library — what to ask, accepting or rejecting a change, the one-click actions, suggestions as you type, which model answers, and how it is governed and counted.