Work reaches Coroid from people in the portal, in Slack or in Telegram, from your own systems and assistants, and from Coroid's own automation. New Work, where a person describes work in the portal, is one of these routes. All of them converge 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 |
| Slack or Telegram | Someone asks for it in a chat |
| Work intake API | Another system files the request, such as a feature-request form in your product |
| Event automations | Something in GitHub, Slack, Telegram or Jira should become work |
| Coroid MCP | An assistant or agent such as Hermes, Codex or Claude Code manages the work |
| Schedules | The trigger is time |
| Hooks | The trigger is a platform event |
| Reports and findings | A report or a quality check found a problem to fix |
Requests
New Work
Someone describes it
Import issues
From a tracker
Intake via API
Your product or an agent
Event automations
A pull request, comment or message
Qualification
Screens, deduplicates and verifies the request, then settles the route. Nothing is created until it passes.
Becomes
- Task
- Plan
- Report
- Schedule
Pick one, or leave Create as on Automatic and let Qualification choose.
Tasks and plans: specification, plan, build, verify, review, pull request
Checked, then routed
A request from New Work or an import is not created as soon as it arrives. It first goes through Qualification. Coroid screens it for sensitive values, checks it against the current release, looks for duplicates, verifies what it can and settles what it should become. Nothing is created until it passes. See Describing what you need.
Requests from the work intake API go through it too, and so do events that an event automation sends to Qualification.
What it becomes is one of four routes:
| Route | Produces |
|---|---|
| Task | A single task, ending in one pull request |
| Plan | A phased plan you approve before code is written |
| Report | A generated report |
| Automation | Work that runs on a schedule, or when something happens |
On the New Work form you can pick the route yourself, or leave it on Automatic and let Qualification choose. When you pick one and Qualification recommends another, you see the recommendation and decide.
Ask Coroid works differently. In its Assistant mode, the chat assistant creates tasks and plans directly, without Qualification. A Prepare Work chat, the guided SDLC workflow, sends its approved specification to Qualification before planning starts. See Chat assistant.
The other routes create work directly, without Qualification, and their own settings decide what may start. For the MCP server, those are its approvals and automation policies.
When the work starts
Nobody waits in the portal for a request from the work intake API or an event automation. Coroid creates its work within a few minutes of Qualification passing it. Whether a task also starts on its own depends on where the request came from:
| Source | Starts on its own |
|---|---|
| A service account set to start qualified work automatically | Yes |
| A GitHub pull request or issue whose author has write access to the repository | Yes |
| A GitHub comment that mentions Coroid, which counts only from writers | Yes |
| Any other service account | No |
| Slack, Telegram, Jira and any other source | No |
A task that does not start on its own waits for someone to start it. Qualification shows the request as waiting for someone to start it, with a link to the task. Plans never start on their own: they wait for approval, as always. A schedule waits in review for a person to decide when it runs.
Coroid creates the work as the first active member in this list: the person who filed the request or set up the automation, the creator of the service account, the creator of the project, and an owner of the organization.
A request that names no project goes to the organization's only project. If there are several, the request waits for review in Qualification, and the reviewer chooses the project when accepting it.
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 go through the same Qualification. Duplicates, already-fixed issues and requests that cannot be verified are stopped there, and the rest become tasks or plans. A backlog is a wish list, so this filter matters more for imports than anywhere else. See Importing work.
From your own systems
Another system can file requests through the work intake API: a feature-request form in your own product, for example, or a support tool that passes on what customers ask for.
The API needs a service account, which is included with the Professional and
Enterprise plans. Create one under Settings → Service accounts. Its API key
needs this scope: intake:write. The key is shown once, when you create it,
and disabling the service account rejects all of its keys.
Send each request to the API gateway, with the key as a bearer token:
curl -X POST https://api.coroid.ai/api/v1/organizations/work/intake \
-H "Authorization: Bearer ak_…" \
-H "Content-Type: application/json" \
-d '{"title": "Export invoices as CSV", "content": "Customers want to download their invoices as CSV from the billing page."}'| Field | Required | Description |
|---|---|---|
title | Yes | A short name, up to 500 characters |
content | Yes | The request itself, up to 20,000 characters |
projectId | No | The project the work belongs to |
workType | No | task, plan, report or schedule |
signal | No | The error, alert or issue the request comes from, described below |
Without a work type, Qualification chooses the route. Qualification runs on every API request and cannot be skipped.
When the request comes from monitoring or another automated source, describe its signal. Coroid uses it to recognize the same incident filed twice, in any project, and to draft the task's outcome contract.
signal field | Required | Description |
|---|---|---|
fingerprint | Yes | A stable identity for the incident, such as the issue id in your error tracker |
source | No | Where the signal comes from, for example glitchtip or sentry |
routes | No | The routes the incident affects, up to 50 |
minExposure | No | How many requests on those routes must be served before the outcome is judged |
url | No | A link to the incident |
With routes and minExposure, the contract is measurable: the incident must go
silent. Without them, the contract records that it cannot be measured. A
mandate can refuse to start unmeasurable work.
A qualified task from a service account waits for someone to start it. An owner or admin can change that for the account under Service accounts with this setting: Start qualified work automatically. Turn it on only when everything the account submits comes from people you trust. See When the work starts.
Events in GitHub, Slack, Telegram and Jira can become requests too, without anyone retyping them. An event automation sends them to Qualification. See Triggers and destinations.
From your assistants
An assistant or agent you run, such as Hermes, Codex or Claude Code, can work with Coroid through its MCP server. It can read your projects and work, and create, run and deliver work, within the scopes you grant it. Work it creates does not go through Qualification. See Coroid as an MCP server.
Automated entry
Schedules and hooks open work without a person asking, differing only in trigger: time, or something happening. Both are automations, listed in the factory and created in New Work.
Quality checks lead to fix work as well. When a Quality policy checks a report and finds problems in the product, Coroid opens a remediation task for them. Factory → Review lists test failures that no task owns. Fix turns one into a fix task.
All of these 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.