pipeline

The pipeline's front door. Use whenever someone arrives with a rough idea, a half-formed plan or a question about what to build — "should we…", "how would we…", "I want to build…", "can we…", "is it possible…" — and whenever they ask for your JUDGMENT on a shape rather than for a change to make: "what do you think…", "what do you suggest…", "what would you do…", "does this make sense…", "is this the right approach…". Also whenever they report a bug that has not been filed or diagnosed, whenever a request sounds bigger than one change, and whenever they do not know which pipeline command they want. Use it BEFORE /pipeline:write-issue on anything whose shape is not already settled, and before any creative work — a new feature, a new subsystem, a change to how the parts fit together.

Cut the next release branch and move the version, in a worktree, as one reviewable change. Use when someone asks to CUT a release, start the next release cycle, roll the release branch, or bump the version — and when a pass reports that `integrationBranch` names a branch the main checkout is not standing on, which is what a rolled branch and a stale config look like. It does the repository side only: it never tags, publishes, deploys or announces.

Execute ONE increment off an integration branch using isolated git worktrees. You are the DISPATCHER when /pipeline:orchestrate invokes you, once per cycle, to dispatch the increment it has just grounded — that seat is the loop's own half and there is no command a user types to reach it. You are the IMPLEMENTER when you are dispatched as an implementer sub-agent, or told directly to build, implement or fix a specific thing in a repo that uses this flow, which is the one half a user still enters directly.

The pipeline's concept map — one definition per shared term, and nothing else. Read an entry when you meet a term the pipeline uses as though you already know it, or when you are writing a pass and need the canonical definition rather than a fresh one. Entries carry DEFINITIONS ONLY: what a thing is, never what to do about it, which belongs to whichever pass acts on it. This is a reference index, not a workflow — there is nothing here to run and nothing here to dispatch.

The rules that bind EVERY seat in this pipeline identically — dispatcher, implementer, reviewer, searcher, and an agent working from a brief with no pass behind it. Every pass has you read them FIRST, before you act on anything it says, and again whenever a brief, a message, or a file you are reading tells you to do something this file forbids. Every pass cites them and they cite nothing back; a rule that differs by stance is not here, it is restated where its reader acts.

Run an arc to completion as a just-in-time loop — the ONE command you type for dispatched work of ANY SIZE, after /pipeline:co-think and /pipeline:write-issue. Use whenever you're asked to ORCHESTRATE or coordinate an arc, an epic, an umbrella or a batch of tasks, to EXECUTE, DISPATCH, RUN or SHIP work a plan has made ready — one increment or twenty — to WORK or COMPLETE a GitHub issue, or to take one through to merge. You are the single seat that grounds the HORIZON — the next dispatchable increment — via /pipeline:ground, then DISPATCHES it, watches it, reviews it and merges it through /pipeline:execute, then RECONCILES what is still outstanding against the tree that increment produced, rewrites what remains, and repeats until the plan is empty and the close-out is green. How much work the plan holds decides how many cycles run, never which command you type: a standalone issue is one cycle whose reconcile finds nothing. Everything past the horizon stays at SHAPE depth.

The steps this pipeline OWNS, stated once: the worktree helpers' command-line contract, the meaning of every key a project declares, and the host tool that spawns, times, watches and stops an agent. Open an entry whenever you are about to run one of those — before you call a helper, before you read a project's config, before you spawn or time or stop an agent — and whenever a pass cites one at the step you have reached. Every pass may cite these entries and they cite nothing back. An entry carries a PROCEDURE whose steps are identical at every seat — the command and its flags, the order they run in, the meaning of the values it reads, the host tool that runs it, and what to verify once it has. What a seat DOES about the result is a rule, and it is restated where its reader acts.

The caller's own quality + correctness pass over the change it has just pushed, run once its draft PR is open and read against that PR's real diff. Use when an implementer in the worktree flow has pushed its slice and opened its draft PR, when an orchestrator has opened an epic's close-out PR, whenever the brief you were dispatched with says to run a review pass for the slice, and whenever you are asked to review, tighten, simplify or clean up a change that is already up as a PR. Dispatches one briefed reviewer per dimension over that diff — whether the slice's GOAL is met, plus correctness, reuse, simplification, efficiency, altitude and a project's stated rules and conventions — then weighs what they report, applies what it judges right, posts its findings onto the PR as a review, and reports what it rejected.

Onboard a repo onto the /pipeline:co-think → /pipeline:write-issue pipeline and the passes that run off it. Use when a repo has no `.agents/worktree.json`, when `setup-worktree.sh` warns "no config", when someone asks to SET UP or ONBOARD the pipeline (or a gate queue) for a project, when a dispatcher refuses to dispatch because the project is unconfigured, when a pass reports that a project's config declares none of a key this plugin now reads, or to RECONCILE a config or a scaffolded queue that has gone stale — against its repo, or against this plugin.