Flow-Next Engineering Pipeline
A repository-native workflow for turning AI coding work into reviewed specs, tasks, and evidence-backed delivery.
- Source repo
- gmickel/flow-next
- Stars
- ★ 718
- Last updated
- today
- License
- MIT
- Primary language
- Python
- FA score
- 62/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A Claude Code tech lead who wants to convert a requirements conversation into a reviewable specification before implementation begins.
- Not a fit if
- Teams standardized on one coding agent and unwilling to maintain multi-harness configs
- Teams that need a hosted dashboard or SaaS control plane
- Developers who want agents to code freely without specs or review gates
- Source review
- 62/100 · Some gaps
What does this agent do, and when should you use it?
Flow-Next is a repository-native engineering workflow plugin that keeps specs, tasks, memory, and receipts under .flow/. It pairs host-agent reasoning with flowctl, a bundled pure-standard-library Python CLI, rather than a hosted control plane. Its main path captures a durable spec, plans dependency-ordered tasks, runs implementation, and produces a PR-oriented review artifact. Workers can start each task with fresh context and re-read the spec, task, and Git state before making changes; plan and implementation reviews can use a different model. The repository documents first-class support for Claude Code, OpenAI Codex, Factory Droid, Cursor, and Grok Build, with project artifacts remaining in Git.
/flow-next:capture writes a conversation or briefing into .flow/specs/<id>.md and source-tags acceptance criteria as [user], [paraphrase], or [inferred]. /flow-next:plan <spec-id> investigates the codebase and creates dependency-ordered fn-N.M tasks that declare the R-IDs they satisfy. /flow-next:work <spec-id> or a task ID launches fresh-context workers that re-anchor on the spec, task, and Git state, then implement, test, commit, and record evidence; plan-review and impl-review can iterate with another model until SHIP. /flow-next:make-pr renders a PR body from R-IDs, task evidence, memory, glossary and strategy changes, deferred findings, and the diff. /flow-next:resolve-pr <PR#> fetches review material, dispatches resolution work, validates commits, and replies to and resolves threads through GraphQL. flowctl also manages configuration, readiness state, and disk-backed receipts used by autonomous Ralph runs.
- A Claude Code tech lead who wants to convert a requirements conversation into a reviewable specification before implementation begins.
- An engineering team breaking a broad change into context-sized tasks while preserving the commit and test evidence for every task.
- A GitHub-based team that wants a second model to review both the implementation plan and completed implementation before human PR review.
- A mixed Codex and Claude Code team that needs workflow state and specifications to travel with the repository rather than live in one vendor workspace.
- A team running fully planned work overnight with Ralph shell loops, hooks, and on-disk receipts.
How do you install or deploy this agent?
Claude Code:
/plugin marketplace add https://github.com/gmickel/flow-next
/plugin install flow-next
/reload-plugins
/flow-next:setupOpenAI Codex:
git clone https://github.com/gmickel/flow-next.git
cd flow-next
./scripts/install-codex.sh flow-nextThen run /flow-next:setup. The Codex installer merges bundled agents and hooks into the active Codex home’s config.toml and is documented as idempotent. Requirements are Python 3.11+, jq, and gh; Bun is optional for the Ralph TUI.
How do you use this agent?
After setup, run /flow-next:capture to create a spec from the current requirement, then /flow-next:plan <spec-id> and /flow-next:work <spec-id>. Use /flow-next:make-pr <spec-id> to create the PR review body, and /flow-next:resolve-pr <PR#> to process review feedback. For autonomous operation, mark approved work with flowctl spec ready fn-12, then run /flow-next:pilot and /flow-next:land loops in separate clones. Ralph is intended only for fully planned specs.
What are this agent's strengths and limitations?
- Uses a single durable repository spec and traces acceptance R-IDs through tasks, commits, tests, and PR coverage.
- Fresh-context workers re-anchor before every task, while cross-model plan and implementation reviews provide an explicit second opinion.
make-prproduces an R-ID coverage table and a focused review guide instead of leaving reviewers with an unexplained large diff.- Supports several coding hosts while keeping workflow state, receipts, and documentation reviewable in Git.
- Requires Python 3.11+,
jq, and GitHub CLI; PR and review-resolution functions depend on GitHub tooling. - The workflow adds explicit specs, tasks, gates, and receipts; the documentation notes that experienced developers may initially perceive this as friction.
- Codex requires an installation script because its plugin protocol does not directly register the custom
.tomlagents or hooks. - Ralph requires an external shell loop and only handles fully planned specs; it is intentionally not built for Cursor or Grok Build.
How does this agent compare with similar options?
It is not positioned as a Jira or Linear replacement: tracker-sync projects specs to a tracker while the spec remains the source of truth. The documentation also contrasts its one evolving spec document with Kiro-style split requirements.md, design.md, and tasks.md files.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Flow-Next Engineering Pipeline This agent | 62 · Some gaps | Agent plugin / skillFree + model costs | ★ 718 | today | Python | Codex · Claude Code |
| Agent Skills — Production-Grade Engineering Skills for AI Agents | 71 · Some gaps | CLIFree + model costs | ★ 114k | 5d ago | JavaScript | Codex · Claude Code · OpenAI API |
| Loki Mode | 57 · Major gaps | CLIFree + model costs | ★ 1.1k | today | Shell | Claude Code · Claude API |
| Pilot Shell | 53 · Major gaps | CLIPaid | ★ 2.1k | 1d ago | Shell | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: plugin runs locally, no external services, install script is idempotent, and uninstall is rm -rf .flow/. User confirmation: capture has mandatory read-back, setup asks mode, qa is opt-in. Data flow transparency: specs, receipts etc. are in repo, reviewable. Sensitive data handling: no explicit handling found, but local run reduces risk. Dependency security: few dependencies, but no audit. External effects: mainly local repo, has rollback mechanism. Source attribution: has SECURITY.md and contributing guide. Deductions: least_privilege only partial evidence, no explicit least privilege; sensitive_data_handling not explicit; dependency_security no vulnerability scanning.
Evidence shows: README and docs consistent, CI tests (3 OS), tests cover TUI and mock-codex classification. Dependency availability: few dependencies, but no lock file. Failure messages: troubleshooting doc. Deductions: self_consistency has minor inconsistencies (version check only at plan), but overall consistent; dependency_availability no explicit version pinning; failure_messages documented but not deep.
Evidence shows: targets enterprises and developers, teams guide, supports multiple harnesses (Claude Code, Codex, Droid, Cursor, Grok). Capability boundaries: running-lean doc prices each layer. Trigger precision: slash commands and plain language equivalent. Environment fit: multi-OS, platform matrix. Deductions: audience_and_scenarios broad but not deep; capability_boundaries documented but not exhaustive; trigger_precision clear but not all edges; environment_fit matrix but not all versions.
Evidence shows: clear information architecture, doc index. Install notes detailed, platform matrix. Naming stable: commands and file structure consistent. Examples and FAQ: cookbook and troubleshooting. Known limitations: running-lean and troubleshooting mention. License: MIT. Versioning: release badge but no changelog. Maintenance responsibility: SECURITY.md and contributing guide. Deductions: versioning_changelog no explicit changelog file.
Evidence shows: output usability high, PR cognitive aid, receipts provide evidence. Marginal value: addresses agent drift and review bottleneck. Cost benefit: running-lean doc prices. Deductions: output_usability evidence but not deep; marginal_value asserted but not quantified; cost_benefit documented but not quantified.
Evidence shows: README cites SlopCodeBench paper, external contributor PR and issue references. Fact/inference separation: capture has [user]/[paraphrase]/[inferred] tags. Deductions: claim_traceability has references but not all verified; cross_source_corroboration has external references but not independently verified; fact_inference_separation has tags but not comprehensive.
- Publisher identity unverified, but not a deduction by itself.
- Static review, no execution, scores based on file evidence.
- Dependency security lacks vulnerability scanning, recommend checking dependencies.
- Versioning/changelog unclear, recommend checking release page.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
flow-next-v9.8.0 flow-next v9.8.0
Release notes excerpt
Flow now builds a ready spec directly unless you ask for a plan. A spec that spans two repositories, is expected to ship in several PRs or names separate owning teams runs as one task with the same review and QA gates, and that task can still open several PRs. On a pre-registered routing test (Opus 5.5, three runs per case), 9.7.0 sent a two-repo, a three-PR and a two-team spec to planning every time; 9.8.0 sent none of them, and every explicit ask still reached planning. …View on GitHub ↗ -
flow-next-v9.7.0 flow-next v9.7.0
Release notes excerpt
Specs that depend on each other in a loop are now caught when the loop is closed. Before, they just never became ready. Teams that cut an epic into one spec per story see the full path the moment a dependency closes a circle, a split whose dependencies loop is shown before anything is written, and /flow-next:deps says why each stuck spec can never start. Nothing to configure. Added …View on GitHub ↗ -
flow-next-v9.6.0 flow-next v9.6.0
Release notes excerpt
GitLab teams can now take a spec all the way to a merged merge request. make-pr opens or updates the merge request, resolve-pr works through its review discussions, and land squash-merges it once the pipeline for its current head has passed and GitLab's own merge check allows it, so flow --auto --until=merge runs the whole loop on gitlab.com or a self-managed instance. A merged merge request moves the tracker issue to Done the way a merged pull request does. Teams that keep the spec as the only record can also make the tracker issue body follow the spec. …View on GitHub ↗
FAQ
Does Flow-Next require a hosted service?
.flow/ and explicitly does not offer a hosted dashboard or SaaS tier.