File your first Issue

You dispatch work by creating a normal GitHub Issue in your connected repository and adding the ai-ready label. That label is the execution switch. Nothing else is required — no command, no form, no separate queue. When the environment is ready, quota is available and no earlier work or version scope holds it up, Orbi usually starts within a minute of the label being added; the regular pickup runs every five minutes.

​

Dispatch an Issue

Don’t want to write the Issue yourself? Click Write a request on the status page and tell Orbi what you want changed. Orbi writes a draft, and starts once you click Hand off to Orbi. See Write a request.

1. In your connected repository on GitHub, create an Issue describing one change.
2. Add the ai-ready label.

For a new bug report, add bug alongside ai-ready. Use ai-fix-needed only to resume a delivery that already has a PR, not to classify a new bug. The label already exists — preparing the work environment created it along with the rest of the ai-* set. Once Orbi picks it up, ai-in-progress appears on the Issue, the status page headline becomes Orbi is coding and shows the active Issue and its progress, and the Issue appears in Task history.

​

Dispatching from the status page

After connecting, Orbi reads the repository and suggests work it can do. Orbi suggests starting with these contains up to three suggestions per batch:

• Existing Issue: Let Orbi do this applies ai-ready and dispatches it immediately.
• New task: Review draft opens a draft already prepared for you. Ask for changes if needed, then click Hand off to Orbi to create and dispatch the Issue.

Use Why this › to expand the reason. On the first-task card, See N more suggestions expands the list and Show others at its end reads the repository again; in a project’s suggestion section the button is Get new suggestions (with several projects it names the project); with no suggestions available, use Get suggestions. Reading usually takes about 2 minutes, and you can leave the page. The other entry points remain available: Write a request, other existing Issues listed on the page, and GitHub’s new-Issue form. Existing-Issue buttons (Let Orbi do this or Try →) dispatch immediately. Create an Issue on GitHub preselects ai-ready, so submitting enters the queue directly. Issues already carrying any ai-* label are excluded from the available list. After a delivery, an idle project may also offer the small README run-note task; it is created and dispatched only when you click Try →.

​

How to write the Issue

Write it the way you would for a capable colleague who has not seen your codebase before. Orbi reads the Issue body and comments as its instructions, so what you put there is the specification. The things that consistently matter: Say what should change, and where it is if you know. “The export button on the reports page produces a CSV with no header row; it should include one” gives more to work with than “fix export”. Say how you will know it worked. An acceptance criterion is what the independent review checks against. “A downloaded CSV starts with a header row matching the column titles” is checkable; “export works properly” is not. Keep one Issue to one change. A bundled Issue produces a bundled pull request that is harder to review and more likely to need repair rounds. Name constraints explicitly. If a public API must not change, if a file is off limits, or if a specific approach is required, say so in the Issue. Orbi will not infer prohibitions. Do not ask for things the environment cannot do. A delivery runs in an isolated environment with your repository, not against your production systems. Acceptance criteria that require production credentials, real third-party accounts, or a live deployment cannot be satisfied there — and an Issue that demands them will spin until it reaches ai-blocked. If you need that kind of evidence, gather it yourself and state in the Issue that it is out of scope for the delivery.

​

Choosing what to start with

Your first Issue is worth choosing deliberately. A well-scoped small change — the starter task, a bug with a clear reproduction, a missing test, a contained refactor — finishes fast and shows you the whole loop. Save the ambiguous architectural work until you have seen how Orbi handles your codebase. Your CI determines which automated checks the merge and release gates can enforce. The independent review follows the tests and coverage requirements declared by your repository. With no CI, the absence of reported checks does not prove tests passed; the review and the remaining merge conditions still apply. A pending or failed check is not treated as a pass. See security.

​

Steering a delivery in flight

You do not have to wait for the result to correct course. While an Issue is ai-in-progress, add a comment with the new decision or edit the Issue body — the running session picks the correction up and restarts with it, usually within a minute. A delivery accepts 3 such restarts, and only comments from people with write permission in the repository can steer it. See steering a delivery.

​

Priority

Add the p0 label to have an Issue picked up ahead of others. The pickup order is p0 first, then Issues labelled bug, then everything else.

​

Other kinds of work

ai-ready dispatches development work by default. Pair it with a second label for other task types — ops and research (ai-ops-only), content (ai-content-only), or a release (ai-release). See the delivery lifecycle.

​

What happens next

Follow it on the Issue’s labels or on the status page. The sequence you are looking for is ai-in-progress → ai-pr-opened → ai-merged; a repair round shows up as ai-fix-needed in between, which is normal. When something needs you — an approval, a confirmation, missing detail, or a blocked Issue — the status page says so in the main status card, in the items that need your attention.