Flow-Next

Faster than your agent alone. And better.

Agents generate. Flow-Next proves.

Flow-Next is a workflow plugin for your coding agent. Hand it a bug, an idea, a ticket or a slow page, and it takes the work all the way to a pull request. It picks the route that kind of work needs, builds the change, gets it reviewed by another model family when the risk calls for it, and hands you something you can check instead of something you have to trust.

It's also fast now. On the same model, the working change comes back in about the time your agent takes on its own, often less, and a large feature in about half the time. The result is better than the plain agent's before any review runs, and review and live QA widen that gap.

You say	What Flow-Next does
"This fails: ``"	Turns the failure into a failing test, fixes the cause, and shows you the test going from red to green.
"Add passwordless login" (or the conversation you just had about it)	Writes a spec with numbered acceptance criteria, builds it, has it reviewed, and opens a PR that maps every change to a criterion when you ask for one.
"The /reports page takes four seconds, it should take under one"	Measures the real page before touching anything. The before-and-after numbers are the evidence.
"Extract the pricing rules into their own module"	Pins the current behaviour with a characterization test first, so the refactor has to keep it.
"Work ticket WOR-17"	Reads the issue with the access you already have and routes on what it says.
"Why does the parser reject empty headers?"	Answers from git history and the project's decision memory, with citations. Writes nothing.
/flow-next:flow --auto	The same thing with nobody watching. It never stops to ask, keeps fixing until the reviewer signs off, and writes every call it made on your behalf into the PR. Add --until=merge and it also watches CI and review threads and merges the PR when your checks allow it.

Every stage prints ran, skipped(<reason>) or failed(<reason>), so you can see what happened and what didn't. The model that wrote a diff never reviews it. Specs, decisions, task state and receipts live under .flow/ in your repository and stay readable if you stop using Flow-Next. flow --explain shows the route it would take, and why, without running it.

It runs on Claude Code, OpenAI Codex, Factory Droid, Cursor, xAI Grok Build and OpenCode.

📖 Documentation: flow-next.dev · 💬 Discord

---

How much faster, and how much better

I measured this over more than 170 full end-to-end runs against plain Claude Code on the same model, each case run several times. Hidden tests the agent never sees check every result, and a blind judge scores the handoff. Speed is time to the working change, before any review or QA.

Task	Speed on the work	Quality	What the quality stages did
Large feature	up to 1.9x faster	+25%	Plain Claude Code shipped a data-integrity bug in every run. Flow-Next's reviewers caught it every time, before the pull request.
Held-out large feature (Rust)	1.2x faster	+48%	Four real bugs fixed, including a race condition. Flow-Next passed every hidden test; plain Claude Code failed one run in three.
Hard bug	about 2x faster	+9%	Found the real cause and fixed it there, instead of loosening the flaky test.
Simple bug	1.2x faster	+10%	No review needed. The gain comes from how it works: a failing test first, a fix at the cause, then a check that it works for the user.
Small feature	1.1-1.3x faster	+8%	The reviewer caught a setup check the new option broke. Fixed before handoff.

Unattended, with --until=merge, a large feature went from spec to a merged pull request with nobody watching and no stops, in about half the time plain Claude Code took to build it. The evidence page has the method and the rest of the numbers.

---

Why this exists

Writing the code got cheap. Everything around it didn't: pinning down what was actually asked, keeping the build aligned with it, checking the result, and explaining the diff to whoever reviews it. That work is where agent-written code quietly goes wrong, and it's the part I wanted to make repeatable.

So the spec lives in .flow/specs/<id>.md instead of a chat that scrolls away. The build reads it before it touches code. When the risk calls for it, a model from another family checks the change, because a model reviewing its own work shares its own blind spots. And the PR shows which criterion each change satisfies and what proves it. It can't promise that the codebase stays easy to maintain. That still takes people who care about it.

---

Install

Claude Code OpenAI Codex Factory Droid

/plugin marketplace add \
  https://github.com/gmickel/flow-next
/plugin install flow-next
/reload-plugins
/flow-next:setup

git clone https://github.com/gmickel/flow-next.git
cd flow-next
./scripts/install-codex.sh flow-next
# For another Codex home (any path you like):
# CODEX_HOME="$HOME/.codex-work" ./scripts/install-codex.sh
# Run once per home.
# then, in your project's Codex conversation: $flow-next-setup

droid plugin marketplace add \
  https://github.com/gmickel/flow-next
# /plugins → install flow-next

Use installation commands in your terminal or the host's plugin interface as shown above. Workflow invocations belong in the agent conversation. Codex uses $flow-next-<name>; OpenCode uses /flow-next-<name>; the other hosts accept /flow-next:<name> (Cursor also accepts the hyphen form).

Cursor, Grok Build, or OpenCode? Install has the current steps per host, including the Cursor team-marketplace import and Clau