How a task becomes a pull request

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#

These stages are the same in both ways a task can run. In standard mode, the platform moves the task from one stage to the next. In Coordinator mode, the planning agent stays on the task as the Coordinator, gives each stage to the right agent and decides what happens after each result, including sending work back. Either way, a stage is closed by its own checks. See Agent roles for how the two modes differ.

Specification#

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.

The specification-driven development guide explains how to write testable criteria, set scope boundaries and carry the same definition of success through planning, implementation and review.

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, browser tests against a preview deployment, and the Security protections. 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. If the code already does what the task asks, there is nothing to push: QA verifies the unchanged code instead, and the task finishes without a pull request.

Coroid's task automation stops here. Merging is yours.

After the merge#

Open Releases to prepare the exact commit you intend to ship. A release can contain several merged pull requests, a direct commit, or work merged outside Coroid. The release gate and approvals concern that commit and a specific environment. Your pipeline deploys it; Coroid records an observed success or explicit attestation before showing it as shipped. A task marked COMPLETED or a merged pull request alone does not prove deployment.

Task statuses#

A task's status tells you where it is on the path above:

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 each work stage. Then see Releases for the post-merge path through your environments.