backpressured

name	backpressured
description	Runs a backpressured automated development loop. Use it ONLY when the user explicitly mentions "backpressured" or "backpressure" — e.g. asking for a "backpressured" loop/run, "do this backpressured", or invoking it by that name — or runs the `/backpressured:goal` command. A bare `/goal`, or any goal-like request that does not mention backpressure, does NOT trigger this loop.

Backpressured

Overview

You are the producer's backpressure of LAST resort — your job is to replace yourself with machines that say "no" first. A human reading your code should be the last line of defense, never the first. Every "no" a machine can produce — a failing test, a type error, a lint rule, a benchmark regression, a reviewer's objection — must be produced by the machine, before you hand anything back.

So you do not stop when the code "works." You drive the goal through the full loop below and stop only when every acceptance criterion and every quality check passes — or when you are genuinely blocked and can name exactly what is blocking you.

When to Use

• The user explicitly mentions "backpressured" or "backpressure" — asking for a backpressured loop/run, "do this backpressured", or invoking it by that name (brand-name mentions count too).
• The user runs the /backpressured:goal command.

Not for: generic "implement X", "fix this bug", "build X and ship it", "open a PR", or a bare /goal request that does not explicitly mention backpressure. A finished, landed result being expected is not by itself enough — wait for one of the two signals above. Also not for one-line factual answers, pure research/exploration, or when the human wants to drive step by step.

First: pin down "done"

"Done" is defined by criteria, so make them explicit before anything else:

• Acceptance criteria — what must be true for the goal to be met. If the user didn't list them, infer them and state them up front.
• Quality checks — lint, tests, new behavior covered, project verification scripts, benchmarks, review. These apply on top of acceptance criteria, every time.
• Project customization — check for an optional BACKPRESSURE.md at the project root and fold its instructions in now (see Figuring out the checks).

The Loop

digraph backpressure_loop {
    "Goal received" [shape=doublecircle];
    "Write lightweight plan (approach + architecture, not details)" [shape=box];
    "Independent reviewer approves the plan?" [shape=diamond];
    "Revise plan" [shape=box];
    "Write the next patch" [shape=box];
    "Run every applicable check (incl. independent code review)" [shape=box];
    "All checks green?" [shape=diamond];
    "Fix the failure" [shape=box];
    "Genuinely blocked?" [shape=diamond];
    "STOP: name the blocker, do NOT mark done" [shape=octagon, style=filled, fillcolor=red, fontcolor=white];
    "All acceptance + quality criteria met?" [shape=diamond];
    "Run for real: curl, browser, full suite, full benchmarks, holistic independent review" [shape=box];
    "Open the PR" [shape=box];
    "Monitor: CI, comments, conflicts" [shape=box];
    "Landed clean with nothing outstanding?" [shape=diamond];
    "Done" [shape=doublecircle];

    "Goal received" -> "Write lightweight plan (approach + architecture, not details)";
    "Write lightweight plan (approach + architecture, not details)" -> "Independent reviewer approves the plan?";
    "Independent reviewer approves the plan?" -> "Revise plan" [label="no"];
    "Revise plan" -> "Independent reviewer approves the plan?";
    "Independent reviewer approves the plan?" -> "Write the next patch" [label="yes"];
    "Write the next patch" -> "Run every applicable check (incl. independent code review)";
    "Run every applicable check (incl. independent code review)" -> "All checks green?";
    "All checks green?" -> "Fix the failure" [label="no"];
    "Fix the failure" -> "Genuinely blocked?";
    "Genuinely blocked?" -> "STOP: name the blocker, do NOT mark done" [label="yes"];
    "Genuinely blocked?" -> "Run every applicable check (incl. independent code review)" [label="no"];
    "All checks green?" -> "All acceptance + quality criteria met?" [label="yes"];
    "All acceptance + quality criteria met?" -> "Write the next patch" [label="no — keep going, do NOT hand back"];
    "All acceptance + quality criteria met?" -> "Run for real: curl, browser, full suite, full benchmarks, holistic independent review" [label="yes"];
    "Run for real: curl, browser, full suite, full benchmarks, holistic independent review" -> "Open the PR";
    "Open the PR" -> "Monitor: CI, comments, conflicts";
    "Monitor: CI, comments, conflicts" -> "Landed clean with nothing outstanding?";
    "Landed clean with nothing outstanding?" -> "Write the next patch" [label="no"];
    "Landed clean with nothing outstanding?" -> "Done" [label="yes"];
}

Phase 1 — Plan, then get it reviewed (before any code)

Write a lightweight plan: the overall approach and architecture, not implementation details (defer those to the loop). Then dispatch the reviewer subagent to judge whether the fundamental approach is sound; it applies [[plan-review]] for its criteria. Iterate until it approves. Only then write code. A wrong approach caught here is free; caught after 300 lines it is not.

Phase 2 — Implement in a loop, with checks EVERY iteration

After each patch, before writing the next one, run the checks that apply to this project:

• lint clean
• tests green, and new behavior covered by new tests (if the project has tests)
• project verification scripts (typecheck, commit-message check, etc.)
• benchmarks via [[running-benchmarks]], if the project is performance-sensitive (the fast targeted suite per iteration)
• a visual review via [[visual-review]] for front-end changes (screenshots vs. the design)
• the reviewer subagent on the diff

Run checks every iteration, not batched at the end — confronting the consumer's expectations often is what catches issues early. Scope them to stay fast (lint + targeted tests on touched code is fine per patch), but never skip them, and run the full suite before you leave the loop. Do not write the next patch until everything you ran is green.

Phase 3 — Before you call it done

Automated green is necessary, not sufficient. Once all criteria appear met, in this order:

1. Run the full test suite + lint, and the full benchmark suite via [[running-benchmarks]] if perf-sensitive. Cheapest signal first — no point hand-driving the app if a unit test already catches it.
2. Only once that's green, run the app for real via [[manual-testing]]: exercise each acceptance criterion and the cheap unhappy paths through the running app (curl the API, a real browser via Playwright for the UI). Always run this gate — green automated tests, including integration and end-to-end suites, do not satisfy it; they exercise the code, not the running system. The only exception is when BACKPRESSURE.md's Skip section explicitly opts out of manual testing (e.g. it designates an E2E suite as the replacement). Absent that written opt-out, manual testing runs — your own judgment that "the tests cover it" is not an opt-out.
3. For front-end changes, run [[visual-review]] over the whole feature, not just the last view you touched.
4. Dispatch the reviewer subagent over the whole changeset, not just the last patch.

Phase 4 — Ship and monitor

Open the PR — then keep watching it until it lands. A PR opening is not "done." Done is when the change has merged clean (or you are blocked on something only a human can resolve). Run the watch-until-landed loop in [[pr-monitoring]]: CI to completion, the green-minute rule (a green check can flip red), late review-bot/human comments, and merge conflicts — monitoring in the background, but never abandoning it before merge.

Independent reviewers are not optional

Reviews must come from a subagent that did not write the code. Your own re-read shares the blind spots you wrote with — "it looks clean to me" is exactly the state in which subtle bugs survive. Dispatch the reviewer subagent (defined in this plugin's agents/), hand it the diff or plan, and let it invoke the relevant reviewer skill(s) below for its criteria; then act on the real findings (and push back on wrong ones). This applies to the plan (Phase 1), each iteration (Phase 2), and the whole changeset (Phase 3).

This skill is the router; the criteria live in the reviewer skills

Do not inline review criteria here. Each review dimension is its own skill, and the reviewer subagent invokes the relevant one(s) for the diff in front of it. Dispatch by what the diff touches:

Dimension	Reviewer skill	Dispatch when the diff…
Correctness, simplicity, tests	[[general-code-review]]	almost always — the default lens for logic/edge-case bugs, needless complexity or duplication, and whether new behavior is actually tested
Type design	[[type-design-review]]	adds/changes data models, function signatures, or domain types (booleans/optionals for state, switch over unions, as/!, raw string/number ids)

A diff usually warrants more than one dimension — give the subagent every reviewer skill that applies, not just one. [[general-code-review]] is the default; add [[type-design-review]] (and future reviewer skills) on top when they apply. The plan review (Phase 1) judges approach soundness against a plan rather than a diff, so it uses [[plan-review]] instead of these code-review dimensions.

Also apply any project/personal standards skills the project names. If BACKPRESSURE.md has a Review section listing standards skills (e.g. react-best-practices, design-skills, an accessibility or API-style guide — typically from the project's .claude/skills/ or your ~/.claude/skills/), hand those to the reviewer subagent too, alongside the dimensions above. They encode this project's conventions; the reviewer should hold the diff to them.

Figuring out the checks

Two inputs decide what runs:

1. An optional BACKPRESSURE.md at the project root — plain-English, project-specific instructions that customize this loop: exact check commands, extra gates, things to skip, acceptance defaults, how to run the app or pick a benchmark suite, and so on. It is optional. If it exists, treat its instructions as authoritative project customization layered on the defaults here — it wins on conflict, and it overrides the loop diagram and Quick Reference too. So it can skip or replace any step they show (e.g. "don't open a PR, we merge from local branches" or "skip the visual review"). If it does not exist, just use the defaults; do not create one or ask the user for one.
2. What the project actually has — wherever BACKPRESSURE.md is silent (or absent), discover the commands yourself: package.json scripts, Makefile, CI config, README.

Gate the project-specific layers on what exists: no benchmark suite → skip benchmarking; not a UI change → skip the visual review; not a git/GitHub repo → skip PR open/monitor. Run what exists; do not invent or fake checks.

Quick Reference

Phase	Backpressure applied
Plan	Independent reviewer approves the approach before any code
Each iteration	Lint, tests, coverage, verification scripts, benchmarks, visual, independent code review
Before done	Real run (curl + browser), full suite, full benchmarks, holistic independent review
Ship	Open PR, then monitor CI + comments + conflicts until landed

Common Rationalizations

Rationalization	Reality
"I'll run lint/tests once at the end"	Run them each iteration. End-only batching turns one red bar into a bisecting session and lets bad patches pile up.
"My own careful re-read is enough review"	You review with the same blind spots you wrote with. Spawn an independent reviewer.
"The PR is open, so I'm done"	Open ≠ landed. Monitor CI, comments, and conflicts until it merges clean.
"The approach is obvious, skip the plan review"	Obvious-and-rushed is exactly when the wrong approach ships. Get the plan reviewed first.
"It works when I curl it, ship it"	One manual happy path is not the full suite, edge cases, or a real browser.
"Integration/E2E tests pass, so manual testing is redundant"	Automated suites exercise the code, not the running system, and share the blind spots you wrote with. Run the app for real every time — the only exception is an explicit manual-testing opt-out in BACKPRESSURE.md.
"This is a natural breakpoint, I'll check in"	You are backpressure of last resort, not first. Keep going until criteria pass or you are blocked.
"CI will catch it"	CI catching it means a human waits on a red PR. Catch it locally first.
"The flaky/failing check isn't really my problem"	A red check is unresolved work. Fix it, or stop and name the blocker — never skip, retry-until-green, or mark done around it.

Red Flags — STOP

• About to report partial progress and hand back without a concrete blocker
• About to open a PR without an independent review
• About to skip or defer checks "just this iteration"
• About to call it done off green automated tests (including integration/E2E) without running the app for real, with no manual-testing opt-out in BACKPRESSURE.md
• Treating PR-open as the finish line
• Skipping the plan review because the approach "feels obvious"

All of these mean: you are about to become the human backpressure you are supposed to replace. Get back in the loop.