Tasks

A task is the unit of work. It has a status, a priority, an assignee and a result that someone accepts. Everything else in the system revolves around this.

Board and list: one screen, two views

A project's tasks live on one page; the Board and Tasks tabs under the project header only change how they are shown:

• Board: columns by status. This is where tasks are moved: drag a card and the status changes. The one exception is a card in In review: dragging it to Done (accept) or Ready (send back) is the reviewer's decision, open only to the project manager, a workspace administrator and the owner. For everyone else those columns dim while the card is held, and the card cannot be dropped there. Sending back needs a comment, so the board asks you to do that in the task itself.
• List (the Tasks tab): a table grouped by status. This is where you sort, select many at once and edit in bulk. Extra columns (type, labels, due date, created date) are turned on in the Display menu.

By default the list is sorted by key, newest first: a task you just created is the first one in its group. To see the whole list from newest to oldest without status groups, open the Group: status menu next to Display and pick None; the choice is remembered. Click a column header to sort by it, click again to flip the direction.

Filters are shared between both views. Filter by role on the board, switch to the list, and the filter is still there. The view is part of the page address, so you can send a colleague a link to the board and the board is what opens.

Statuses

Status	What it means
Backlog	Written down, but not handed to anyone yet.
Ready	Free to take. For an agent it goes into the queue; a human picks it up.
Queued	Waiting in the dispatcher queue for a free agent with the right role.
Assigned	The dispatcher gave it to a specific agent and holds a lease for it.
In progress	Someone is working on it right now: an agent or a human.
Waiting for a human	The agent asked a question and stopped. No answer, no progress.
Blocked	Something outside is in the way: another task, an access, a decision.
In review	The result is submitted and waits to be accepted or returned.
Done	Accepted. A final state.
Failed	It did not work out: three returns in a row, or the agent gave up.
Cancelled	Decided against. A final state.

Three statuses are worth telling apart, because they get confused:

• Queued: the task is waiting for a free agent. Nobody is on it.
• Assigned: the dispatcher has already given it to a specific agent. While the lease holds, no other agent will take it.
• Waiting for a human: the agent asked a question and stopped. This is not a fault: the work openly stands still until someone answers.

Who may make which transition

The table below is assembled from the code itself, from the same array the system uses to decide. If something is missing here, the system will not allow it.

From	To	Who may	When
Backlog	Ready	human	The task was declared ready to work on.
Ready	Queued	platform, human	It went into the agent queue, either on its own, if an agent may be the assignee, or because a human queued it.
Ready	In progress	human	A human took the task.
Queued	Assigned	platform	The dispatcher gave it to a free agent with the right role.
Assigned	In progress	agent, human	The agent confirmed it started work.
Assigned	Queued	platform, agent, human	The agent declined the task or disappeared, so it went back to the queue.
In progress	Waiting for a human	agent, platform, human	The agent asked a question or requested approval and waits.
Waiting for a human	In progress	human	A human answered; work continues.
Waiting for a human	Queued	platform, human	The answer came too late: the agent that asked is gone. The task returned to the queue.
In progress	Blocked	platform, human	A blocking dependency on another task appeared.
Blocked	Ready	platform, human	The last blocking task was closed.
In progress	In review	agent, human	The result was submitted and awaits review.
In progress	Failed	agent, platform, human	The agent could not do it, or the rework attempts ran out.
In progress	Queued	platform, agent, human	The agent disappeared mid-work, so the task returned to the queue.
In review	Done	human, platform	The result was accepted by a human, or automatically on pull request merge.
In review	Ready	human, platform	The reviewer returned the task for rework.
Failed	Ready	human	A human restarted the task.
Backlog	Cancelled	human	Cancelled.
Ready	Cancelled	human	Cancelled.
Queued	Cancelled	human	Cancelled.
Blocked	Cancelled	human	Cancelled.

A few rules follow that are worth knowing in advance:

• Only the dispatcher can assign a task to an agent. You cannot move a task to “Assigned” by hand. Otherwise two agents would start the same work.
• A human accepts and returns. An agent cannot accept its own work. Every task in review is also listed in the project's Approvals section, next to dangerous commands. You can accept or return it right there, under the same rules as inside the task. Not every human can: accepting and returning is open only to the project manager, a workspace administrator and the owner, and the platform checks that on every path (in the task, in Approvals, by dragging on the board, in a bulk edit of the list), not only on the buttons.
• Returning for rework is not unlimited. The third return in a row sends the task to “Failed” instead of “Ready”. The platform warns about this before you press the button.
• A returned task first waits for the same agent. The agent that submitted it has its context in mind, and the fixes land on its own work. When the task enters the queue, for 15 minutes only that agent gets it, and before its other tasks; the task feed shows whom it waits for and until when. If the agent is offline, paused or out of its limit, there is no hold. If it goes offline within those 15 minutes or does not take the task, any suitable agent can take it. The automatic return on red GitHub checks works the same way.

Changing the status

Inside a task, the main next step is a button at the top right, on the line with the task key: “Ready for work”, “Launch”, “Send for review”, “Restart”, or “Take it on” when the task is for a person. The status itself is the first row, Status, of the properties on the right. That row also lists the other allowed transitions and, when there is nothing for you to do, says why: an agent has the task, it is waiting for an answer, it is waiting on its dependencies, it is under review.

The button only ever offers transitions the table above allows.

On the board and in the list you can change the status without opening the task:

• drag the card to another column;
• right-click a card or row (long press on a phone): the menu has status, assignee, priority and milestone, plus "Open in new tab", "Copy link", "Duplicate" and "Delete";
• from the keyboard: on a focused task, S for status (digits 1–9 pick an item by number), A for assignee, P for priority, M for milestone, ↵ to open, ⌫ to delete after a confirmation.

Only allowed transitions are ever offered. To move between sections, press G and a letter: G B for the board, G I for the inbox, G S for Workspace settings, G P for all projects. ⌘P (Ctrl+P) opens the project switcher.

Board display is your own setting, kept in your browser: card ordering, whether to show empty columns and done tasks, and what a card shows (labels, due date and more). Hiding or merging columns for everyone lives there too, under Project columns, if you can change project settings.

Creating a task

The “New task” button in the filter row opens a window: title, description, type, priority, assignee, milestone, labels and free-form fields. Only the title is required. The rest can be filled in later.

The title is a single line of up to 300 characters: line breaks and control characters are replaced with a space however the task is created or edited, in the interface, by an agent, by import or by an incoming hook. Older titles with line breaks are brought to one line the next time they are edited.

The “Ready to work on” checkbox in the corner of the window moves the task out of the backlog into “Ready” right after creation. For a task assigned to an agent that means it goes into the queue immediately.

“Create” saves the task and opens its page right away: next you usually attach files, link it to other tasks or start it. “Create another” saves the task and keeps the window open with the same settings, which is handy when you are entering a dozen similar tasks in a row.

The window keeps what you wrote. Close it by accident (a click outside, Esc) and the draft is kept and comes back the next time you open it, with a “Draft … restored” line. Start over throws it away. A draft lasts a week and stays in this browser only; files are not part of it, so attach them again. The new-project window works the same way.

Bringing in the tasks you already have

Nobody starts from an empty board. The “Import” section of a project takes a list you already keep somewhere else and turns it into tasks. The rights are the same as for creating a task by hand.

You can feed it three things: a Markdown file, a CSV file, or issues from a connected GitHub repository. A file can be uploaded or pasted as text. The extension decides how it is read.

Markdown is read the way you already write it:

• a heading becomes a task, and a deeper heading becomes a subtask of the one above it;
• a checklist item (- [ ] …) inside a section becomes a subtask of that heading, and a nested list becomes subtasks of that item, as deep as you nest it;
• - [x] arrives as done, - [ ] arrives in the backlog;
• a plain bullet with no checkbox does not become a task: it stays as text in the description of the task it belongs to.

Nothing is created until you say so. What the file produced first appears as a preview table, and every row can be edited there: title, type, priority, assignee, role, milestone, labels, even which task is the parent. A row you do not want is unticked and simply not created. Anything the parser found doubtful is listed above the table.

Issues from GitHub go through the same table rather than a separate path, so they get the same look-over before anything appears on the board. Issues you have already imported are marked as such, so importing the same repository twice will not give you two of everything.

Files attached to a task

You can attach a mockup, a log, an export: a file up to 20 MB, up to ten of them: text and Markdown, CSV and JSON, PDF, Word, Excel and PowerPoint documents, images (PNG, JPEG, SVG, WebP) and zip archives. The Spec section accepts the same types. The “Attach files” button is both in the creation window and in the right-hand column of an existing task: materials often arrive after the task is written.

The agent reads them. Files reach it together with the task, as names and short-lived download links, and the tool description says plainly that they are part of the assignment, not decoration. A link lives five minutes, so the agent downloads right away instead of postponing.

There is no way back: an agent does not upload files. It can ask a human for them (see Collaboration), but it never puts anything into storage itself: the client does not send the contents of your project files to the server.

Priorities

From P0 (critical) to P3 (low). Priority is not just for the eye: the dispatcher hands tasks to agents in priority order, and within one priority in queue order.

Assignee: human, agent or anyone

Each task records who should do it:

A role is recorded separately: developer, sysadmin, designer. An agent only receives tasks matching its role.

If a task has neither a role nor a specific assignee, it cannot be queued: there is nobody to hand it to. The platform says so in advance instead of letting you press the button.

The same rule stops you from removing the last target of a task that is already queued or in progress: if both the role and the assignee are taken off, the dispatcher can no longer find it, and the edit is refused. Keep a role or an assignee, or first move the task back to Ready. The same goes for a bulk role edit to "No role" and for removing a member, see Settings.

The role has to exist. An agent that creates tasks takes roles from the project directory instead of inventing them. A task for a role the workspace does not have is refused, and the refusal lists the real ones. A role that exists but that nobody in the project holds is accepted with a warning to the agent: such a task is picked up only once someone is given the role.

Result and acceptance

When the work is done, the task gains a Result: a Markdown report, links to pull requests and commits, a test status. The task moves to “In review”.

A human can write the result too: a task may well be assigned to one. Every edit of the result lands in the task feed, so it is visible who rewrote it and when.

The reviewer then accepts it or returns it for rework. The reviewer is the project manager, a workspace administrator or the owner: other members see the result without the "Accept" and "Send back for changes" buttons. A return requires a comment: without an explanation the button does nothing: the agent has to know what to redo.

Links can be fixed by hand

Links to pull requests and commits are added by the agent when it submits work. Life edits them afterwards: a PR was recreated after a rebase, two branches were merged into one, a person finished the work and opened their own request. The button next to the links opens a list where they can be added, replaced and removed.

The edit goes into the task feed like any other, so it is visible who changed the links and when.

Submitted partially

An agent can submit work with caveats: the main thing is done, but one acceptance item could not be checked, say. Such a task arrives for review like any other, and a Still to do block appears under the result: what exactly is left, in the agent's own words.

The decision is yours and it is the same one: accept as is, or send it back with changes. Auto-acceptance does not apply to a partial submission: work the doer itself called unfinished is never closed silently.

Several repositories in one project

A project can hold several repositories: backend, frontend, infra. The task card then shows a "Repository" field: which of them this task writes code into.

With a single repository the field is absent entirely: there is nothing to choose, and a required setting with one possible answer would be noise in every card.

An agent is bound to one repository, and that is the crux. quiel init runs in a directory, and the agent works in a worktree of that very checkout, so it cannot switch repositories. The client reports its origin address to the platform, and the dispatcher does not hand it tasks for other repositories: otherwise the agent would dutifully write code into the wrong one.

Addresses are compared by meaning, not letter by letter: the ssh form git@host:owner/repo.git and the https form of the same repository are treated as one.

Task follow-ups

After almost every task something is left over: check it in the browser, write an e2e test, move a number into settings. Agents listed these in the report before too, as prose, inside the result. Turning such a paragraph into a task meant copying text by hand, and some follow-ups stayed as text nobody would find a week later.

Now the agent sends them as a list, and a "Follow-ups" block appears under the result: tick the ones you want and press "Create", or "Create all" in one click. Anything unnecessary is dismissed in the same place.

A created task lands in the backlog, not in the queue: sending it into work is your separate action. Its description carries a line saying which task it came from, and a link to the original appears in the dependency graph.

Required follow-ups are marked by the agent: that is "what is done cannot count as done without this". They come first, and a task created from one becomes a blocking dependency of the original.

Next to the "Accept" button you are reminded how many follow-ups are still undecided. It is a reminder, not a block: accepting a task with undecided follow-ups is allowed.

A task for the remainder

When an agent delivers work with reservations, the "What is left" block gets a "Create a task for the remainder" button. What is done is accepted, what is not becomes a separate task that blocks the original until it is closed.

This is the alternative to returning the whole task for rework: a full return sends the agent back over work that is already done.

Pressing twice is safe: a task has exactly one remainder task.

Dependencies

A task can be marked as depending on another (“blocked by”) or related to it. Dependencies are visible in the task itself and on the project graph.

A dependency’s number is a link: click it to open that task. In the edit window it opens in a new tab, so nothing unsaved is lost.

This is more than a label: an agent taking a task receives the results of the tasks it depends on: “what was done before”. That way it does not ask again about something already decided.

Milestones

A milestone is a deadline with a set of tasks: a sprint, a release, a stage. It has progress, counted from closed tasks.

On a milestone page tasks are view-only; they are managed on the project board and task list.

Below the milestone cards is the timeline: each milestone gets a bar from its start to its deadline, a diamond on the deadline, and a red line for today. Switch between weeks and months. Done is green, in progress shows the share of closed tasks, overdue is red, not started is dashed with its start date.

You can set the start date in the milestone window next to the deadline. Without it, a milestone starts the day after the previous one in the plan is due, and the first one starts on the day it was created; the hint on the bar says where the start came from. A milestone without a deadline is not shown on the timeline.