Small fix? Skip the ceremony.
/flow-next:plan fn-9 && /flow-next:work fn-9 ✓ Fewer stages, same contracts: the plan still gates the work, and done still demands evidence.
Repeatable agentic engineering
Agents generate.
flow-next proves.
Implementation got cheap. Reviewing it, verifying it, and keeping a codebase coherent did not.
Flow-Next holds agent work to a bar you set: a different model reviews every handover, and receipts back every claim of done. Hand the whole arc to a loop when you are ready.
$ /flow-next:plan fn-52 && /flow-next:work fn-52 specs/fn-52-quality-gates.md Ready ✓ Review gated Tasks 3 / 4 R-IDs 6 Receipts 2
Terminal
$ /flow-next:chart fn-52 # optional · when it is unclear
✓ 6 decisions resolved · briefing → capture
$ /flow-next:capture
✓ spec written · 6 R-IDs · source-tagged
$ /flow-next:plan fn-52
✓ sized 4 tasks for focused context
$ /flow-next:work fn-52
> Re-anchoring spec + task
+ Evidence recorded
$ /flow-next:impl-review fn-52
✓ verdict: SHIP · codex · cross-model
Receipt: .flow/review-receipts/fn-52.json
$ /flow-next:qa fn-52
✓ verdict: SHIP · live-app · 6/6 R-IDs
$ /flow-next:make-pr fn-52 && /flow-next:land
✓ PR opened with R-ID coverage
✓ merged · released · spec closed
$ ▌Review receipt
.flow/review-receipts/fn-52.json
- verdict
- SHIP
- reviewer
- codex · cross-model
- introduced
- 0
- pre-existing
- 2 · logged
- evidence
- commits + tests
evidence over narration
The measured problem
What happens on the twentieth change
SlopCodeBench puts 11 models through 93 sequential checkpoints. Each checkpoint spec fixes external behaviour and says nothing about internal structure, so every run inherits whatever the run before it left behind.
No model finishes a problem end to end. The best strict pass rate is 17.2%, falling to 0.5%. Structural erosion rises in 80% of runs and verbosity in 89.8%. Measured against 48 maintained human repositories, the gap widens at every iteration while the human numbers stay flat.
The cheap fix is a better prompt, and the authors test it. Quality-aware prompts cut initial verbosity by about a third, leave the rate of decay untouched, move no pass-rate subtype, and cost up to 48% more. Better instructions do not survive iteration.
The authors name one intervention they do not test: structural discipline enforced across checkpoints through tooling. That is a description of Flow-Next. Gates the agent cannot skip, a different model reviewing every handover, a receipt for every claim of done.
The answer
Bias towards verification.
Every stage leaves an artifact the next stage or a human can audit.- in-loopgreen baseline, then prove the change against the spec's own criteria
- impl-reviewstructured findings + verdict, bound to reviewed head
- flowctl donerefuses completion without evidence JSON
- qalive-app verdict; PASS by reading source is forbidden
- landmerges on evidence, never on agent narration
- make-prone grounded walkthrough across artifact, GitHub, and HTML
What you get
What changes when you run it.
Each card states the outcome. The line under it is the machinery that produces it.Ship more without lowering the bar.
Volume goes up and the standard holds. Nothing reaches your review queue that has not already been challenged and fixed.
✓ A different model reviews every plan and every implementation, the loop iterates until SHIP, and a task cannot be marked done without evidence JSON.
plan review SHIP
implementation NEEDS_WORK
fix + re-review SHIP
flowctl done evidence requiredReviews stop being where work waits.
Open the pull request and the argument is already made. Reviewers spend their attention on decisions instead of reconstructing the diff.
✓ The pull request arrives explaining itself: which acceptance criterion each change satisfies, which decisions still need a human, what deliberately did not change.
GitHub PR
WHY -> STEP -> KEPT -> VERIFY
proof: R-IDs + tests + reviewed head
human judgment: named decisionsYour team's context stops living in three people's heads.
The reasons behind the code sit next to the code. A new teammate, or the next agent run, starts from what the last one learned.
✓ Specs, decisions, glossary, and memory are files in your repository that the next run reads.
.flow/specs/ intent + criteria
.flow/memory/ lessons that stuck
GLOSSARY.md your domain wordsClimb to autonomy without a leap of faith.
Start with one task you watch from beside it. End with a loop draining the backlog overnight. You pick the rung, and you can step back down.
✓ One dial from a supervised pair to a loop draining the backlog overnight. The gates do not change as you climb.
/flow-next:work fn-12 you watch
/loop 10m /flow-next:pilot it ticks
./scripts/ralph/ralph.sh it runsSpend the expensive model where it earns its keep.
Buy quality on the steps that decide the outcome. Spend cheaply on the rest. Set it in config, or just ask for it in the prompt.
✓ Route any model to any role, by parameter or by sentence. Cost and quality become steering decisions.
plan -> the model you trust most
work -> the fast one
review -> a different familyYour process outlives your agent.
Change harness, change model, change vendor. The specs, the gates, and the record of what happened stay yours.
✓ The same specs, gates, receipts, and task state across harnesses. Everything in your repository, and nothing outside it.
Claude Code -> write the spec
Codex -> implement
Cursor -> review
same .flow/ state, every role
uninstall: rm -rf .flow/Flexibility
A menu, not a rail.
Decide what to build, build it, prove it shipped. Take the whole arc or one step of it, asked for in plain language or typed as the exact command. Every route keeps the same execution, evidence, and review contracts.Task Graph
fn-52-quality-gates ✓Spec · blessed
write-spec ✓Task
context-fit-plan ✓Task
worker-reanchor ✓Task
review-loop ●In review
make-pr-cognitive-aid …Handover · queued
Fit − 100% ＋ ⛶
Command Palette
◇ Chart a Decision Map /flow-next:chart ✎ Capture Spec /flow-next:capture ⊙ Plan Spec... /flow-next:plan fn-52 ⌘ Work Ready Task /flow-next:work fn-52 ▣ Impl Review /flow-next:impl-review ◎ Live-app QA /flow-next:qa fn-52 ⇄ Sync to Tracker /flow-next:tracker-sync ⚑ Land the PR /flow-next:land ∞ Pilot Tick /loop 10m /flow-next:pilotRecent Runs
SHIP fn-52-quality-gates
ADVANCED fn-61 · pilot
Loops
Bless it. Loop it. Ship it.
Your judgment lives in the spec. The pipeline runs on a loop.Pilot - the build loop
One tick moves one ready spec one step closer to a pull request, then reports a verdict your host's loop can act on.
/loop 10m /flow-next:pilot Land - the ship loop
Babysits the draft PRs the build loop opened: CI green, reviews converged, merged, released, per your project's own rules.
/loop 30m /flow-next:land Ralph - hardened harness Advanced
External shell loop for fully planned specs: fresh session per iteration, hook-enforced guardrails, receipts on disk. When the run outlasts a session.
./scripts/ralph/ralph.sh /loop 10m /flow-next:pilot --review=codex
tick 1 fn-61 · stage=plan ✓ 4 tasks, deps recorded PILOT_VERDICT=ADVANCED spec=fn-61 stage=plan tick 2 fn-61 · stage=plan-review ✓ verdict SHIP (round 1) PILOT_VERDICT=ADVANCED spec=fn-61 stage=plan-review tick 3 fn-61 · stage=work ✓ 4/4 tasks done · impl-review SHIP PILOT_VERDICT=ADVANCED spec=fn-61 stage=work tick 4 fn-61 · stage=make-pr ✓ draft PR #172 opened (gh-confirmed) PILOT_VERDICT=ADVANCED spec=fn-61 stage=make-pr tick 5 PILOT_VERDICT=NO_WORK spec=- stage=- backlog drained, bless more on the board
Signal
Where it already runs.
Flow-Next runs inside enterprise engineering organisations worldwide: CAD and construction software, proptech, education. Modern monorepos and hundred-repo microservice estates sit alongside thirty-year-old legacy stacks. GitHub Enterprise, GitLab, Jira. Windows included, because the field runs Windows.
A two to three hour structured discovery interview reliably produces eight to eleven implementation-ready specs. Product and engineering leads report a clear efficiency gain, and edge cases caught during spec review that the team would otherwise have met in production.
Adoption is not uniformly euphoric, and pretending otherwise would cost this page its credibility. The consistent pattern: product and delivery roles feel relief early - specs they can read, evidence they can audit, progress they can see. Senior developers feel friction early - the pipeline formalizes judgment they already exercise implicitly, and the ceremony reads as overhead until the first review gate catches something they would have missed. The friction fades with the first caught regression; the relief does not.
- 669 stars
- 52 forks
- 8 contributors
- CI on Linux, macOS and Windows every push
- Featured in awesome-claude-code-workflows
- External contributors shipping flowctl patches
“I am enjoying your version of all these cool new plugins. So far yours has worked the best.”
“Hello, really enjoying this project, thanks for making it and making it public (also huge compliments on your website!)”
“it’s been really useful in my workflow.”
Pick your path
Start where you are.
Three routes in, one set of gates. Every one of them ends at a reviewed pull request.You are solo and want to feel it today.
/flow-next:setup ✓ One small change from idea to reviewed pull request, with the output you should expect at every step.
Your first 30 minutes →Your team is adopting it together.
/flow-next:interview fn-3 ✓ The spec becomes the shared artifact: product fills intent, engineering fills constraints, reviewers read one handover.
How teams run it →Your organisation is rolling it out.
managed-settings.json ✓ Deploy it once through Claude Code managed settings and every developer has it on next launch, with no per-person install.
Org-wide deployment →Not sure which applies? Ask /flow-next:guide - it names the smallest sufficient route for where you actually are, including when to skip a stage entirely. Or read When to use.
Updates
Notable updates
The changes that alter how you work. Latest release first, with setup only when needed.Review verdicts you can audit, not just believe
A resumed reviewer session could answer from its previous round's context in about a kilobyte with zero tool calls, asserting measured facts that happened to be true - and the verdict text looked identical to a real review. Every attempt row now records how its verdict was produced: output size, the tool calls it actually made where that could be measured, and exactly which commits it judged.
-
3.23.0 Status answers say where they came from
A status read that answered from a stale snapshot looked exactly like a right answer - a review sandbox once burned three review rounds arguing with a spec that was already done. Status output now names its source (authoritative store vs committed snapshot), the pre-work commands warn once when your checkout is behind upstream, and reviewers are told task lifecycle is never theirs to judge from committed files.
-
3.22.0 Handovers point at the work, not a retelling
A finishing agent used to narrate what it had just done to whoever picked the work up next - a second copy of the story that aged the moment anything moved. Handovers now carry pointers: the task, its status, where the summary and evidence live, what changed, and the verdict, so the next reader opens the files that are the current truth.
-
3.21.0 Nits stop crowding out defects
One reviewer reading your whole change had one pool of attention, and naming conventions are easier to spot than a requirement quietly implemented wrong. The audit now runs two reviewers at once with separate jobs - one asks only whether the code does what the spec said, the other only whether it is code worth keeping - and both reports come back in full, side by side.
☆ New to Flow-Next? Get your first spec planned, worked, reviewed, and handed off.