01Bring an issue in
On a repository you have attached, open the project's Specs page and press "Plan it" beside the issue. It syncs the issue and starts planning in the same action, and the run appears on the project's runs page, starting in "planning".
If the GitHub App is installed on that repository, opening an issue there does the syncing for you: it is already on the Specs page, ready for the same button, before you switch tabs. Crewbit also syncs every attached repository's open issues on a schedule, so one is never more than a few minutes stale even without a delivery reaching it.
If GitHub already shows the issue blocked by another one that is not done, "Plan it" is replaced by a badge naming what it is waiting on, rather than planning something that would only be redone.
02Approve the plan
Once the plan is ready, open the run. It opens directly on the decision (the plan itself, the files it touches, the approach, the steps, the tests it commits to) with "Approve" and "Reject" beside it. Nothing about the decision needs scrolling to reach.
Approving moves the run to writing code. Rejecting, with or without a question attached, sends it back to be planned again. No code is written without this approval, on any run, ever.
03From code to a pull request
After approval the run advances on its own: it writes the code, opens a pull request, and evaluates the change against the plan's own acceptance criteria, dispatching each stage to whichever connected runner has a free slot.
If the evaluation passes, the pull request is marked ready for your review. If it does not, the run goes back to writing code for another attempt, up to a limit: past that limit it stops and waits for a person, rather than retrying forever.
04End it early, if you need to
Any run that has not already finished shows an "End run" button. If nothing is running yet (waiting on your approval, say), ending it closes the run immediately.
If a stage is running, ending it records the request rather than stopping it on the spot: the runner picks it up on its next check-in and stops there, instead of losing whatever it was in the middle of.
05Do it all from the command line
The same token the runner connects with reads and acts, without opening a browser.
crewbit project list shows the projects this credential's org owns, and
crewbit project view <id> shows one, its sources and what each is
bound to.
crewbit spec list --project <id> shows the issues a project's sources
are offering, and crewbit spec plan <ref> (the pair spec
list prints, as acme/api#12) starts planning one, answering with
the run it started or a refusal in the server's own words.
crewbit run view <id> reads that run back: its state, how long it has
been there, its history, and how many events its Jobs reported. Events are counted but
not fetched by default; --events <n> asks for that many, and
--output json prints the server's own response instead.