Tasks

A task is one unit of work that results in one pull request. It is what actually executes — plans, sprints and lanes are ways of organising tasks.

The header#

A row of chips summarises the task at a glance: its project, its type, the AI profile running it, and the QA checks applied — shown as the policy name, where it came from, and its version, for example Standard · From plan · Organisation policy · v6.

A padlock on the AI profile means it is fixed and cannot be changed now. The resolved QA policy is likewise pinned when execution begins, so altering the organisation policy later does not retroactively affect work already running.

Agent workflow#

Four agents run in sequence, each displaying its own state — Pending, running or done:

Architect → Developer → QA → Reviewer

This is the clearest indication of where a task stands. A task showing Developer done and QA Pending is waiting to be verified, not stalled.

Note that a stage can legitimately display Pending even on a finished task — tasks generated from a plan already have their specification and implementation plan, so the Architect stage has nothing further to do.

See Agent roles to learn what each agent can and cannot do.

Acceptance criteria#

The criteria from the specification, presented as a checklist with a status for each — Verified OK when a criterion has been confirmed.

Statuses reflect the current pipeline stage, so criteria are verified as the task progresses rather than all at once at the end.

This panel is what to consult when assessing a finished task. It shows what was promised and what was actually confirmed, which provides a clearer picture than merely checking whether the tests passed.

Execution trail#

Every execution recorded against the task. Each entry details the agent, its activity, the result, and the cost:

DEV · Generating code · Completed
4m 41s / 608.9k tokens · 16.2 g Est. CO2e / deepseek-v4-flash-0731

Duration, token usage, estimated carbon emissions and the exact model are all logged per execution — so if a task costs more than expected, you can identify which stage and which model caused it.

Expanding an execution reveals the full step-by-step trail: files read, commands run, agent reasoning, and every file changed along with its line counts (+25 / −0). Token entries show cache efficiency (9.1k used (90% cached)), which typically determines whether a run is expensive or inexpensive.

This is the view to open when you want to know how something was done rather than just what changed.

The remaining sections#

Usage & timeline reports attempts as well as cost — 1 attempts means it succeeded first time. A higher number indicates rework, which is the single most useful indicator of specification quality.

Dependencies & context lists the project and every linked dependency with its status. This helps you determine whether a task is waiting on something else or genuinely blocked.

Priority#

Tasks carry P0 (highest) through P3, defaulting to P2. Priority orders the queue when more tasks are waiting than there are free slots.

It does not add capacity. If everything is P0, nothing is — see Capacity and agent slots.

Statuses#

Every task status and what to do about it is in Task statuses. The two key points to note here are:

• PENDING It is not stuck. It is queued, awaiting a processing slot.
• NEEDS_HUMAN_REVIEW It is not a failure. It is a query. Respond to it and the task proceeds.

Intervening#

While a task is running, you can pause it, cancel it, or send it back for rework along with comments. To decide which option to use, see When a task becomes stuck or fails.

Related#

• Describing what you require
• Plans
• Agent roles