Dev Pipeline

What it is

Dev Pipeline is an opt-in bundled skill that runs a full software-development workflow end to end on one task — investigate, plan, red-team, build (which starts by creating the run's worktree), code-elegance pass, docs, git-prep — pausing at five approval gates (one per phase 1–5; phase 6 finishes on its own) so you stay in control.

Off by default — except on a box set up with the team dev profile, which enables it for you (devPipelineSkillEnabled, applied by npm run setup); on an Omniscio dev machine it is likely already on. Otherwise enable it under Settings → Features → "Enable Dev Pipeline skill". Flipping it on installs the skill into your ~/.claude/skills/dev-pipeline/ (this requires Omniscio's global skill-sync, which is on by default); flipping it off removes it. No restart needed. Because it installs into your global skills dir, /dev-pipeline then works in every project, and — once the config-sync feature is on — is carried to your other AI CLIs too.

It also installs /ready-to-merge (into ~/.claude/skills/ready-to-merge/, same toggle). That's the merge-prep gate on its own: rebase once onto the base branch, run the repo's real lint/typecheck/tests, classify each red as pre-existing debt vs. a regression this branch introduced, and — only if it's green for what the branch changed — stamp the SHA-bound ready-to-merge tag the git-guardrails push gate validates. The pipeline runs that same gate itself in Phase 6, so you never need /ready-to-merge mid-pipeline; it's there for the common case of a branch you built without the pipeline that still has to earn the tag before it can be pushed. Like the pipeline, it never pushes and never merges.

The flow

Invoke it in a Claude Code session with /dev-pipeline "<task>" (or "run the dev pipeline on X"). It drives six phases in order; phases 1–5 each STOP at a hard gate where you reply approve / feedback / abort:

Phase	Ends at gate header
1 — Investigate & plan	## 🔍 🟢 Plan Ready
2 — Red team (10 lenses) + revised plan	## ⚔️ 🟢 Red Team Complete
3 — Build & verify	## 🔨 🟢 Build Complete
4 — Code elegance (mechanical only)	## 💎 🟢 Elegance Pass Complete
5 — Docs	## 📝 🟢 Docs Complete
6 — Git prep (branch ready)	## 🚀 🟢 Ready to Merge (no gate — finishes)

Every gate report reads the same way from one phase to the next — a one-line headline, then a few ## section headers (one sentence per bullet, like the final "Ready to Merge" report), then the standard approve / feedback / abort footer (the "Ready to Merge" report is the exception: no headline, and a one-line bottom summary instead of the footer) — so you never re-learn the layout mid-run. The header's status dot triages how much input the gate needs from you: 🟢 nothing (safe to just approve), 🟡 a question to answer, 🔴 a serious call or a blocker — and a non-green dot swaps in an honest title (e.g. ## 🔍 🟡 Plan Not Ready — One Question), so a green header always means "nothing needed". In the chat, the little pipeline-stepper widget under each report lights the current step to match — green, amber, or red.

By default each gate is a real, observable stop — there is no hands-free seam. (Opt-in autonomous mode — see below — self-advances the gates and stops only when something genuinely needs you.) In Phase 6 the pipeline runs one authoritative, self-contained verification pass — it runs the project's full lint/typecheck/tests/build itself, in the same session (never trusting a prior run's "it passed" claim), and classifies each failure: a failure already red on the base branch is pre-existing debt and does not block, while a regression this branch introduced does. When every check is green or classified pre-existing it stamps the branch's SHA-bound ready-to-merge tag; the pipeline emits ## 🚀 🟢 Ready to Merge only once that tag is confirmed on the current commit — so the header always means a genuinely-tagged branch (if it can't be tagged, it reports a 🔴 not-ready status instead). The pipeline never pushes or merges on its own — even in autonomous mode.

Right-sized rigor. The Phase-2 red team always applies all 10 lenses, but verdict DEPTH scales to the task: a docs-only or tiny mechanical change gets terse one-line verdicts instead of manufactured paragraphs of hypothetical risk, while anything sizable, risky, or novel gets full depth — the revised plan is always full quality either way.

A UI change arrives with a picture of itself. When the work adds or moves a control — a new screen, panel, row, button, dialog, menu item, layout move, or a visual state — Phase 1 also renders the change before the Plan gate: one page showing the same screen twice, labelled before (today) and after (proposed), built from the real component and the repo's design language. It rides the Plan Ready report as a UI Render section carrying the link (published to Shares, so it opens on your phone). A copy, label, icon, colour or spacing tweak that adds no control and moves no layout skips it, as does a non-visual change — and every skip is stated in one line rather than passed over. The render is best-effort and can never block a run, it is a labelled mock rather than a screenshot (at plan time nothing is built yet), and it carries placeholder content rather than any real data. The real before/after of the finished interface stays the job of the post-build screenshot path, which runs once the UI actually exists.

Where to find it

Running inside Omniscio

One-click gate replies. When a gate is waiting on you — the plan gate (manual by default), a gate you switched off auto-approve, or a HOLD — Omniscio shows Approve, Feedback and Abort buttons right above the reply box. Approve sends approved, Abort asks you to confirm, then sends abort (the run stops and its work is kept), and Feedback just puts the cursor in the reply box so you can type what to change. Typing a reply still works for anything else. The buttons only appear when the session is actually waiting on you for that gate, never while a run is moving on its own, and they disappear once you answer (see the repo's pipeline-gate-reply-buttons-contract.md).

When you run it inside Omniscio, completing a gate auto-advances to the next phase and the run shows up on the agent status board — Omniscio reads the skill's .claude/pipeline/state.md and the byte-exact gate headers above. Outside Omniscio the workflow is identical; you approve each gate yourself. (Those markers are locked to Omniscio's parsers by a conformance test that runs at every merge gate, so the integration can't silently drift.)

Six robustness layers keep real-world runs from stalling or mis-advancing:

• A bookkeeping slip can't cost you the whole run. The run's state.md records which gate it is parked at, and the agent is supposed to move that label forward at every phase boundary. Agents forget. When the label is left BEHIND — say it still reads "waiting at the plan gate" while the agent has just posted its Red Team report — every later gate used to be checked against that stale label, match nothing, and quietly refuse to advance, for the rest of the run: one missed update and you hand-approve every remaining gate (observed live, 2026-08-25, and again 2026-09-20 at the 🚦 Standards Check). Omniscio now advances the gate the agent ACTUALLY finished, provided the run's own history proves it genuinely reported every earlier gate — the same in-session lineage proof the engine-agnostic fallback uses. Manual gates stay manual: a gate you left manual — the plan gate by default, or any gate you switched off auto-approve — is only stepped past after a real person replied following that gate's report; Omniscio's own automatic messages never count. Advancing only ever moves FORWARD, never past a hand-back or any other deliberate stop, and every existing veto still applies. Every gate you have configured counts, custom ones included — the reserve covers the 🧭 AI Code Review and the 🚦/🔬 Standards gates exactly as it covers the six numbered ones, so a run parked at a custom gate is picked up rather than stranded. The reserve also reads the run's own closing line: a run that has already reached its final gate is treated as finished and left alone, instead of being re-judged every few minutes against a gate it moved past. Both outcomes show in the log: a rescue says it advanced a gate the state file was still behind on, and a refusal names both the stale label and the real gate. See the repo's pipeline-auto-advance-contract.md (in .claude/memory/contracts/) invariant stale-gate-token-backstop.
• Label forgiveness. Agents hand-write state.md and sometimes invent label variants (PHASE_5_VERIFY, GATE_3_LOCAL_VERIFY (…), DONE — … — all observed live). Omniscio normalizes number-prefixed variants to the canonical labels so auto-advance and the panels keep working; a genuinely unknown label stays raw and never advances anything. Advancing still requires the byte-exact gate evidence in the agent's message (two-factor), so forgiveness can't cause a wrong approval.
• Question-widget veto. A gate report whose body asks you a real question is NEVER auto-approved — even if the agent mistakenly printed an AUTO-APPROVE: OK marker beside it. Omniscio asks its canonical question-widget parser (every widget format it can render), fences excluded, so quoted examples don't false-hold. One thing it does NOT hold on: a routine "approve to proceed?" the agent tucks into its own Plain Speak overlay card (below the report) — that tail is overlay metadata Omniscio strips before the check, so a green gate that just repeated its approve/feedback/abort footer as a card widget still auto-advances instead of stranding on a question you were never really asked. A genuine decision rides the report body (or a 🟡/🔴 header), which still holds.
• A HOLD always holds. If a gate report says AUTO-APPROVE: HOLD for a gate anywhere in the message, Omniscio never auto-approves that gate — not even when an AUTO-APPROVE: OK for the same gate turns up further down (a recap, an example, the Plain Speak card). Only when every marker is an OK does the last one decide. This holds on every path, including the backstops that rescue a run whose state.md token is missing or left behind. Markers and headers inside a fenced code block are illustrations and never count, while a gate header the agent wrapped in backticks still counts as its real header — so a quoted example can't approve a run and a backticked 🔴 header still stops one. See the repo's pipeline-auto-advance-invariants-1-contract.md (in .claude/memory/contracts/) invariants the-marker-is-primary and a-quoted-marker-is-never-the-verdict.
• Any AI engine — even one that skips the state file. Auto-advance is not Claude-only: cursor/grok, codex, gemini and the other non-Claude engines advance their gates too, with the "approved" delivered through the engine-aware sender (a one-shot engine has no live stdin like Claude). And because some non-Claude agents don't reliably write state.md, Omniscio keeps a loop-safe state.md-free fallback — it advances a gate on the trailing AUTO-APPROVE: OK marker ONLY when the session's own history proves it genuinely reported every earlier gate in its own prior turns (the in-session lineage). A session merely quoting a marker has no such lineage, so it can never self-approve; a single injected turn can't invent prior turns. Kill-switch AMC_DISABLE_EXTERNAL_PIPELINE_FALLBACK=1 disables just that fallback (never the strict state.md path). See the repo's pipeline-auto-advance-contract.md (in .claude/memory/contracts/) invariant non-claude-engines-auto-advance.
• A non-Claude engine gets the workflow handed to it. Claude (and the Claude-compatible vendors like DeepSeek / Kimi / GLM) runs the pipeline from the installed /dev-pipeline skill. A skill-less engine — Codex, Gemini, OpenCode, Cursor and the like — can't invoke that skill, so on a software-development session in an enabled repo Omniscio injects a compact portable brief of the whole workflow (the six phases, the five stop-and-wait gates, and the exact gate markers) straight into that engine's own instructions. It's best-effort — a leaner model follows it less precisely — but a Codex run now drives the same gated pipeline and lights up the panel like a Claude run. The brief also carries the skill's guidance for verifying under a per-command time limit — offload heavy checks (a --cloud wrapper) off the engine's clock, and treat a check that can't finish in time (a timeout / missing toolchain) as an environment caveat that keeps the gate green rather than a stop — so a time-limited engine like Codex no longer strands the Build gate on a lint that timed out (the fix for a live 2026-08-15 go-live wave). Claude is unaffected: the brief is only ever sent to a non-Claude engine.
• A missing to-do tool never stalls a run. Some harnesses don't expose TodoWrite; the run notes that and carries its six-step backbone in the state file instead.
• A stranded gate gets picked back up. Auto-advance normally happens the instant a phase reports done. If that instant is ever missed — a rare timing edge, or Omniscio restarting at exactly the wrong moment — a periodic background check finds any run still parked at a gate whose latest report carries a valid AUTO-APPROVE: OK and advances it for you. It's a true backstop, not a competitor to the instant path: it only touches gates you've left on auto-approve, only after one has sat parked a few minutes, and only when nothing newer from you is waiting — so it can never race the normal path, re-approve over you, or double-spend a turn. It also stays on your side when the computer is busy: it used to stand down completely under heavy load, which could leave a valid gate parked for the whole busy stretch — now it just raises the bar (rescuing a gate that's been stuck about fifteen minutes, one at a time) instead of standing down, so a genuinely stuck gate still gets cleared mid-crunch. Kill-switch AMC_DISABLE_PIPELINE_GATE_RECONCILE=1. See the repo's pipeline-auto-advance-contract.md (in .claude/memory/contracts/) invariant level-triggered-reconcile-backstop.

Companion toggles (Omniscio)

Enabling the skill reveals five optional, independent companions under the same Settings → Features → "Enable Dev Pipeline skill" row (plus the plan-gate sub-option) — see the repo's dev-pipeline-companions-contract.md (in .claude/memory/contracts/):

• Gate auto-approval (per phase) — for EACH of the five gates (Plan · Red Team · Build · Elegance · Docs) a toggle for whether Omniscio clears it itself or always asks you, plus a select-all master. Backed by pipelineGateAutoApprove, resolved by resolveGateAutoApprove (falling back to the deprecated pipelineAutoAdvanceEnabled / pipelineAutoApprovePlanGate, so no prior choice is lost — zero migration). Defaults preserve the prior behavior: the Plan gate asks you, while Red Team / Build / Elegance / Docs auto-clear the moment a phase reports done. A gate that asks a question or reports a blocker is never auto-approved, whatever its toggle. The same controls appear in Settings → Features AND the Dev Pipeline panel — both bind the one resolved map.
• Remind every session to use the pipeline (devPipelineReminderEnabled, default OFF) — writes a short, self-gating note into each spawned session's .claude/amc-instructions.md: follow /dev-pipeline IF this session is doing software development, otherwise ignore it. Skips the in-app helper bots (Ask Omniscio / Ask-page / Automation Helper) and is independent of the Default Agent Instructions feature.
• Add the pipeline quick replies (devPipelineQuickRepliesEnabled, shipped default OFF but turned ON for every developer by npm run setup) — seeds the "Full Local Git", "Open a Pull Request", "Package My Work Into PRs", and "Worktree Cleanup Analysis" quick replies if they are missing, grouped inside a "Dev Pipeline" FOLDER placed at the top of your quick-reply list (so they stay tidy and, being a folder, out of the composer picker's first-pop-up view). All four are day-to-day git actions, in the order you meet them: "Full Local Git" (a local land-all-ready + worktree/branch cleanup + mobile-rebuild pass, unnumbered), then "Open a Pull Request" (the contributor path — finalize ONE worktree, run the gate, rebase, open the PR, stop), then "Package My Work Into PRs" (the whole-checkout path — read everything your local trunk has that the shared trunk does not, subtract what already landed or is already in an open PR, and slice the rest into PRs sized on BOTH ends — too big and a PR sits unmerged collecting conflicts, too small and you drown in merge cycles, since each one costs a branch + a check run + a review + a merge; so: one AREA of the codebase per PR, reviewable in about fifteen minutes, revertible on its own, split on the AREA boundary rather than the commit boundary, two same-area changes that add no extra risk kept in ONE PR rather than split just because they can be named separately, and past roughly eight PRs it goes back and combines same-area neighbours; every file lands in exactly one PR or on a stated left-out list, dependency / migration / security changes always get their own PR regardless of size, and it stops for your approval before opening anything — you can approve all of it, some of it, or send it back), then "Worktree Cleanup Analysis" (a bare /worktree-cleanup, which retires the worktrees the other three leave behind — one line on purpose, because that skill already owns every safety rule and restating them here would fork them). The two PR replies are the ones that do NOT auto-submit: opening PRs is outward-facing, so they land in the composer for you to read and edit before they send. One-way: turning it off never deletes quick replies you already have; a reply you already keep — including your own "Full Local Git" — is left exactly where it is (never pulled into the folder), and if you already have all four no folder is created. When they arrive: on every launch, not only when you flip the toggle. Omniscio checks the bundle at startup, so a reply ADDED to it in a later release still reaches you even though your toggle went on months ago — which it could not before 2026-09-07, when "Package My Work Into PRs" sat undelivered on installs that already had the companion on. Each reply is offered exactly ONCE (recorded in devPipelineQuickRepliesSeeded), so one you delete never comes back on the next launch. Switching the toggle off and on again is the deliberate way to ask for the whole set afresh. "Package My Work Into PRs" was hardened after a red-team pass (2026-09-01) and its rules are load-bearing, not boilerplate. It may never reset / rebase / amend your local trunk or touch a worktree it did not create (the unlanded work often lives ONLY there), it slices in NEW worktrees and proves your trunk still points where it did, it bails out and says so if the repo lands work locally instead of by PR (an owner box with an auto-lander — where opening PRs is against the house rules), it measures the delta and comes back with a strategy rather than grinding through an oversized one, it de-duplicates against open PRs by CONTENT rather than sha (a landed PR is a cherry-pick with a NEW sha, so sha matching silently re-publishes), it scans for secrets before any push, and it builds each cut branch standing alone to catch the classic split failure — two PRs that each pass on the author's machine, one of which will not compile on the trunk without its sibling. Each rule maps to a specific failure; read the block comment above the constant before trimming any of them. The set is landing-only by design. The "Red Team" (skill Phase 2) and "Full Documentation Prompt" (Phase 5) mirrors were seeded here until 2026-09-01 and were removed: the skill already runs those phases itself, so a second hand-fired copy in everyone's picker was duplicate surface, not a shortcut. Red Team is still a normal seeded default in seed-defaults.ts — still the single editable copy the Phase-2 parity test pins, so that test is unaffected — it is just no longer duplicated into this folder.
• Add the workflow auto-replies (devPipelineAutoRepliesEnabled, default OFF) — seeds a small set of preset auto-reply rules for the pipeline's common handoffs (e.g. answering a red-team completion with "proceed"). Two-way by stable id: turning it off removes exactly the presets it added, never rules you wrote.
• Write a durable note into the repo (devPipelineFileNoteEnabled, default OFF) — this one edits a git-tracked file in your own repository, which is why it is called out here: reconcileDevPipelineFileNote splices a marker-bracketed managed block (<!-- AMC-DEV-PIPELINE:note:start … --> … <!-- AMC-DEV-PIPELINE:note:end -->) into the repo's OWN CLAUDE.md — else AGENTS.md, else it creates CLAUDE.md — for every repo enabled in the per-repo selection. Unlike the ephemeral reminder above, the note persists in a file you see and commit, so it also reaches sessions Omniscio did not spawn. Written/removed at Claude session spawn: two-way (turning it off strips the block again), idempotent, atomic, fail-open, and independent of devPipelineReminderEnabled. This repo's own CLAUDE.md carries such a block.

How it behaves

The build checklist + definition of done

Before it builds, each run pins down what "done" means — and then tracks the work so nothing slips:

• Definition of done — at the plan gate the run lists the concrete "Done when …" outcomes for the task; approving the plan approves them. In Phase 3 each one must be met with real evidence (a test or an observed result) before the build gate can go green — a passing test suite isn't the same as the thing you asked for being finished.
• Implementation checklist — alongside those outcomes, Phase 1 breaks the plan into a granular, itemized checklist of every build task and shows it at the plan gate as a ## Build Checklist, then mirrors it into the session's to-do list so it appears on the agent status board and ticks off live as the build runs. In Phase 3 every item must end up checked off — or explicitly deferred with a reason — before the build gate goes green; an item left unfinished blocks it, exactly like an unmet outcome. A long, multi-part build can't quietly forget a requirement.

Autonomous mode (opt-in)

Ask for hands-free operation — "run autonomously", "no check-ins", "leave it overnight", or /dev-pipeline --auto "<task>" — and the run drives itself through every phase, doing the full work of each, self-approving the gates and stopping only when something genuinely needs you: a real decision (scope, a trade-off, anything irreversible), an ambiguous ask, a risky rewrite, or a build it can't get green. It still ends at "Ready to Merge" and still never merges or pushes on its own. The default stays the normal five-stop flow; autonomous mode is per-run, recorded in the run's state.md as ## Mode: autonomous so it survives a mid-run compaction.

Tiered-model execution (opt-in)

Ask for it — "run tiered", "smart planner, middle executor", "plan on Opus, build on Sonnet", or /dev-pipeline --tiered "<task>" — and the run splits the work across two model tiers: a smart model does the planning and judging, a middle model does the heavy execution. By default only the Build phase drops to the middle tier (plan, red-team, elegance, and docs stay smart) — which is exactly "smart plans and judges, middle executes" — but you can reassign any of phases 1–5 (e.g. "tiered, docs on middle too"). The default pair is the smart tier for planning and judging and the worker tier for execution — tier names, never a pinned model id, so the sentence does not go stale when a new model ships. ("Plan on Opus, build on Sonnet" is how you might say it; the pipeline stores the tiers.) You can name a different pair per run.

The smart main loop always keeps the judgment: on a middle phase it delegates only the generative work to a middle-model subagent, then reviews that output and presents the gate itself — the tiering never quietly moves a judgment call to the weaker model. If a middle-model subagent can't actually be run, the pipeline reports "tiered execution unavailable" rather than silently running everything on one model while implying a saving. Like autonomous mode it's per-run, recorded in state.md as ## Models: tiered so it survives a mid-run compaction, and the two compose freely. The default stays a single model for the whole run.

Even without tiered mode, the build already leans cheap by default. In an ordinary single-model run, the Build phase now encourages handing the actual code-writing to cheaper Sonnet-level implementer subagents while the orchestrator reviews and double-checks every diff — the same "cheap writes, smart reviews" economics as the tiered Build tier, but with no opt-in. Crucially this is decoupled from parallelism — even work that can't be fanned out in parallel (a shared-git audit fix-wave committed one finding at a time) still hands each edit to a cheaper implementer and reviews it serially (a sequential cheap-writer), so "can't parallelize" is never by itself a reason to keep the writing on the expensive model. It's a bias, not a rule: a tiny cohesive change, or work that genuinely needs the smart model's own hand, can stay on the main loop. Tiered mode above is just the formal, recorded, per-phase version of that same split. Details: the dev-pipeline skill CONTRACT.md invariant 31.

Related

The opt-in behaviour modes, the configuration layers and the skill's internals are on Dev Pipeline (part 2).

Every control and toggle for this workflow — which repos it watches, the gate auto-approval switch, and the panel's own setup — lives in the Dev Pipeline panel, never in Settings. The housekeeping jobs that ride alongside it are documented in Dev Pipeline Maintenance.