---
name: autonomous-pipeline
version: 0.1.1
description: |
  Run the whole engineering lifecycle end-to-end from one request — spec → plan → build → simplify → test
  → review → performance → ship — as a single autonomous pass with ONE human approval (the plan) and
  hard-gated escalation for anything irreversible. It chains the auto-* phase skills, carries a durable
  pipeline checkpoint so a stop/crash resumes at the exact phase and task it left off, watches the signal
  between phases (a phase that misses its gate is recorded blocked and surfaces in the register — fail closed, no false-green downstream), and returns a
  verified findings register at the end. It does NOT loop on its own: after one pass it reports what
  shipped and what's open, and the user decides on any fix round. This is the top-level "maximise
  autonomous agents" entry point. Composes every auto-* phase plus checkpoint-resume, budget-guard,
  watch-and-act, and adversarial-verify.
allowed-tools:
  - Skill
  - Agent
  - Workflow
  - AskUserQuestion
  - Bash
  - Read
  - Write
  - Edit
  - Grep
  - Glob
disable-model-invocation: true
user-invocable: true
effort: high
argument-hint: "<feature request to take from idea to shipped> (or 'resume' to continue a run)"
arguments:
  - request
when_to_use: |
  Use when the user wants "prompt → spec'd, planned, built, cleaned, tested, reviewed, tuned, shipped" in
  one autonomous run rather than invoking each phase by hand. Do NOT use for a single phase (invoke that
  auto-* skill directly), or for a quick one-off edit. It spawns many agents across many rounds over the
  whole lifecycle — it is explicit-user-only.
---

<EXTREMELY-IMPORTANT>
This is the most powerful and the most dangerous skill here — the full lifecycle, unattended. It inherits
every phase's guardrails and adds pipeline-level ones. Non-negotiable:
1. ONE HUMAN GATE (plan approval); irreversible/ambiguous/unfixable situations from ANY phase still STOP
   and ask. Approval authorizes the plan, not surprises.
2. ONE PASS, NO AUTONOMOUS RECURSION. The pipeline runs each phase once, returns a verified findings
   register, and STOPS. It never silently loops the whole lifecycle — an autonomous fix-loop is what turns
   a run into a multi-hour grind. A fix round is a deliberate user choice (re-invoke with the findings).
3. PHASE GATES FAIL CLOSED. A phase that doesn't reach its bar (build blocked, red validate, unverified
   review, a died agent) is recorded `blocked` — never `done` — its items go to the register and
   `converged` is false, so a resume re-enters it and no phase ever hands a FALSE-GREEN forward. The run
   is ONE forward pass: rather than hard-stop mid-run (a Workflow can't ask the user), downstream phases
   still execute over whatever integrated and collect their findings (except auto-simplify, which needs a
   stable base and is skipped when the build is incomplete). The user reads the register and decides the
   fix round. Never fabricate a phase's clean verdict to keep the pipeline moving.
4. DURABLE, RESUMABLE. A pipeline checkpoint records the current phase + each phase's state; a stop/crash
   resumes at the exact phase/task, skipping completed work — never restarting from spec.
5. BUDGET THE WHOLE RUN. Declare a pipeline-level budget/escalation contract (`budget-guard`) on top of
   each phase's. The lifecycle is long; an unbounded pipeline is a runaway.
6. HONEST END STATE. Report what actually shipped, which gates ran, and the open findings — caveated by
   which phases the user chose to skip. Never present a pipeline with a dead gate or a red end-state as
   done.
</EXTREMELY-IMPORTANT>

# Autonomous Pipeline

## Overview

One request in, shipped-quality work out — by running the eight phases as one governed pass. The pipeline
is not magic autonomy; it's *disciplined* autonomy: a single approval, fail-closed gates between phases, a
durable checkpoint, a whole-run budget, and an honest findings register at the end. It removes the human
stepping between phases, not the verification each phase enforces.

## Phase order and gates

```
 auto-spec → auto-plan →[APPROVAL]→ auto-build → auto-simplify → auto-test → auto-review → auto-performance → auto-ship
    │            │                      │             │              │            │              │                │
 testable    acyclic DAG           all tasks     behavior-      green,       verified      measured, no      gates green,
   spec      + self-reviewed       integrated,   preserving     meaningful   findings      correctness       rollback ready,
             covers spec           tests green   cleanups       coverage     (no false +)  regression        human sign-off
```

Each arrow is a fail-closed gate: a phase that misses its bar is recorded `blocked` (never `done`) and its
items surface in the register so `converged` is false and a resume re-enters it — no phase hands a
false-green downstream. (The pass runs forward and collects findings rather than halting mid-run; the
register, not a mid-run stop, is what carries an unmet gate to the user.) The user may configure which
optional phases run (simplify/performance/go-live can be skipped);
build/test are not skippable. (This order follows spec→plan→build first; simplify runs against the
build's test safety net, test then hardens coverage.)

## Runtime backends — canonical deterministic coordinator vs. legacy Workflow

The unattended stretch runs on ONE of two backends. They are NOT peers: one is the canonical runtime, the
other a Claude-only compatibility shim.

- **CANONICAL — the deterministic coordinator CLI (`scripts/pipeline.mjs`).** A zero-dependency Node
  program: `node autonomous-pipeline/scripts/pipeline.mjs approve|start|resume|status|authorize`. This is
  the runtime the **Codex adapter launches** and the one Claude should prefer for a real run. The decisive
  property: **no model prompt owns Git, the checkpoint, the phase gates, or the convergence decision — the
  coordinator library (`scripts/lib/`) does, deterministically.** Model agents (native or Codex) appear
  ONLY as sandboxed, capability-free **per-task engineers**; Git integration (`git-integration.mjs`,
  `git-workspaces.mjs`), the locked checkpoint store, the fail-closed phase engine, the budget ledger, the
  capability-gated authorization, and the convergence conjunction (`pipeline-state.mjs`) are all machinery,
  not prose an LLM can talk its way past. A **BLOCKED required gate HARD-STOPS downstream execution** here
  (fail-closed): the run returns `status:blocked` / `converged:false` and no later phase runs.
  - `approve --plan <canonical.json> --config <run-config.json>` — validates the base is approval-ready,
    inits the durable run + immutable budget, enters the `prepared` window, and mints the ONE-USE,
    hash-bound plan-approval capability. **This IS the recorded human approval.** A human MUST sit between
    `approve` (mint) and `start` (consume) — the coordinator can never auto-chain the gate.
  - `start --run <id>` — runs every preflight refusal (plan/base/config drift, wrong target, dirty tree)
    and **consumes the one-use approval BEFORE a single executor spawns**, then drives build → post-build
    phases and publishes ONLY as a fast-forward after the explicit convergence conjunction + a durable
    finalize `done`. `resume --run <id>` continues from durable state (never erasing spend, never
    re-consuming the approval); `status --run <id>` is a read-only snapshot; `authorize --run <id> --action
    <ship|deploy|publish|remote-merge>` halts a converged run and mints a fresh, action-scoped capability
    for one irreversible step (a plan approval never satisfies an action). See `references/cli-contract.md`
    (grammar + exit codes), `references/budget-contract.md` (the immutable termination set), and
    `references/authorization-contract.md` (capability-gated approval + irreversible actions).
- **LEGACY (Claude-only) — `references/pipeline-workflow.js`.** A compatibility backend invoked via the
  Claude Code `Workflow` tool. The **Codex adapter cannot select it** (a Workflow needs the Claude Code
  runtime). Because a Workflow cannot ask the user or hard-pause mid-run, it does ONE FORWARD PASS
  collecting findings rather than hard-stopping on a blocked gate — an honestly-different shape documented
  in `references/pipeline-state.md`. Prefer the canonical CLI; reach for the Workflow only on a
  Claude-only install where launching the CLI is not an option.

## Phase 0: Intake — request, config, budget, mode

- Detect **new run** vs **resume** (`$request` = "resume" / a pipeline checkpoint id → resume; skip
  intake, load the checkpoint, continue at the recorded phase).
- New run: capture the request; ask the FEW configuration questions (`AskUserQuestion`): which optional
  phases to run (simplify, performance, go-live/ship-deploy), and any budget/scope steer. Keep it light.
- **Codex delegation (D14 — offer ONLY if detected).** Probe for a Codex integration (`command -v codex`,
  or a `codex`-type subagent in your available agents). If — and only if — one is present, offer the user
  a choice to delegate any of three roles to Codex: **build** (the per-task engineer), **review** (the
  slice + dimension reviewers), **verify** (the adversarial finding-verifiers). Pass their choice as
  `delegate: { build|review|verify: 'native'|'codex' }`. If Codex is NOT detected, do not mention it —
  every role runs native. (At run time, a `codex` role with no integration DEGRADES to native and the
  degradation is recorded in the register — never a silent skip.)
- **Note which specialists are actually installed** — the subagent types available to you and the domain
  skills in your available-skills list. `auto-plan` routes each task to the best fit BY DESCRIPTION (a
  Next.js task → whatever React/SSR specialist exists, whatever it's named), and you pass that installed
  set to the Workflow as `availableAgents` so a plan-assigned name that isn't present here degrades to a
  general engineer (recorded in `missingAgents`) instead of hard-failing. Never route on a guessed name.
- Verify a git work tree + working branch; declare the pipeline `budget-guard` contract; create the
  pipeline `checkpoint-resume` file (one unit per build task (phase statuses live in the same file)).

**Success criteria:** run mode determined; phase config + budget set; git preflight passed; checkpoint
open.

## Phase 1: Run the lifecycle (one approved pass)

The skill owns the human-facing front half (intake, spec, plan, and the single approval); a backend owns
the unattended stretch. Pick the backend by install: **Codex (and any Claude run that prefers determinism)
uses the canonical CLI** — after the approval is RECORDED (`pipeline.mjs approve`, which mints the one-use
capability), a human confirms and the run is launched with `pipeline.mjs start --run <id>`; Git,
checkpoints, gates and convergence are the coordinator's, never a prompt's (see **Runtime backends**
above). The steps below describe the **legacy Claude `Workflow`** path (`references/pipeline-workflow.js`),
which the Codex adapter cannot select:

1. **spec → plan** run first, in-session, by FOLLOWING their contracts (they may ask questions, so they
   stay outside the Workflow). Compose them by CONTRACT, not by a programmatic `Skill()` call: `auto-spec`,
   `auto-plan`, `auto-map` and `auto-learn` are `disable-model-invocation` skills (expensive, explicit-
   invocation only), and the docs are explicit that dmi *blocks programmatic invocation* — so a
   `Skill(auto-spec)` from here would fail. Instead read the installed skill's `SKILL.md` (find it under
   `.claude/skills/`, `.agents/skills/`, or the plugin root) and execute its phases directly; if it isn't
   installed, apply the methodology inline. Then the SINGLE approval gate on the plan (unambiguous
   affirmative).
2. **Create the checkpoint** (`checkpoint-resume`'s `scripts/checkpoint.mjs init`) — the Workflow
   sandbox has no filesystem access, so the skill creates the status file before launch. Pass
   `--launch '{"scriptPath":"<pipeline-workflow.js>","args":{…the full launch args…}}'` so the exact
   relaunch recipe is persisted IN the status file — then `run-status.mjs --resume` can reconstruct the
   resume with no session memory.
3. **Launch `references/pipeline-workflow.js` via the Workflow tool** with full args:
   - **required**: `root`, `workingBranch`, `validate` (the whole-workspace end-state gate), `planPath`
     (the approved DAG plan), `approved: true`, `statusFile`, `checkpointCli` (absolute path to
     `checkpoint-resume/scripts/checkpoint.mjs` — the status-writer agents call it).
   - **routing/quality**: `availableAgents` (the installed specialist set from Phase 0 — each task's
     plan-assigned agent/reviewer is honored when present, degrades to general when not, recorded in
     `missingAgents`), `allowGeneralFallback` (default true — degrade a missing specialist rather than
     crash), and `planValidator` (absolute path to `auto-plan/scripts/validate-plan.mjs` — the
     DETERMINISTIC DAG gate preflight runs; pass it so a cyclic/mis-ordered plan can't pass on model
     judgment. Without it, preflight falls back to an LLM plan check).
   - **budget/config**: the optional-phase `config` (`{simplify, performance, shipPrep}`), `budgetFloor`
     (default 60000 — stop-and-report at a phase boundary once the run dips below it), the concurrency
     caps (`maxBuildParallel`, `maxParallel`, `maxFix`), and `delegate` (D14 — the per-role Codex choice).
   It executes
   build → simplify → test → review → performance → ship-prep with fail-closed gates (a phase agent that
   died = a gate failure in the register; skipped ≠ clean), the DAG walk with worktree isolation and
   bounded fix loops (each engineer/reviewer routed to its task's specialist), and per-task checkpoint
   writes. It hard-throws without `approved: true` — the human gate cannot be bypassed.
4. AROUND the workflow (before launch / after it returns), use `watch-and-act` to gate on external signals — e.g. CI green on the pushed branch before offering a fix round. (A Workflow cannot invoke skills mid-run.)
4b. **After EVERY run (even a bumpy one)**, close by following the `auto-learn` contract (again by
   CONTRACT — it's a dmi skill; read its installed `SKILL.md` and execute it, don't `Skill()` it) —
   harvest the checkpoint's register/blocked-units/degradations into verified, routed learnings so the
   next run doesn't repay this run's tuition. Machine defects it finds are surfaced in the final report,
   never self-patched.
4c. **After a real (non-aborted) run**, then follow the `auto-map` contract (same — read its `SKILL.md`,
   don't `Skill()` it) — refresh the disclosure-tiered context map so every future session starts knowing
   the code that just shipped. (Learn first: learnings may update rules the map refresh then verifies.)
5. Any escalation (unfixable/ambiguous/irreversible) surfaces in the returned register and PAUSES the
   pipeline; on resolution, re-invoke — the checkpoint resumes at the exact phase/task.

**Querying a run (any time, from any session):** `node <checkpoint-resume>/scripts/run-status.mjs`
renders the newest run — phases, per-task progress, the open register, and the resume command — READ-
ONLY, so it's safe to run while the pipeline is in flight. `--list` shows all runs; `--resume` emits the
exact Workflow call to continue. This is how the user checks "where's my run at?" without touching it.

**Native /goal framing (Claude Code):** for a fully unattended run, set the session goal to the
pipeline's Output Contract before launching — `/goal` pins the done-condition ("workflow returned
converged:true with an empty register; every gate ran") and the platform's independent verifier model
checks it, so the actor never grades itself. See `converge-loop`'s
`references/native-goal-loop.md` for the full termination-set → /goal compilation.

See `references/pipeline-state.md` for the state machine, per-phase gate conditions, and the handoff
contract.

**Success criteria:** each phase reached its success bar before the next began; the checkpoint reflects
progress; escalations reached the user, not a guessed-through continuation.

## Phase 2: Verify + return the findings register (no auto-loop)

- Collect the phases' findings (review blockers, perf gaps, ship blockers), dedup, and `adversarial-verify`
  the aggregate so the register holds only real, confirmed items.
- The pipeline runs ONE pass and returns. If the register is non-empty, PRESENT it and let the user choose:
  run a fix round (re-invoke with the findings as the request — same intake), hand-fix, or accept-with-risk.
  Never loop the whole lifecycle on its own.

**Success criteria:** a verified, deduped findings register is returned; the next move is the user's, not
an autonomous recursion.

## Phase 3: Report

Read the pipeline checkpoint and report end-to-end (see Output Contract): what each phase produced, which
gates ran vs. were skipped (by user config), what shipped, and the open register. Fail closed — a run with
a dead gate or a red end-state is not "done".

**Success criteria:** an honest, phase-by-phase account; the durable checkpoint reflects the final state.

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "It's autonomous, let it loop until everything's perfect." | An unbounded whole-lifecycle loop is the multi-hour-grind failure mode. One pass, return findings, let the user decide. |
| "Build came back with blocked tasks but let's just run review anyway." | A phase that didn't meet its bar hands a false-green downstream. Gates fail closed — pause or escalate. |
| "The user approved the plan, so I can deploy too." | Plan approval ≠ deploy approval. Irreversible steps in any phase still need explicit sign-off. |
| "Resume by re-running from spec, it's cleaner." | That redoes finished work and can diverge from what shipped. Resume from the checkpoint at the recorded phase. |
| "Report it as shipped — most of it worked." | Partial is not done. Report what shipped, which gates ran, and the open register honestly. |
| "Skip the budget, the phases have their own." | The lifecycle is long; phase budgets don't bound the whole. Declare a pipeline budget too. |

## Red Flags

- The whole pipeline looping on its own without a user-initiated fix round.
- A downstream phase started while the upstream phase had unresolved blockers.
- A deploy/irreversible step taken on the strength of the plan approval alone.
- A resume that restarted from spec and redid integrated work.
- "Shipped" reported while a gate didn't run or the end-state validate is red.
- No pipeline-level budget declared for a full lifecycle run.

## Guardrails

- One approval gate (the plan); every irreversible/ambiguous/unfixable situation still escalates.
- One pass, no autonomous whole-lifecycle recursion; fix rounds are user-initiated.
- Phase gates fail closed; never pass a false-green downstream.
- Durable resume from the checkpoint; never restart from spec.
- Declare and enforce a pipeline-level budget.
- Report the honest end state, caveated by which phases were skipped.

## When To Load References

- `scripts/pipeline.mjs` — the **canonical deterministic coordinator CLI** (the Codex runtime):
  `approve|start|resume|status|authorize`. Run it (after a recorded `approve`) instead of the Workflow
  whenever determinism is wanted or Codex is the host; its `scripts/lib/` modules own Git, the checkpoint,
  the gates, and convergence. Read the three contracts below to drive it safely.
- `references/cli-contract.md` — the CLI's five-verb grammar, flags, and pinned exit-code table (the
  human-readable spec; `scripts/lib/cli-contract.mjs` is the enforced one). Load before scripting the CLI.
- `references/budget-contract.md` — the immutable termination set (the whole-run budget/no-progress/
  escalation bound the coordinator enforces). Load when setting or reasoning about a run's budget.
- `references/authorization-contract.md` — the capability-gated plan approval + irreversible-action model
  (`approve`/`authorize`). Load before wiring approval or any ship/deploy/publish/remote-merge step.
- `references/pipeline-workflow.js` — the LEGACY Claude-only Workflow backend for the unattended stretch
  (build → simplify → test → review → performance → ship-prep, forward-pass, checkpointed). The Codex
  adapter cannot select it. Launch via the Workflow tool with full args after the plan approval; edit +
  relaunch (same scriptPath) to iterate.
- `references/pipeline-state.md` — the phase state machine, per-phase gate conditions, the phase-to-phase
  handoff contract, the checkpoint v2 schema, and the canonical-hard-stop vs. legacy-forward-pass
  divergence. Load when wiring or resuming a run.
- The phase skills — `auto-spec`, `auto-plan`, `auto-build`, `auto-simplify`, `auto-test`, `auto-review`,
  `auto-performance`, `auto-ship` — each runs its own phase to its own bar.
- `checkpoint-resume` (skill) — the durable pipeline + per-phase state.
- `budget-guard` (skill) — the whole-run budget + escalation contract.
- `watch-and-act` (skill) — wait on CI/deploy signals between phases.
- `adversarial-verify` (skill) — verify the returned findings register.

## Output Contract

Report:

1. the run config — which phases ran vs. skipped; the working branch; the single approval recorded
2. per phase: outcome + gate status (met its bar / blocked / skipped); which specialists the build
   actually routed to (`specialistsUsed`) and any plan-assigned specialist that was absent here and so
   ran generic (`missingAgents` — surface it so the user can install the missing agent/skill)
3. ship-prep artifacts produced (changelog + PR body draft — OPENING the PR / deploying is the user's explicitly-gated step) and the end-state validate result (honest)
4. the verified open findings register + the next-move options (fix round / hand-fix / accept-with-risk)
5. the pipeline checkpoint path (durable, resumable record) + the one-liner to query it any time
   (`run-status.mjs` for a rendered view, `run-status.mjs --resume` for the relaunch call)