backpressured

Sets up backpressure for a project — detects its check/run commands, writes or edits a BACKPRESSURE.md, verifies Playwright, and installs the MCP servers the loop uses. Runs ONLY when the user explicitly invokes `/backpressured:config`; never auto-trigger it.

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.

Use after a pull request has been opened and the task is not finished until it lands. Triggers on "PR is open", "CI is running", "is it merged yet", a PR that is green but not merged, fresh CI that might still flip, or being tempted to report a task done at PR-open. GitHub / gh CLI based.

Verifies a feature works by running the real app, not by trusting green tests. Use when a backpressured loop reaches the before-done gate (Phase 3) and needs to confirm new behavior end-to-end — curling live API endpoints and driving a real browser via Playwright — including the cheap unhappy paths, before the task is called done.

Use when a backpressured code-review subagent is judging whether a diff uses the type system to make illegal states unrepresentable — i.e. the diff touches data models, function signatures, or domain types. TypeScript-centric, with mappings to Rust, Swift, Kotlin, and Haskell/OCaml.

Use when a backpressured loop needs to run benchmarks on a performance-sensitive project and decide whether a change is a regression, an improvement, or a wash — per-iteration sanity checks and the full pre-done run.

Reviews implementation plans during iterative backpressured development. Use when a backpressured loop's Phase 1 reviewer subagent is judging whether a lightweight implementation plan's approach/architecture is sound before any code is written — approving it or sending it back with approach-level concerns.

Use when a backpressured loop has a front-end/UI change and needs to compare the rendered result against its design reference (a Figma frame or images on a Linear ticket) — catching layout, spacing, contrast, and visual-consistency defects automated tests and happy-path clicking miss.

Use when a backpressured code-review subagent is reviewing a diff for correctness/logic, simplicity/reuse, or test-quality defects — everything except type design. The default reviewer dimension.