Flow-Next

Flow-Next is a local plugin that moves coding agents from disposable chat sessions into a reproducible engineering workflow. It captures work as a durable spec, implements it with fresh-context workers, assigns independent roles to spec compliance and code-quality review, and stores test, QA, review, and PR outcomes as receipts. Project state lives in the repository under .flow/, so work can resume across sessions and agent handoffs. The plugin supports several coding hosts, but it inherits each host's file, shell, model, and GitHub permissions; teams should set clear automation limits, merge policy, and sensitive-repository boundaries before adoption.

Choose a host, pin a reviewed release, and install into a test repository. Run setup only to initialize project state, then verify specs, implementation, review, and the draft-PR boundary with a low-risk task. Do not enable Ralph automation or automatic merging during the first validation.

Help me install and minimally verify Flow-Next in an isolated test repository. Project: https://github.com/gmickel/flow-next. First read the README, platforms guide, install-codex.sh, SECURITY.md, and latest release. Confirm Python 3.11+ and, for Codex multi-agent roles, CLI 0.102.0+. Pin the version I specify; if I do not specify one, show me the latest release and exact commit before installation. Explain every write to CODEX_HOME and project .flow/ before running installation and setup. Verify only a documentation task through spec, implementation, independent review, test receipt, and draft PR. Do not enable Ralph, access a production repository or secrets, configure external trackers, use --until=merge, auto-merge, force-push, or expand gh permissions. Finish with all file and configuration changes, evidence, rollback steps, and still-unverified capabilities.

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

1. 1
   Pin a version and prepare the host

   Check Python, host version, and model access, then choose a reviewed Flow-Next tag. Add jq and least-privilege gh credentials only if PR work is needed.

2. 2
   Install and initialize a test repository

   Follow the host guide, run setup, and inspect changes under CODEX_HOME or the plugin directory and the repository's new .flow/ state.

3. 3
   Capture one low-risk spec

   Describe a small documentation task through flow or capture, then review its goals, acceptance criteria, and constraints before implementation.

4. 4
   Inspect reviews and receipts

   Confirm that spec review, code-quality review, tests, and human QA produce evidence and that failures return to a repair loop.

5. 5
   Stop at a draft PR for human judgment

   For the first run, create only a draft PR and inspect the diff, permissions, and Git state. Do not pass --until=merge until policy is proven.

Flow-Next's value is not another code-generation command; it turns specs, context isolation, independent review, and evidence receipts into a recoverable repository workflow. That is attractive for long tasks, multi-agent work, and disciplined PR delivery. The cost is more state, role calls, and tool authority, and workflow structure cannot replace project tests, security review, or branch protection. Version 6.0.0 turns the PR body into a reviewer briefing and narrows landing to one named PR per invocation. That is a clearer boundary, but automatic merge still belongs behind isolated validation and strong repository gates.