Owner's guide

The development workflow

When you ask for something, your Claude answers with one line that says what it will do and when you will hear back. Every check that stays out of your ask runs at the push or on its own cadence instead. This page is that contract and the full schedule.

DispatchEvery ask gets one line back before the work starts

You say what you want in plain words. Before the work starts, your Claude answers with one line: what it understood, which lane the work takes, and its stopping rule. The line arrives in the chat where you asked, and the same line goes on the issue that tracks the work. You correct the line in a word, and the work follows the correction.

Build now It builds immediately and reports when the change is live. The lane for "this is urgent" and "real quick."
Queued It files the issue, and the work gets built the next time you have your Claude work the queue. The lane for "we should" and "put it in the queue."
Filed only It records the idea in the queue and builds nothing yet. The lane for "file this" and "capture this."

The stopping rule says when you hear from it next.

One pass One working iteration, then a check-in with what changed. The default while you are iterating on something together.
Run to done It keeps going until nothing is left that it can do without you. The default for "complete all work you can."

When your words leave the lane open, the line states its best guess and the work proceeds. A guess costs you one word to correct. A question costs you the whole exchange.

ScopeThe same line says what is in and what waits

The line also splits the scope, once, at the top. It says which surfaces are in: web can go first with mobile filed as a follow-up, or both can go together. It says whether words are involved: a change can have none, touch only interface labels, or include real copy, and real copy gets its own writing pass after the build. And it says how much testing runs before you see the change: quick checks run on every ship, and the full suites run before a release.

Mid-build, scope holds. Anything discovered along the way is filed as its own issue instead of growing the ask.

ClocksChecks that stay out of your ask run on their own schedule

A check that ran inside every ask made simple asks slow. Each one now has its own clock, and the table below says where each result turns up.

Every push Every check runs on your Claude's machine before the push leaves, and any failure stops the push. The hook refuses a push from a session that is not the integrating one, then runs one list of checks over what the change touched: the personal-data scan, the type checks, lint and test suites of the apps in the change, the design rules, the check for drift between the logic web and the phone share, and the facts these pages cite. What the hook passes is what ships, since GitHub's own check runner is switched off for good.
When asked The board report checks the board's own hygiene. It runs when you or your Claude starts it, and nothing runs it on a schedule.
When asked The copy sweep reviews words added or changed since the last sweep against your writing rules, in the product and in these pages.
When asked The parity sweep checks mobile against web in the areas of the product that changed, and files the catch-up work.
At a release Dependency updates get read and folded in deliberately when a release is cut, rather than arriving as pull requests on GitHub.
Every two weeks A guide review round comes due, so these pages keep describing the product that exists. This one puts nothing on the board. Your Claude is told it is overdue at the start of the next session.
Before a release The full end-to-end suites run on iPhone and Android before anything ships.

A sweep waits for someone to start it. The copy and parity sweeps used to arrive every week as issues from GitHub's check runner, which is off for good, and no job on your Claude's machine replaces them. You ask for one or your Claude starts one, and it is worked as an ordinary issue.

None of these checks leaves a record the app can read, so the Development page draws no row for them. It shows what is running instead: the commit each part of the app last deployed.

The boardEvery check reports somewhere you can see it

A sweep reports as an issue, and the status on it tells you where it stands. The push checks fail in one place instead, on your Claude's own machine, where a failure stops the push before anything leaves. The release suites run in front of the session that starts them. How to read the queue is on The work-loop page.

A sweep that runs is filed as an issue on GitHub, beside the rest of the queue. The app's Development page reads GitHub too, and sorts open issues into three lanes by their labels. An issue labelled status:in-progress is under Building now. One assigned to you, or labelled status:waiting-on-you, is under Waiting on you, even while it is also being built. Everything else is under Queued.

Under those lanes, Last deploy has a row for the backend and a row for the web. Each row shows the commit that part is serving and how long ago it went up, read from the marker the deploy script writes into every upload. The commit links to its change on GitHub. A row that says Not marked is serving a build the deploy script did not make, and one that says Unreadable could not be asked. These rows read the running app, not GitHub, so they show even when the board cannot be read. A line under them says where the push checks run, since they record nothing the page can show.

When a lane or a clock changes, this page changes in the same commit.