A task is one unit of work that ends in one pull request. Start one from New Work.
Choose a good first task
The best first task is small, real, and near existing tests. Something like
"add a --json flag to the export command, matching the output shape the import
command already accepts" gives Coroid a clear target and gives you a clear read
on the result.
Avoid, for a first run:
- anything touching authentication, payments or data migration
- work that needs a design decision you have not made yet
- vague cleanups — "improve error handling" has no finish line
Describe what you want
Write the outcome, not the implementation. Say what should be true when the work is done, and name anything non-obvious: files that matter, conventions to follow, things not to touch.
You do not need to write the plan. That is the first thing Coroid produces, and you get to approve it.
If there is context the code does not carry — an ADR, a style guide, a ticket — attach it. See Project context for what Coroid already knows without being told.
Review the specification
Coroid turns your description into a specification: what will be built, what is out of scope, and the acceptance criteria that decide success. It appears on the task's Specification tab.
Read it before anything gets built. If the acceptance criteria do not match what you actually want, fix them now — they are what the verification stage later tests against. See Specifications.
Approve the plan
For anything beyond a trivial change, the specification becomes a plan: an ordered set of steps. You approve it before code is written.
This is the cheapest place to intervene. Rejecting a plan costs you a minute. Rejecting a finished pull request costs an entire run.
Watch it run
Once approved, the task enters PENDING until an agent slot frees up, then
IN_PROGRESS. You can follow the run live: the steps taken, tools called, files
touched, and test output as it accumulates.
You do not have to watch. Notifications will tell you when it needs you or when it is done.
What to expect
- Duration is driven by the size of the change and how long your test suite takes, not by how many agent slots you own. Slots control how many tasks run at once.
NEEDS_HUMAN_REVIEWis not a failure. It means Coroid hit a decision only you can make. Answer it and the task continues.- Rework is normal. If the reviewer finds something, it goes back to the developer before you ever see it.
Next
Review and merge the result — what arrives, and what to check.