New Work is where a person describes work in the portal. You describe the outcome once. Coroid checks the request before anything is created, then turns it into a task, a phased plan, a report or an automation.
Work also arrives from issue trackers, from your own systems and from automation. See Ways to start work.
Finance teams keep asking for their invoices in a spreadsheet. Add an export button to the invoice list that downloads the current filter as CSV.
Done when: the file opens in Excel and Numbers, amounts use the account currency, and exports over 10,000 rows don’t time out.
The New Work form: choose what to create, pick the project, then describe the outcome in a title and a brief.
Create as
The first row decides what the request becomes:
| Option | Produces |
|---|---|
| Automatic | Coroid chooses the route during Qualification |
| 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 |
Automatic is selected by default. Coroid reads the request while it qualifies it and picks the route that fits. Pick a route yourself when you already know the answer: Task when the work is a single change a reviewer could read in one sitting, Plan when it needs several changes in a particular order, or when you want to see the whole approach before committing to any of it.
If you choose a route and Qualification recommends a different one, the form says so before anything is created. You can accept the recommendation or edit the request.
Work that spans more than one project always becomes a plan. With a second project added, only Automatic and Plan are available.
The form adapts to the route. Reports ask for their own details further down, and tasks and plans show the specification section. An automation has its own form: choose when it runs and what it does. See Automations.
Two shortcuts sit beside the form: Import issues brings work in from a tracker, and Ask Coroid hands the same job to the chat assistant.
Projects
Choose the project this work belongs to. For Automatic and Plan you can add more projects when the work spans dependent projects. That is how cross-project work is expressed. A task runs in exactly one project.
Describe the work
Two fields, and they do different jobs.
Work title: a short name. This is what you will scan for in lists later.
Brief: the substance. Outcome, context, constraints, source material, and what Coroid should deliver. Write the outcome rather than the implementation; Coroid turns it into a testable specification and checks the finished work against those promises.
Add rate limiting to the public API.
100 requests per minute per API key. Exceeding it returns 429 with a
Retry-After header. Limits are per key, not per IP.
Internal service-to-service calls are exempt — they authenticate with
service tokens, not API keys.
Do not change the existing auth middleware's public interface.That last line is doing real work. Scope lines are the difference between a focused change and a sprawling one.
For Automatic, Task and Plan you can drop, paste or attach files under the brief: screenshots, PDFs and notes. Tasks accept images; plans also accept PDFs and text files.
Specification
Tasks and plans have a Specification section with two choices:
- From the brief: the default. Coroid writes the specification from your brief (intent, user stories and acceptance criteria), then builds and verifies the work against it.
- Write my own: your specification replaces the generated one. Fill in the intent, user stories, acceptance criteria, constraints, business value, scope and type yourself.
With Write my own, Structure with AI drafts the fields from your brief so you can edit from there. It also shows a coverage ledger of what it preserved, what it added and what it could not fit, so you can check nothing from the brief was lost.
Write your own when acceptance criteria already exist, for example in a product requirement. Otherwise, start from the brief and correct the result on the task's Specification tab. See Specification-driven development.
Advanced settings
Optional. Which fields appear depends on the route.
Use the SDLC workflow
Off by default. Turn it on to review an intent and a specification before planning begins. The final button changes to Prepare work and opens guided preparation instead of creating the work straight away.
Turn it on when the work is consequential enough that you want a checkpoint before an approach is even drafted. Leave it off for work where the brief is already unambiguous. See The SDLC workflow.
Qualify before work starts
On by default. Where your organization's policy allows it, you can switch Qualification off for a request. You then have to give a reason, and the actor, reason, time and policy are recorded permanently in the audit trail. When Qualification is bypassed, the Advanced settings heading says so.
Goal
Plans only. What the plan should achieve beyond the brief. The brief says what to build; the goal says what it is for.
AI profile
Which models run this work. See AI profiles.
QA checks
Which verification level applies. Use policy default inherits from the project's or the organization's Quality Control policy. Standard runs the current checks. Thorough adds extra-careful live checks against the brief and can reject work that Standard would accept.
The resolved policy is fixed when execution begins. Changing the policy afterwards does not retroactively change work already running. See Quality policies and gates.
Priority
P0 to P3, defaulting to P2. Priority orders the queue when more work is
waiting than there are agent slots. It does not add capacity; see
Capacity and agent slots.
Token budget
For a plan, Token budget per generated task caps how much context each generated task may consume. For a task, Maximum token budget caps the task itself; leave it empty for no limit. Raise the budget for work that needs to read widely across a large codebase; lower it to keep spend tight on routine work.
Constraints
Plans only. Plan constraints, non-goals, dependencies and delivery rules. This is where explicit non-goals belong, and it is the single most effective field for preventing scope creep.
Start from / Pull request into
Which branch the work starts from, and which branch the pull request targets. Same as start from is ticked by default, so both follow one setting.
main → new Coroid branch → PR into mainCoroid always creates the working branch. These fields only change the branching point and where the pull request lands. They cannot make Coroid commit directly to an existing branch, and the form checks that the branches exist on the remote before you continue.
Use them when you merge into something other than your default branch, such as
a develop branch or a release train.
Sprint and target release
Tasks, and Automatic requests that become tasks. Place the task in a sprint and link it to a planned release from the start, instead of assigning it afterwards.
Continue: Qualification
Nothing is created when you press Continue. Coroid first screens the request for credentials and other sensitive values, then runs Qualification:
Qualification checks
- Normalize and sanitize
- Filter prompt injection
- Check current release
- Deduplicate and cluster
- Verify or reproduce
- Assess impact and ownership
- Route work
No work exists until the checks pass.
QualifiedWork is created
A task joins the queue; a plan starts planning. With attachments, a report or a schedule, you confirm with Review and create first.
DuplicateAlready fixed
No new work. A duplicate is merged into the request that already covers it.
Not reproducibleNeeds review
Edit and retry, close it, or create it anyway with a recorded reason if you have permission.
Every submission is kept under Quality Control → Qualification.
Qualification checks the request against the current release, looks for duplicates, verifies or reproduces what it can, assesses impact, ownership, scope and difficulty, and settles the route. You can follow each check live.
What happens next depends on the verdict:
- Qualified: a task or plan without attachments or the SDLC workflow is created as soon as Qualification passes. Otherwise you return to the form with Review and create, and the final button names what it will make: Create task, Create plan, Generate report or Create automation. A new task joins the queue straight away, and a new plan starts planning.
- Duplicate or Already fixed: no new work is created. A duplicate is merged into the request that already covers it.
- Already resolved: the same issue or failure is already being handled under another request, in any project. The request is linked to that work instead.
- No change needed: the assessment found the reported behavior is intended. No work is created.
- Deferred: only for requests that arrive without a person, such as from the work intake API or monitoring. The work qualifies but has to wait for its mandate's capacity or budget. A request you make here is never deferred.
- Not reproducible, Rejected or Needs review: no work is created. Edit the request and add evidence, retry Qualification, or close it.
When you disagree with a verdict, someone with permission can Create work anyway. The override needs a reason, and the reason is recorded.
Requests that wait on a decision are listed under Factory → Review, and every submission, whatever its verdict, keeps its own page with its checks, evidence and audit trail.