Flow-Next

Agents generate. flow-next proves.

Implementation got cheap. Reviewing it, verifying it, and keeping a codebase coherent did not.

Flow-Next is a workflow plugin that runs inside your coding agent. Give it the change you want and the rules your project follows. It turns that intent into specs, implementation, review, and pull requests with evidence. Your specs, decisions, and task state live in your repository.

A real recorded run: plan, then cross-model plan review (catches a missing guard, fix, SHIP), then implement plus tests, then impl review SHIP, ending on the receipt. Nothing staged; every frame is live output.

_{The recording drives each tick with claude -p "..." (Claude Code's non-interactive / headless mode) so the whole run captures unattended. In normal use you type the prompt or the /flow-next:... command in your interactive session: same pipeline, same gates.}

📖 Doc index · 👥 Teams guide · 💬 Discord · Full documentation site: flow-next.dev

Why this exists

Generating a change is only part of the work. Someone still has to clarify the requirement, keep the implementation aligned with it, check the result, and explain the diff to a reviewer.

Flow-Next makes that work repeatable. A spec preserves intent beyond the chat. Focused workers reread it before implementing. Review and live QA examine the result, and the PR connects changes to their requirements and evidence. Start with one change, then adapt the same workflow to a team or an unattended backlog.

The pipeline proves the change does what was asked and records what it did; it does not prove the codebase stays maintainable. Plan review and the technical refine pass ask two structural questions while the change is still a plan (does it make the same edit twice, does it bend a dependency direction) and record the answer; measuring what happened to the code after the fact is separate, later work.

The evidence page covers the measured problem behind this approach, field use, and internal evaluations. One real change through review shows what the workflow produced in this repository.

What you get

Decide what to build, build it, and verify the result. Describe the workflow in plain language or invoke its skills directly. The host agent runs the process and adapts it to the work.

Everything reaches your queue already reviewed. Configured review checks the design or implementation and records its verdict; the work contract closes each task through flowctl done with its evidence JSON (commits, tests, PRs), which the receipt records. Review settings, completion-review policy and opt-in QA apply on both direct and planned routes.

Open a PR that already makes its argument. The pull request arrives explaining itself: which acceptance criterion each change satisfies, which decisions still need a human, what deliberately did not change.

Decide what to build before anyone builds it. An idea too big to write down gets charted one decision at a time; a conversation becomes a spec; a product owner and an engineer refine it in their own passes on one file.

Your team's context lives in the repo. A review correction becomes a lesson the next task can read. Specs, decisions, glossary, and memory stay in your repository, available to the next agent and your teammates.

Prove it in the running app, not by reading the source. Live QA drives the app the way a user would, from the spec's own criteria, and files what it finds with screenshots and a verdict you can audit.

Hand over as much as the receipts have earned. One dial from a supervised pair to a loop draining the backlog overnight. The gates do not change as you climb.

Choose the model for each job. Name a model per role once in your CLAUDE.md, or say it in the prompt for a single run. Whatever you pick, the model that wrote the diff never reviews it. The pipeline shape per item and the model per job are decided separately, and each decision prints its reason: orchestration.

A way of working, not a tool you bolt on. The same rails carry a solo developer on a Sunday and a fifty-person organisation on a rollout. The spec is the handover object, and it reads the same to product, engineering, and the next agent run.

Your process outlives your agent. The same specs, gates, receipts, and task state across harnesses. In a harness that can dispatch subagents, the same routing runs across models in-host with no bridge at all. Specs and task state live under .flow/, in Git and available for review. The files remain readable when you stop using Flow-Next.

Where it already runs

Flow-Next's ways of working are coached and run in enterprise engineering organisations worldwide, from CAD and construction software to proptech and education, across modern monorepos, hundred-repo microservice estates, and 30-year-old legacy stacks, on GitHub Enterprise, GitLab, and Jira. A 2-3 hour structured discovery interview reliably produces 8-11 implementation-ready specs with numbered acceptance criteria, boundaries, and task breakdowns; the edge cases surface in the interview instead of the sprint. Receipts, evidence JSON, and review gates are the audit trail enterprise adoption asks for: approval checkpoints and traceability are built in.

Try it on one change that crosses roles. Check whether the spec makes the intended behavior clear, the review catches a concrete defect, and the PR gives the next person enough evidence to decide. Use those handovers to judge which stages your team needs.

The open-source record is linkable, so it speaks in its own words: an outside contributor shipping a correct flowctl patch in PR #95, a feature in awesome-claude-code-workflows for plan-first workflows, Ralph autonomous mode, and receipt-based gating (#96),