Help us improve
Share bugs, ideas, or general feedback.
From backpressured
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.
npx claudepluginhub lucasfcosta/backpressured --plugin backpressuredHow this skill is triggered — by the user, by Claude, or both
Slash command
/backpressured:goalThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**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.
Enforces a gated Spec → Plan → Build → Test → Review → Ship lifecycle for multi-file features and projects, preventing AI coding agents from skipping specification and verification steps.
Auto-loop execution workflow with quality gates. Use when starting any non-trivial implementation task. Provides automatic task decomposition, code implementation, testing (L1-L4), and iterative quality gates until completion. Invoke with /autoworker.
Orchestrates implement-analyze-fix loops: implements code, AI-reviews changes, fixes issues, repeats until clean or max iterations. For iterative development with quality checks.
Share bugs, ideas, or general feedback.
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.
/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.
"Done" is defined by criteria, so make them explicit before anything else:
BACKPRESSURE.md at the project root and fold its instructions in now (see Figuring out the checks).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"];
}
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.
After each patch, before writing the next one, run the checks that apply to this project:
reviewer subagent on the diffRun 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.
Automated green is necessary, not sufficient. Once all criteria appear met, in this order:
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.reviewer subagent over the whole changeset, not just the last patch.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.
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).
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.
Two inputs decide what runs:
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.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.
| 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 |
| 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. |
BACKPRESSURE.mdAll of these mean: you are about to become the human backpressure you are supposed to replace. Get back in the loop.