A task is a single unit of work. Under the hood it becomes an implementation: one autonomous run that takes your request from a plan, to code, to a pull request. Where a session is live and interactive, a task runs on its own and reports back.
Where tasks come from
- Directly — from the prompt card on your workspace home: pick a blueprint (bug fix, feature, or quick change), describe what you want to build, and choose a repository and model.
- From a brief — start an implementation from an approved brief so the agent works from a reviewed spec.
- From an automation — every automation run creates a task on a schedule.
The lifecycle
A task moves through clear states you can watch: pending → queued → running → completed (or failed, stopped, or cancelled), and it may pause in a waiting for input state to ask for your approval. Once its pull request is merged, it shows as merged.
While running, the task shows its blueprint steps — for example Sandbox setup → Plan → Analyze → Implement → Fix issues → Test → Open PR — along with an iteration count and the current step.
Previews & UI feedback
An implementation can serve a live preview of your app. On that preview you
can leave UI feedback — comments pinned to what you see, each tracked through
open → in progress → resolved (or ignored) — and the agent can act on them.
This makes review visual, not just diff-based.
Follow-ups, approvals & conflicts
When a task finishes (or fails), you can send follow-up instructions to request changes or fixes. If a step is waiting on you, you can approve it or reply with feedback. If a merge is blocked by conflicts, you can ask the agent to fix conflicts.
The pull request
Every task’s output is a pull request on your repo. You can Open PR, Merge, re-open, or close it, and its status (open, draft, merged, closed) is shown with a link to GitHub. If CI auto-fix is enabled, a failing CI run can trigger an automatic follow-up that pushes a fix.
See Review implementations, previews & UI feedback for how to work through a task’s output.