Three projects, one workflow

01Three projects, three different jobs

Think about how a crew works. There is a process that knows what order the work happens in, there is the craft knowledge of how things are built in this particular shop, and there are the actual tools and eyes on the job. These three repositories are exactly those three things.

Why they are separate

They change at different rates, and each is useful on its own. The process can stay still for months. A stack's conventions change whenever that stack evolves. The toolkit grows when a new device capability appears. If they were one repository, every small convention change would force a release of the whole pipeline. The toolkit in particular stands alone: it gives any AI editor control of a simulator, whether or not the pipeline is involved.

02The big picture

The three repositories at the top. The three command-line tools that run them in the middle. At the bottom, the systems a run talks to and the durable trace it leaves behind.

03What happens when you run one command

Eight phases in order. Two of the arrows go backwards and one is a shortcut the fast modes take. Those three arrows are the reason this is worth drawing rather than listing.

04The pipeline: modes, gates, review

There are not nine unrelated modes to memorise. There are three independent switches, and the nine names are just the useful combinations of them.

Two of those switches are commands; the third is not. Worktree and questions are chosen by which entry you type. Depth is asked once, at Phase 0 Step 7.5, and recommended from the task type - which is why there is no fast-and-unattended entry: autopilot may not ask, and an unwatched run is the worst place to drop analysis and planning. And ship is the odd one out: it skips the writing entirely and runs the tail of the pipeline over work you already did by hand.

Nine entry points over the same eight phases

You choose how much ceremony a task gets. The full pipeline asks about everything. Autopilot resolves the defaults itself. The fast modes skip analysis and planning, go straight to building, and use a stronger model while doing it.

What stops a run, and what only warns

A check that cannot fail is worse than no check, because the green tick gets read as coverage. So every gate declares which side of the line it is on, and several deliberately stay closed when the evidence is missing.

Review: three stages, and one honest asymmetry

Eight specialists, three model vocabularies

Each specialist is defined once and states a tier, not a model name. Every CLI maps that tier onto a model it can actually reach, so one definition works in three places.

05The plugins: craft knowledge per stack

How you build a screen in an iOS project has nothing to do with how you add an endpoint in a backend. The pipeline does not carry those answers inside itself. It asks that stack's plugin.

Every plugin has the same skeleton

06The toolkit: hands and eyes for the AI

A model being able to read code does not mean it knows whether what it wrote works. This server closes that gap: it can launch the app, tap it, take a screenshot, run a build, and audit the package before submission. All 84 tools over a standard MCP connection.

The server runs independently of the pipeline. It connects to any MCP client, because it is a plain stdio MCP server. Some pipeline skills declare a minimum version, so when the server moves it has to ship: the sync step has its own gates, from a syntax check to package completeness to the advertised tool count matching the real one.

07Three CLIs, one pipeline

The same tree installs into three places, in three different shapes, because the three hosts disagree about how skills are discovered and how much of a prompt survives.

Why Codex gets exactly one skill

Codex collects the name and description of every skill it finds into one block, and silently drops the overflow. It does not warn. This was measured, not assumed.

08Three operating systems

The same scripts have to run on macOS, Linux and Windows. That is a contract, not an aspiration: at the end of every sync each shell script is syntax-checked and scanned for patterns that are not portable.

Six rules that keep it portable

• Paths are always quoted and always go through the home variable. No absolute user path anywhere.
• Timestamps try the BSD form first and fall back to the GNU form.
• Tree walks prune node_modules, Pods and build output identically everywhere.
• Text tools are invoked in POSIX form. No GNU-only flags.
• Secrets only ever go through one layer. Nothing calls the platform tool directly.
• Verification parses every shell script after a sync. Any output at all means a portability regression.

09Talking to the outside

A task rarely arrives self-contained. Six typed fetchers pull in the surrounding evidence, and six channels write the result where people are already looking. Neither has an address or a secret hard-coded: addresses come from preferences and secrets from a keychain mapping.

10How it keeps itself honest

Most of what follows exists because the opposite behaviour shipped once and cost something.

On top of those sit 137 smoke suites, a separate parity gate per host, an install fingerprint that catches structural drift, and a registry where a command name may only disappear through a recorded rename.