Skip to content

Tasks


Track long-running work by state, then inspect its result, changes, checks, and proof.

Task lifecycle from queued through terminal states01Queuedready to start02Runningwork in progress03Waiting for inputCCompletedFFailedXCancelledresultchangeschecksproofevery Task returnsTask lifecycle from queued through terminal states01Queuedready to start02Runningwork in progress03Waiting for inputCCompletedFFailedXCancelledevery Task returnsresultchangeschecksproof
A Task keeps its state and returns four inspectable parts.

A task is work that outlives a single reply: an implementation, an audit, a migration. It has a state you can read at a glance and a receipt you can inspect when it finishes.

#Read the state first

StateMeaning
QueuedAccepted, not started
RunningWorking now
Waiting on youAn ask or an approval is blocking the next step
CompletedFinished with a result
FailedStopped on an error or a failed check
CancelledStopped on purpose

Labels vary slightly by app, but a task is never done because a message sounded confident. The state says so.

Capture pending: A running task in the panel with its live statecapture pendingA running task in the panelwith its live state1440×900/
A running task in the panel with its live state

#Find it

Open a task from the thread that started it, from the panel's Tasks tab, from Inbox when it is waiting on you, from search, or with atoi task in the terminal. Every door opens the same task.

The four parts of a Task receipt01resultThe outcome the Task produced.02changesFiles and records changed by the Task.03checksCommands and tests that ran.04proofEvidence you can inspect.
Every Task returns a result, changes, checks, and proof.

#Read the receipt

A receipt has four parts.

  • Result: the outcome in plain words.
  • Changes: the files, records, or external state that changed, plus returned artifacts such as previews, screenshots, logs, or recordings.
  • Checks: the tests, builds, or reviews that ran, and what they showed.
  • Proof: the evidence that ties the result to what you asked for, and what remains open.

For a bug fix, proof means the reproduction, the root cause, why this change fixes it, and the test that keeps it fixed. A green build alone is not proof that a feature works.

#Answer what it is waiting on

When a task is waiting on you, open the ask before you approve anything. If the action is destructive, outward-facing, or changes permissions, check the exact target and payload first. See Asks and approvals.

#After it finishes

Accept the result, ask for a follow-up in the same thread, or open the artifact. In the terminal, continue the same task instead of starting a new one:

bash
atoi task continue <task-id> --prompt "Now implement it"

Read Sharing and invites next, before a result leaves your workspace.

Was this useful?