Flow-Next 工程流水线
把 AI 编程任务转为可审查的规格、任务、跨模型评审与完成凭据。
按维度查看评分与理由
证据显示：插件在本地运行，无外部服务，安装脚本是幂等的，且明确说明卸载是 rm -rf .flow/。用户确认方面，capture 有强制回读，setup 询问模式，qa 是 opt-in。数据流透明度：specs、receipts 等都在仓库中，可审查。敏感数据处理：未发现明确处理，但本地运行降低了风险。依赖安全：依赖较少，但未提供依赖审计。外部影响：主要影响本地仓库，有回滚机制（rollback-plan）。来源归属：有 SECURITY.md 和贡献指南。扣分：least_privilege 仅部分证据，未明确权限最小化；sensitive_data_handling 未明确说明如何处理敏感数据；dependency_security 未提供依赖漏洞扫描。
证据显示：README 和文档一致，有 CI 测试（3 OS），测试覆盖了 TUI 和 mock-codex 分类。依赖可用性：依赖较少，但未提供依赖锁定。失败消息：有 troubleshooting 文档。扣分：self_consistency 有部分不一致（如版本检查仅 plan 时），但整体一致；dependency_availability 未明确依赖版本锁定；failure_messages 有文档但未深入。
证据显示：面向企业和开发者，有 teams 指南，支持多种 harness（Claude Code, Codex, Droid, Cursor, Grok）。能力边界：有 running-lean 文档说明各层成本。触发精度：slash 命令和 plain language 等价。环境适配：支持多 OS，有平台矩阵。扣分：audience_and_scenarios 有广泛场景但未深入；capability_boundaries 有文档但未详尽；trigger_precision 有明确命令但未覆盖所有边缘；environment_fit 有矩阵但未覆盖所有版本。
证据显示：信息架构清晰，有 doc index。安装说明详细，有平台矩阵。命名稳定：命令和文件结构一致。示例和 FAQ：有 cookbook 和 troubleshooting。已知限制：有 running-lean 和 troubleshooting 提及。许可证：MIT。版本变更：有 release badge 但未提供 changelog。维护责任：有 SECURITY.md 和贡献指南。扣分：versioning_changelog 未提供明确 changelog 文件。
证据显示：输出可用性高，PR 有认知辅助，receipts 提供证据。边际价值：解决了 agent 漂移和审查瓶颈。成本效益：有 running-lean 文档说明成本。扣分：output_usability 有证据但未深入；marginal_value 有主张但未量化；cost_benefit 有文档但未量化。
证据显示：README 引用 SlopCodeBench 论文，有外部贡献者 PR 和 issue 引用。事实和推断分离：capture 有 [user]/[paraphrase]/[inferred] 标签。扣分：claim_traceability 有引用但未全部验证；cross_source_corroboration 有外部引用但未独立验证；fact_inference_separation 有标签但未全面。
- 发布者身份未验证，但这不是扣分理由。
- 静态审查，未执行代码，所有分数基于文件证据。
- 依赖安全未提供漏洞扫描，建议检查依赖。
- 版本变更记录不明确，建议查看 release 页面。
这个 Agent 能做什么，适合哪些场景？
Flow-Next 是面向软件工程团队的仓库内工作流插件，围绕 `.flow/` 中的规格、任务、记忆和凭据组织 AI 辅助开发。它将主机 AI 的推理能力与纯 Python 标准库 CLI `flowctl` 的确定性状态管理结合起来，而不是提供托管式控制台。核心流程可从 `/flow-next:capture` 生成规格，经过 `/flow-next:plan` 拆分任务和 `/flow-next:work` 实施，再用 `/flow-next:make-pr` 生成带验收项覆盖信息的 PR 正文。每个任务可在新的 worker 子代理上下文中执行，并由不同模型进行计划或实现评审；提交、测试和评审结论会作为证据记录。它提供 Claude Code、OpenAI Codex、Factory Droid、Cursor 与 Grok Build 的一等支持，并将项目状态保留在仓库内而非 SaaS 服务中。
/flow-next:capture 把对话或已有材料写入 .flow/specs/<id>.md，并为验收标准标记 [user]、[paraphrase] 或 [inferred] 来源。/flow-next:plan <spec-id> 调研代码库并生成依赖排序的 fn-N.M 任务，每项声明其满足的 R-ID。/flow-next:work <spec-id> 或任务 ID 会让 fresh-context worker 重新读取规格、任务和 Git 状态，随后实现、测试、提交并写入 evidence；plan-review 和 impl-review 可由另一模型反复审核至 SHIP。/flow-next:make-pr 从规格 R-ID、任务证据、记忆、术语表、策略、评审发现和 diff 等输入生成 PR 认知辅助正文；/flow-next:resolve-pr <PR#> 获取评论线程、分派处理、验证提交，并通过 GraphQL 回复和关闭线程。flowctl 还提供配置、规格就绪状态及 Ralph 自动化运行所需的磁盘凭据支持。
- 使用 Claude Code 的技术负责人，希望先把需求对话固化成可审查规格，再让代理按依赖顺序实施。
- 需要把大型改动拆为可在单个新上下文中完成的任务、并保留每项测试和提交证据的工程团队。
- 希望在人工审阅前获得第二模型计划审查和实现审查的 GitHub PR 团队。
- 在 Codex 与 Claude Code 等不同开发宿主之间协作、但希望规格和流程状态都留在同一代码仓库的团队。
- 准备夜间执行已完整规划的规格，并愿意使用 Ralph shell 循环、hook 和收据文件控制运行的团队。
这个 Agent 有哪些优点和局限？
- 以单个仓库内规格为核心，把验收项 R-ID、任务、提交、测试和 PR 覆盖关系连成可追溯链。
- 每项工作在重新锚定的全新子代理上下文中执行，并支持跨模型计划与实现审查至
SHIP。 make-pr会生成验收项覆盖表和“where to look”提示，降低人工审阅大型 diff 的定位成本。- 支持多种编码宿主，且
.flow/中的状态、凭据和文档可随 Git 一起审阅和迁移。
- 需要 Python 3.11+、
jq、GitHub CLI；PR 和审阅处理依赖 GitHub 工具链。 - 流程引入规格、任务、评审与凭据等显式产物，README 明确指出资深开发者早期可能感到流程摩擦。
- Codex 需运行安装脚本，因为其插件协议不会直接注册自定义
.tomlagents 或 hooks。 - Ralph 需要外部 shell 循环，且只适用于已完整规划的规格；Cursor 和 Grok Build 均明确未构建 Ralph 支持。
如何安装或部署这个 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-next随后运行 /flow-next:setup。Codex 安装脚本会将打包的 agents 与 hooks 合并到活动 Codex home 的 config.toml；脚本可重复运行。运行环境需要 Python 3.11+、jq 和 gh；Ralph TUI 另需 Bun。
如何使用这个 Agent？
完成 setup 后，可先执行 /flow-next:capture 从当前需求生成规格，再运行 /flow-next:plan <spec-id>，随后执行 /flow-next:work <spec-id>。完成实现后使用 /flow-next:make-pr <spec-id> 生成 PR 正文；需要处理审阅意见时运行 /flow-next:resolve-pr <PR#>。对于自主运行，先以 flowctl spec ready fn-12 标记已获准工作的规格，再在独立 clone 中运行 /flow-next:pilot 和 /flow-next:land 循环；Ralph 只面向已规划完成的规格。
这个 Agent 与同类方案有什么区别？
它不试图替代 Jira、Linear 等人类团队的任务系统：tracker-sync 将规格投影到追踪器，规格仍是事实来源。文档也将其单文件、可演进规格模式与 Kiro 式拆分 requirements.md、design.md、tasks.md 的方式区分开来。
常见问题
它是否需要托管服务？
.flow/ 下，并明确不提供托管 dashboard 或 SaaS 层。