Work reaches Coroid through several routes, all converging on the same execution path — specification, plan, build, verify, review, pull request.
| Route | Use when |
|---|---|
| New Work | Someone wants something and is here to describe it |
| Import issues | The request already exists in Jira, Linear, Trello or GitHub Issues |
| Ask Coroid | You would rather describe it conversationally |
| Schedules | The trigger is time |
| Sentinel | The trigger is a condition becoming true |
| Hooks | The trigger is a platform event |
You choose the outcome
However work arrives, you decide what it becomes. The New Work form asks for this first, and the rest of the form adapts to your answer:
| Routing | Produces |
|---|---|
| One executable task | A single task, ending in one pull request |
| Phased work plan | A phased plan you approve before code is written |
| Report | A generated report |
| Schedule | A recurring monitor |
Task or plan?
The useful test is reviewability. If the finished work is one pull request a colleague could read in one sitting, it is a task. If it needs several changes in a defined order, or you want to approve the approach before any of it is built, it is a plan.
When in doubt, prefer a plan for anything substantial. A plan gives you an approval checkpoint before code exists, which is the cheapest place to change your mind. A task that turns out to be too large simply runs out of room.
Imported work
Issues imported from a tracker do not execute on arrival — you still route them. A backlog is a wish list, and not everything on it should be built by an agent without someone deciding. See Importing work.
Automated entry
Schedules, Sentinel and hooks open work without a person asking, differing only in trigger: time, an observed condition, and a platform event.
All three consume real agent slots and real model spend. Give automated work a lower priority than work someone is waiting on — see Capacity and agent slots.