This is the page the rest of the documentation refers back to. It names each stage of execution so other articles can be precise about where something happens.
The path
your description
│
▼
specification what will be built, and how you will know it worked
│
▼
plan the ordered steps, reviewed before any code is written
│
▼
build code and tests written in an isolated workspace
│
▼
verify your test suite, plus checks and quality gates
│
▼
review an automated review pass over the diff
│
▼
pull request on a branch, in your repository, waiting for youSpecification
Coroid does not start from your sentence. It first turns your description into a specification: what will be built, what is explicitly out of scope, and the acceptance criteria that decide whether the work succeeded.
This matters because the acceptance criteria are what the verification stage tests against later. A vague specification produces work that is hard to judge.
You can read and edit the specification on the task's Specification tab before execution begins.
Plan
For anything beyond a small change, the specification becomes a plan: an ordered set of steps, grouped into phases. You approve the plan before code is written.
Rejecting a plan is cheap and is the right move when the approach is wrong. Rejecting after the code is written is expensive. This is the stage where your judgement has the most leverage.
Build
An agent clones the repository into an isolated workspace and works there. It reads the code, writes the change, and writes or updates tests.
The workspace is disposable and per-task. Nothing an agent does touches your default branch, and two tasks running at the same time cannot see each other's work in progress.
Verify
Your own test suite runs first — that is the strongest signal available, because it encodes what your team already decided matters.
On top of that, quality gates run whatever your organization has configured: coverage thresholds, linting, security scanning, browser tests against a preview deployment. A blocking gate stops the task; an advisory gate records a finding and lets it continue.
Review
A reviewer agent reads the diff the way a colleague would and produces findings. Findings that can be fixed are sent back for rework; the rest are attached to the pull request so you see them.
This is why a Coroid pull request arrives already reviewed — not to replace your review, but so that your review is not the first one.
Pull request
The branch is pushed and a pull request is opened against your base branch, carrying the change, the tests, the verification results, and the review findings.
Coroid stops here. Merging is yours.
Task statuses
A task's status tells you where it is on the path above:
| Status | Meaning |
|---|---|
PENDING | Accepted, waiting for an available agent slot |
IN_PROGRESS | Actively being worked on |
PENDING_REVIEW | Work is done and reviewed, awaiting integration or approval |
COMPLETED | Delivered |
NEEDS_HUMAN_REVIEW | Coroid cannot proceed on its own and is asking you a question |
PAUSED | Temporarily stopped, resumable |
FAILED | Execution could not complete |
CANCELLED | Stopped by you |
WONT_FIX | Closed deliberately without doing the work |
What determines throughput
One agent slot runs one task at a time. Slots set how much work happens in parallel; they do not make any single task finish faster. A task's own duration is driven by the size of the change and how long your test suite takes.
Next
Agent roles — which agent handles which stage, and what each one is permitted to do.