A task is one unit of work that results in one pull request. Start one from New Work.
Choose a suitable first task
The best first task is small, practical, and close to 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 provides you with a clear read
of the outcome.
Avoid, for a first run:
- anything related to authentication, payments or data migration
- work that requires a design decision you have not yet made
- vague cleanups — "improve error handling" has no clear finish line
Describe what you want
Write about the outcome, not the implementation. State what should be true once the work is completed, and mention anything non-obvious: relevant files, conventions to follow, and areas to avoid.
You do not need to write the plan. That is the first thing Coroid produces, and you get to authorise it.
If there is context not carried by the code — an ADR, a style guide, a ticket — attach it. See Project context to learn what Coroid already knows without needing to be 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 determine success. It appears on the task's Specifications tab.
Read it before any work begins. If the acceptance criteria do not match what you actually want, adjust them now — they form the basis for testing during the verification stage. See Specifications.
Authorise the plan
For anything beyond a minor change, the specification becomes a plan: an ordered set of steps. You authorise it before any code is written.
This is the cheapest point to intervene. Rejecting a plan takes just a minute. Rejecting a completed pull request wastes an entire run.
Watch it run
Once authorised, the task enters PENDING until an agent slot becomes available, then
IN_PROGRESS. You can follow the run live: the steps taken, tools used, files
modified, and test output as it accumulates.
You do not have to watch. Notifications will inform you when input is needed or when it is finished.
What to expect
- Duration depends on the size of the change and how long your test suite requires, not on the number of agent slots you have. Slots determine how many tasks run at the same time.
NEEDS_HUMAN_REVIEWis not a failure. It means Coroid encountered a decision only you can make. Respond to it and the task continues.- Rework is normal. If the reviewer finds issues, the task goes back to the developer before you ever see it.
Next
Review and merge the result — what arrives, and what to check.