Three projects, one workflow

multi-agent-pipeline

The process

The part that knows the order and refuses to skip steps. It drives a ticket all the way to a merged pull request: analyse, plan, build, review, commit, report. It knows what needs your approval, what is a hard stop, and where to loop back and try again.

multi-agent-plugins

The craft knowledge

The answer to how we build things here, one answer per stack: iOS, Android, frontend, backend and shared. Folder shape, naming, which layer may know what, how tests are written. The pipeline consults this knowledge while it builds instead of carrying it inside itself.

multi-agent-toolkit-mcp

The hands and eyes

The server that lets the AI actually launch the app, tap a button, take a screenshot, run a build and audit a package. Without it the AI can only read code. With it, it can look at the result of its own work.

local

Your checkout, or a separate one

This is a question too, asked at Phase 0 Step 5b. A separate checkout of the same repository leaves your own working copy untouched and lets two tasks run side by side. Local works in the checkout you are sitting in, which is simpler when you want to watch it happen, and costs the user-test phase - that gate checks the change out of a separate checkout, and there is none. The local entries answer it up front; autopilot resolves it to a separate checkout without asking, because an unattended commit in your own copy is the thing separate checkouts exist to prevent.

base branch

Evidence, then the question

Phase 0 collects the candidate base branches with the evidence behind each one before it asks. An issue carrying a target version, or linking the issue that represents the release, already names the branch on a repo whose release branches encode the version - so that becomes a ranked row whose description says why, beside rows reading "the repository's default" or "you used this last time". Nothing is hardcoded: any issue field whose schema resolves to a version is read whatever the board calls it, and the branch naming convention is inferred from the branches that exist rather than read off a table. A failed fetch degrades loudly - the list falls back to local refs and the question says so, instead of presenting a weeks-old cache as the remote's answer.

maturity

Not ready is a question, not a dead end

Phase 0 scores how ready the issue is before anything is built, and until 17.6.0 it scored and stopped: a blocker ended the run, an unattended queue moved to the next item, and the issue stayed exactly as immature as it was found. It now asks. Interactively, at that step: open the issue and fix it, continue without it - and which gap you waved through is recorded, not just that you continued - or abort. Unattended, on the issue itself, if you turned that on: one comment naming what is missing, then it stops and waits. Never a status change, never an assignee, never a close. Edit the issue and the next scan re-checks it, and if the gap closed development starts on its own - an edit is a reason to look again, never proof, so the check re-runs against the new text and decides. The same question is never asked twice.

autopilot

Asks you, or decides itself

Interactively it stops for the plan, the commit and the pull request. On autopilot it resolves those to sensible defaults, writes down what it chose, works in a separate checkout without asking, and turns on the gates that check its claims. It still stops for a review blocker it cannot fix, a build that will not go green, a circuit-breaker trip and the channel choice at reporting. Under the continuous-mode runner it ends at a draft pull request that a person reviews and merges.

research

Research before asking

A run that parks on a maturity blocker or an open analysis question gets a research pass first. It reads the tracker thread, linked items and documents, similar closed items and the repository. A script closes only the gaps a quoted source or a resolving file:line backs, and the original check re-runs and decides. Whatever is still open parks the run with the candidates found.

draft PR

One outward writer

The session never pushes. Phase 4 writes a request, and the runner, outside the session, re-runs the stack's build and tests itself, re-checks the gate ledger, the secret scan and the outbound gate, pushes from a clean staging repository and opens the pull request as a draft. A check that fails leaves the item marked verification-failed with the verdict on disk.

operations

Operations around a run

A second launchd agent keeps the Mac awake while the mode is on. Every credential a configured repository needs is probed before the schedule is offered and again on every tick. A circuit breaker stops launching after attempts that produced nothing, a cost ceiling caps spend over a rolling 24 hours, a parallel-agent cap limits sessions at once, and a daily cleanup report is written.

security

A guard that fails closed

Under the unattended flag the Bash guard judges a command only when it reduces to simple commands, and refuses anything it cannot parse. On what it can parse: no push, PR, issue or tracker write, no Keychain read, no fetch outside the network allowlist, no package install. Ticket and PR text reaches the model inside untrusted-data delimiters. The boundary itself is a separate non-admin macOS user plus branch rulesets.

gates

Claims are checked, not trusted

Before a commit, a run's claims about the repository are checked: a localization key or endpoint it references exists, open analysis questions are answered or park the run, a triage citation quotes the line it cites, a pre-existing finding points at a line the diff did not touch, and a test pass shows a positive executed count plus a new test that fails without the change. Every verdict goes to a ledger, and the commit hook refuses a commit whose mandatory gates did not pass.

client

A client contract and a phone

Commands and run questions are declared as data. /multi-agent:serve starts a localhost server over the same JSON the CLI prints, with a manifest, types and fixtures a client builds against. Four phone routes read redacted runs, answer a parked question with one of its offered options, and, only when switched on, queue a launch. Every request carries a signature from an enrolled device.

index

The router

One entry point that decides which skill should answer a given request.

reference

How this stack is built

Knowledge to read, not steps to run: layers, naming, file placement, which unit may know what.

workflow

What to do, step by step

Create a screen, evolve a component, fix a bug, scaffold a new project, branch and open a PR. Imperative and ordered.

tools

Outside sources

Figma data, Code Connect mappings, component documentation, resource registries.

knowledge

Generated depth

Framework and API depth. Never hand-written here: it is generated from the pipeline, and the next build overwrites it.

No commit without a passing build

And passing means a log that shows it. A self-assertion does not count as a build.

An issue is never closed

Auto-close keywords are forbidden in commits, PR titles and bodies. Closing is a human decision.

Uncommitted work is never removed

The cleanup step has a safe skip path and never force-removes.

A design is never guessed

If a variant, spacing or string is missing, the run stops and asks for the analysis to be regenerated. Substituting something close has cost rebuild rounds.

No AI credit anywhere

Not in commits, not in PR bodies, not in code comments. The author is always the user's identity.

An empty answer is not consent

If a question is submitted blank it is asked again, never resolved to a default.

Counts are derived, not asserted

Every number describing how many commands exist is computed from the tree, and a gate requires the prose to agree.

A test that asserts nothing is rejected

The runner fails a suite that exits successfully having checked nothing. Three suites were doing exactly that.