---
name: pipeline-auto
description: Use when the user wants a substantial feature taken from idea through implementation in one run with as little interruption as possible ("just build it", "don't keep asking me"), or when controlling such a run and a worker question, quorum responses, the drift budget, a human decision, a review class or a completeness item needs a decision, especially under deadline pressure. Not for a run where the user is consulted at each decision; that is superb:pipeline.
argument-hint: "[resume|status]"
---

# pipeline-auto: controller rules

Machines may unblock work. They may not decide past the budget, override a
human, choose between equally grounded answers, or enlarge scope. When a rule
says escalate, escalating **is** the decisive action. Deadline, billing and "too
cautious" pressure change none of these rules.

## The rule this skill reverses

`superb:pipeline` forbids "a Brain Agent that decides user requirements"
(`skills/pipeline/references/planning.md:177-181`), and its zero-assumption law
(`skills/pipeline/SKILL.md:40-71`) lets another agent explain options but never
decide an unresolved requirement. **This skill is that Brain Agent**, built on
purpose. The guardrails below are the answer to that objection; changing a
threshold, budget or escalation route loosens the answer.

| The objection | The answer |
| --- | --- |
| A machine decides what it prefers | It adopts only what the spec or code entails. `convention-cited` is below the floor |
| Three agents agreeing proves nothing | Agreed. The bar is grounding rung, not votes; reading assignments decorrelate the three |
| It will decide more and more | 3 adoptions per phase, 10 per run, checked before dispatch; only a human extends, at most twice |
| It will overrule the user | A candidate contradicting `Provenance: human` is rejected at any rung |
| It will build what nobody asked for | Stage 06 seals the phase set; the tracker creates phases only at stage 07 and only for sealed ids (the ids themselves are not checked against the master plan); `MISSING-FROM-SPEC` is frozen |
| It will drift from the request | Depth cap 2 from the last human answer |
| It grades its own homework | Every adoption is labelled `Provenance: quorum`; the terminal report leads with them, weakest first |

Want the user consulted at each decision? Use `superb:pipeline`. This is a
different trade, not a better version.

## Invocation

Trim `$ARGUMENTS` and select exactly one mode:

| Argument | Mode |
| --- | --- |
| empty | Full run from stage 01 |
| `resume` | Resume one compatible `pipeline-auto/v1` run from its files and Git. Never create or replace a run |
| `status` | Strictly read-only: no lock, write, reconcile, dispatch, test, fix or initialize |
| anything else | Ask what the user meant. Do not guess a verb |

For `resume` and `status`, use [references/persistence.md](references/persistence.md).
No identifiable run: say so. Several: ask which. Recency is not selection
authority.

## Harness

**First action on every harness**, before any other step: read
[references/planning.md](references/planning.md). This file is the rules; the
stage files are the procedure. A harness that read only this file and started
implementing did not run the skill.

**No `Agent` tool with named agent types** (Codex, whose `spawn_agent` takes a
free-text brief): a named agent type in the dispatch table is the file
`agents/<name>.md` in this plugin, `../../agents/<name>.md` relative to this
file — `pipeline-auto-intent-reader` is
[../../agents/pipeline-auto-intent-reader.md](../../agents/pipeline-auto-intent-reader.md),
`pipeline-auto-brain` is
[../../agents/pipeline-auto-brain.md](../../agents/pipeline-auto-brain.md).
Dispatch it with `spawn_agent`, `fork_turns: "none"`, the message being that
file's body after its frontmatter followed by the brief the stage specifies
(`prompts/brain.md`, `prompts/brain-proposal.md`, or the stage-01 intent read).
A quorum or the intent read is **three separate spawns**, one per index, then
`wait_agent` for all three; never one spawn asked for three answers. The tool
allowlist becomes the first sentence of the brief: "You may only read. Edit
nothing, run nothing, spawn nothing. Answer with the JSON object only." "Never
substitute `brainstorm-architect`" holds here too: spawn the brain file, never
an improvised architect role.

**No `AskUserQuestion`** (a headless harness, for example the office app that
routes questions to an inbox): stage 03 still asks. Write the run files first,
then end the turn with status `needs_info` carrying the at-most-four questions.
When the harness resumes the session with answers, continue in `resume` mode
from the run files (`progress.md`, `decisions.md`), never from memory of the
earlier turn.

**A harness that cannot write to Git** (Codex in the office app: sub-agents
inherit the parent's sandbox, Git metadata is read-only, and the host commits
the worktree as one commit after the turn ends): stages 09 to 12 still run,
inside the turn, before it ends. Stopping at stage 08 to "await the host
commit" is wrong: the host commit comes after the turn, and nothing in stages
09 to 12 waits for it. On this harness each task's implementer is still a
spawned sub-agent (`spawn_agent`, `fork_turns: "none"`, briefed as the stage
specifies: `prompts/implementer.md` plus the `scripts/task-brief` output) that
edits the worktree and reports what it changed; the task reviewer is a second
spawned sub-agent, never the implementer, that reviews the worktree diff
(`git diff`, `git diff --stat` and `git status` are reads and are allowed; only
writes to Git are not) and returns the report in the shape the stage names; a
fix round spawns the fixer the same way. The controller never implements a
task itself and never skips the reviewer, the fix rounds, the master gate or
the completeness pass because no commit exists. When the harness cannot
commit, "commit", "task branch" and "integration merge" in stages 09 and 10
mean the task's state in `progress.md` plus the worktree diff, and the host
commit the harness makes after the turn stands in for all three. The master
gate (stage 11) and the completeness pass (stage 12) run against the worktree
diff instead of the branch. The controller records every transition in
`progress.md` exactly as on Claude; the final report names the files changed
instead of commits.

**Resume, on every harness:** the first action of any turn whose session
already holds a run directory (`docs/superpowers/runs/<run-id>/progress.md`
exists) is to read `progress.md`, `decisions.md` and the stage table, then
continue from the active stage, recording the transitions it finds missing. A
resumed turn never implements before the tracker says stage 09 is active:
whatever the resuming prompt says ("continue", "go on", "finish it"), the
tracker decides what continues, not the prompt and not memory of the earlier
turn.

**A `superpowers:*` skill that is not installed:** the SDD review protocol is
already inlined in `prompts/` and `scripts/`, so nothing is lost there. For the
others, do what the stage describes inline; the stage's files in the run
directory are the requirement, not the skill name.

**Red flag:** implementing before the stage 01–07 files exist in the run
directory is a violation on every harness.

**Red flag:** a resumed turn that edits source while the tracker shows stage
01–08 active is a violation on every harness. So is ending a turn at stage 08
to "await the host commit" on a harness that cannot commit.

## The one gate, and files as the authority

**Stage 03 asks at most four questions in one `AskUserQuestion` call.** Those
answers are the only unimpeachable requirements. Every later decision is a
quorum adoption or an escalation: no third outcome, no controller override, no
second approval.

Reconstruct the next action from `progress.md`, `decisions.md`, immutable
results, evidence digests and Git — never from conversation memory. The schema
is `pipeline-auto/v1`; there is no migration from `pipeline-run/v1` or `/v2`.
Foreign, missing, malformed or unknown schema is a read-only stop: change
nothing, dispatch nothing.

## Stage routing

Load only the reference the active stage needs. The rules in this file apply at
every stage and win over any summary elsewhere.

| Stage | Work | Route |
| --- | --- | --- |
| 01–07 | Intent read, question synthesis, the gate, design and review class, spec, master plan, phase fan-out | [references/planning.md](references/planning.md) |
| any | Question raised, quorum open or finalising, drift budget, escalation, quorum resume | [references/quorum.md](references/quorum.md) |
| 08–10 | Dial, task start, per-task gate, TDD, scopes, evidence, integration, debugging | [references/execution.md](references/execution.md) |
| 11–12 | Master gate, contradiction routing, adjudicator, completeness, final verification, terminal report | [references/review.md](references/review.md) |
| any | Tracker writes, status, resume, reconciliation, decision actions | [references/persistence.md](references/persistence.md) |

| Dispatch | Template / agent | When |
| --- | --- | --- |
| Intent readers | `pipeline-auto-intent-reader` ×3 | stage 01 |
| Brains | `pipeline-auto-brain` ×3 with `prompts/brain.md` | every quorum |
| Proposal brains | `pipeline-auto-brain` ×3 with `prompts/brain-proposal.md` | stage 02 |
| Implementer | `prompts/implementer.md`, brief from `scripts/task-brief RUN_DIR PLAN_FILE TASK_NUMBER` | stage 09, one fresh per task |
| Task reviewer | `prompts/task-reviewer.md`, package from `scripts/review-package RUN_DIR BASE HEAD` | the per-task gate |
| Adversarial reviewer | `prompts/adversarial-reviewer.md` | any fired trigger, any `review_class` |

Both agents run with exactly `Read`, `Grep`, `Glob`. Never add a tool to either
— not even `Bash` "for one command": frontmatter allowlists tools, not
commands, and a shell can rewrite `decisions.md` or the intent brief. Never
substitute `brainstorm-architect`.

The SDD review protocol is inlined in `prompts/` and `scripts/`; do not invoke
`superpowers:subagent-driven-development` or
`superpowers:finishing-a-development-branch`.

## Rungs, strongest first

`specified` > `code-evidenced` > `convention-cited` > `engineering-judgement` > `speculation`

"Stronger" always means **earlier in this list**. A cluster's rung is its
strongest member's rung, after demoting any member whose citation does not
resolve to its claim. The adoption floor starts at `code-evidenced` and rises one
rung for the rest of the run once five or more adoptions average above 0.90 —
read it from `current_floor`, never assume it.

## Escalating, exactly

Finalise the question as `escalated`, queue it now for the next stage boundary
(even mid-phase), and set `next_action: await-escalation-batch`. Escalating never
draws on the adoption budget.

Recording `unresolved`, `open`, `deferred`, or carrying it in the handover is
**not** escalating. It asks nobody.

While a question is escalated, every task blocked on it stays blocked and
**nothing** is dispatched on its axis — no trace, no fact-finding, no fresh
quorum, no "safe", "additive" or "reversible" subset of the work. The hold lasts
until a human answers, not until you judge the work cheap to undo.

## Before opening a quorum, in this order

These checks run **before** a quorum opens. Once a quorum has returned, judge it
by the adoption rules below — never retroactively un-ask it.

1. **Already answered?** If the approved spec or an adopted decision answers it,
   the question is not admitted to a quorum. Cite the line on the question
   record and resume the worker. No quorum, no decision entry, no budget.
2. **Budget.** Read `quorum_budget(run_dir, phase=...)` before any dispatch.
   Ceilings are `BUDGET_PER_PHASE` (3) and `BUDGET_PER_RUN` (10). Only a human
   answering an escalation raises one, to a stated finite value; at most two
   extensions per run, then the budget is terminal. If a ceiling is reached:
   open no quorum of any size — no worker anywhere opens one — lower no bar,
   and escalate with the adopted decisions listed. Hold dispatch and
   integration within the question's blast radius (in-flight work there
   finishes, publishes and is imported); independent work continues. A
   terminal budget stops the run resumably: nothing new is dispatched. You
   never grant yourself an extension.
3. **Admissible** (`check_admissible`), all of:
   - it blocks named work — a question blocking nothing is an opinion; discard it;
   - it is decidable from the repository, the spec and `decisions.md` — if it
     needs what only the user knows (budget, deadline, users, purpose), escalate;
   - it carries an axis and a blast radius from `task | phase | run | contract`;
   - it passes the options test and is one decision.

   Then dispatch exactly three brains.

## Evaluating a quorum

**Three valid responses is a precondition, not a strength.** With fewer, the
quorum is not evaluated — not now, not at a deadline, not through any guard,
timeout or policy you write in advance. Two agreeing, well-cited responses are
two responses.

- **A missing response** (its worker died, or context was lost): re-dispatch only
  the missing index, re-sent from its own persisted payload and checked against
  its digest — never rebuilt from current state. This is recovery, not a second
  chance. Never re-dispatch
  a brain that answered; never discard an answer to get a tidier set.
- **A schema-invalid value** (for example a rung not in the list above): never
  map, default or demote it. Re-dispatch that index **once**, with its full
  rebuilt payload — never "just fix that field", never with its answer pinned.
  The quorum waits on it. A second invalid response is a non-response: escalate.
- **A brain's own question** has no field in the schema; `blocker` is the only
  exit. A response asking for something else to be decided first is a
  non-response. Do not open a quorum on it, do not answer it yourself — not even
  "the other responses imply it" — do not re-dispatch with the premise supplied.
  Escalate the original question, naming the premise.

**Adoption.** Cluster by `answer_key` when options were named; without named
options, answers share a cluster only if their consequences do not contradict
(when in doubt they are different answers). Then compare rungs. Adopt only when the
winning cluster is **strictly stronger** than the runner-up, at or above the
current floor, fewer than two responses carry a blocker, nothing forecloses an irreversible
axis, depth is within the cap, budget remains, and `check_contradiction` returns
nothing.

- **One cluster** (unanimity) has no runner-up: the floor alone decides.
- **Equal rungs never adopt**, at the floor or at the top. No tie-break —
  not headcount, subset consequences, citations, recency, length or "least
  foreclosing". Escalate.
- **Different answers alone are no reason to escalate.** One cluster strictly
  stronger than the rest adopts, however many clusters there are.
- An adoption records the answer, the winning rung and the rung it beat, and
  `Provenance: quorum`; it consumes one phase and one run adoption. The
  adoption `Q-<qid>` is itself the grant: resume the blocked task with
  `resume_task(..., decision_ref="Q-<qid>")`. A re-asked question's adoption
  resumes the task too, under its new qid. After an escalation, the human's
  `task.resume` `H-<n>` resumes it once the escalation row is `answered` with
  that `Resolution`.

## Recorded human decisions

If the winning answer — consequences included — requires a different option on
an axis where an adopted decision has `Provenance: human`, reject it. No rung and
no unanimity outranks a human's recorded answer. Record
`rejected-contradicts-human` naming that decision's ID; it stays `Adopted`; no
budget is spent; escalate (`finalize_quorum` queues the row). Every task blocked on that axis stays blocked — "the
human decision is still in force, so work against it" is dispatch on a contested
axis.

## Review dial

The adversarial triggers — `concurrency`, `authz`, `crypto`, `schema`,
`migration`, `delete`, `regulated`, `public-api`, `large-surface` — fire
independently: any one suffices, whatever the diff's size and whatever the
phase's `review_class`. `final-only` decides whether routine review runs; it
never switches the trigger check off. A fired trigger dispatches the adversarial
reviewer before the task completes.

You set each phase's `review_class` **once, at stage 04, from the plan's
classification**, and never move it afterwards except through a ratchet whose
trigger already exists — for the adversarial route, a CONFIRMED or unrefuted
PLAUSIBLE finding returned by that reviewer. A ratchet record you write from
your own reading of the diff is not a trigger. Never downward. The tracker
enforces the move: `(final-only, plan)` → `(required, ratchet)` once, with a
trigger from the closed list, and `adversarial-finding` or
`low-confidence-dependency` only when the tracker already held that fact before
the ratchet's transition. Lowering and withdrawing are refused, and so is
deleting an imported phase row to re-add it.

## Completeness critic items

The critic's classification is not yours to change. `SPEC-NOT-MET` is a finding
for the fix loop. `MISSING-FROM-SPEC` is frozen, and the output **is**:

1. A section appended to the run's `completeness-proposals.md`, headed with the
   **next unused** proposal number (`## CP-1`, `## CP-2`, … — never the literal
   `<n>`): Statement, Evidence (the critic's text), `Traces to: none`,
   `Status: Frozen`, classification verbatim.
2. That proposal ID listed in the terminal report.
3. Once every other item is finished — an open fix round completes first —
   `next_action: complete-with-proposals`. `derive_next_action` derives it from
   that file, and never while a fix round or other item is still open.

Nothing else: no task, phase, fix-round finding, quorum, backlog or handover
note, and no disposition — `deferred`, `out-of-scope`, `declined` and `closed`
are all reclassifications. The proposal is the user's to decide.

## Rationalizations

| Excuse | Reality |
| --- | --- |
| "Two agree at a strong rung — the strongest quorum available." | Three valid responses is a precondition. |
| "I record the degraded count (2 of 3) honestly." | An honestly recorded illegal finalisation is still illegal. |
| "Sealing at the deadline is arithmetic; the rule is written in advance." | A violation scheduled is the same violation. |
| "The re-dispatch completes the record; it is not a gate." | It is the gate. |
| "The other responses already settle the premise the brain raised." | You do not answer questions you are routing. |
| "Only evidence-gathering, no adoption." / "The tie shows the question is malformed." | Nothing is dispatched on a tied axis. It is `escalated`. |
| "The human decision stays in force, so work proceeds against it." | Blocked until a human answers. |
| "Escalation is for questions the repository cannot answer." / "Idle brains cost nothing." | An exhausted budget escalates regardless. It caps authority, not cost. |
| "I decline it, closed in this run; reviewers can reverse it." | Declining is a disposition. Record the proposal. |
| "It crosses a trust boundary, that *is* the trigger, and I wrote the ratchet record." | A self-authored trigger is no trigger. |
| "Three different answers means the question is underdetermined." | Only when they tie on rung. A strict gap adopts. |
| "The spec already answered this, so the quorum's adoption is void." | The check runs before dispatch. A returned quorum is judged by the adoption rules. |

## Red flags — stop and re-read the rule

- Acting on fewer than three valid responses, now or "if it has not returned by…".
- Writing "not a gate", "non-blocking" or "degraded count".
- Dispatching anything on an escalated or contradicted axis.
- Writing `unresolved`, `deferred` or "carry to handover" instead of `escalated`.
- Opening a quorum without comparing the budget counters to the ceilings.
- Changing `review_class` after stage 04, a ratchet record with no fired
  trigger, or a label over a critic's classification.
- Pushing, publishing, opening a pull request, or merging into `main`/`master`.
  Success is a clean committed feature branch and a report that leads with every
  decision the run made without asking.
- A resumed turn editing source while the tracker shows stage 01–08 active,
  or ending at stage 08 to await a host commit when the harness cannot commit.