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 on a clock 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 on the board 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 Three things run on your machine and stop the push: a refusal of any push from a session that is not the integrating one, the personal-data scan, and a type check for the phone app or the web app when either changed. Everything else runs right after, on an independent server: the test suites, the web build, the design rules, the check for drift between the logic web and the phone share, and the facts these pages cite.

Mondays The board report checks the board's own hygiene. A problem becomes one standing issue that collects a comment each red week and closes on the first clean one.

Mondays The copy sweep comes due. Words added or changed since the last sweep get reviewed against your writing rules, in the product and in these pages.

Thursdays The parity sweep comes due. Mobile gets checked against web in the areas of the product that changed, and catch-up work gets filed.

Weekly Dependency updates for the phone app and for the build machinery arrive as pull requests on GitHub, and get folded in during the board's regular review.

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 due sweep is an ordinary board issue. Worked, it closes. Ignored, it stays open in plain view and collects a comment for every week it slips.

The Development page shows a clock for every repository this instance is set to watch, so a deployment that also watches websites or an older app lists those checks alongside these: the sites' health, drift and backups, and the older app's test and browser runs.

The boardYou watch all of it from one place

The clocks that can slip quietly report to the board: a red board report and each due sweep put an issue there, and the assignee tells you its state. The push checks fail in two places instead — the few on your Claude's own machine stop the push while it is happening, and the rest come back from the server about two minutes later, in a run your Claude watches and then fixes or reverts. The release suites run in front of the session that starts them, and dependency updates wait as pull requests. How to read the board is on the GitHub issue process page.

The live version of the board is the app's Development page, reached from Settings, in the same three lanes — Building now, Waiting on you, Queued. Under the board, The clocks gives each check a row with its cadence, its last run and that run's result. The page lists only the checks that leave a run behind them, so three of the clocks above have no row there: the weekly dependency updates, the guide review round, and the suites that run before a release.

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