Rivet Actors 中的 OpenSpec Fast-Forward 工作流用/opsx-ff一次性生成全部实现产物【免费下载链接】actorsRivet Actors are the primitive for stateful workloads. Built for AI agents, collaborative apps, and durable execution.项目地址: https://gitcode.com/GitHub_Trending/riv/actors导读/opsx-ff是 Rivet Actors 仓库.opencode/command/opsx-ff.md中为 AI 编码 Agent 设计的一条 OpenSpec 命令它把创建变更、逐个撰写 proposal、spec、design、tasks 等 artifact的多轮交互压缩为一次快进式Fast-Forward批量生成让 Agent 一次性地把所有实现所需产物全部产出随后直接进入编码阶段。读完本文你将掌握/opsx-ff的完整执行协议——从输入解析、openspecCLI 命令调用、JSON 状态解读到 artifact 的依赖顺序创建与护栏约束并理解它与/opsx-new、/opsx-continue、/opsx-apply等命令在整个 OpenSpec 变更生命周期中的衔接关系。OpenSpec 与 OPSX 命令族/opsx-ff的定位Rivet Actors 仓库在.opencode/command/目录下维护了一组以opsx为前缀的 Agent 命令它们共同构成一套实验性 artifact 驱动变更工作流experimental artifact workflow。其底层由openspecCLI 驱动变更change被组织为openspec/changes/name/目录内部包含 proposal、specs、design、tasks 等按 schema 定义的 artifacts。从.opencode/command/目录可以看到完整命令族命令作用opsx-new.md启动一个新变更展示首个 artifact 模板后停止opsx-continue.md逐个创建下一个 artifact每次只建一个opsx-ff.md快进一次性创建所有实现所需 artifactsopsx-explore.md探索模式思考问题、澄清需求但不实现opsx-apply.md根据 tasks artifact 实施编码opsx-verify.md归档前核对实现与 artifacts 的一致性opsx-sync.md将 delta specs 同步到主 specsopsx-archive.md归档已完成的变更opsx-bulk-archive.md批量归档多个变更并智能解决 spec 冲突opsx-onboard.md引导式教学带用户走完完整工作流周期/opsx-ff是其中唯一一条一次调用、批量产出的命令其定位介于/opsx-new只建变更目录与/opsx-continue一次一个 artifact之间它自动完成/opsx-continue需要多次重复的全部循环。仓库还提供了等价的 skill 描述 openspec-ff-change/SKILL.md两者协议一致可互为印证。一、输入处理没有输入就先问清楚/opsx-ff的参数有两种合法形式变更名称kebab-case例如add-user-auth用户对要构建内容的自然语言描述Agent 需据此推导出 kebab-case 名称例如add user authentication →add-user-auth。如果调用时没有提供任何输入Agent 必须使用AskUserQuestion 工具开放式提问不预设选项向用户询问What change do you want to work on? Describe what you want to build or fix.文档对此给出的约束非常强硬在没有理解用户想构建什么之前不得继续执行Do NOT proceed without understanding what the user wants to build。这一点与/opsx-new的输入协议完全一致见 opsx-new.md是整个命令族共用的第一道关卡。二、创建变更目录openspec new change确认变更意图后第一步是执行openspec new change name该命令会在openspec/changes/name/下创建变更脚手架。默认使用 schema省略--schema除非用户显式要求其他工作流。从 opsx-new.md 可以补充两点相关约定仅当用户提及具体 schema 名称如show workflows时才运行openspec schemas --json让用户选择并以--schema name传入若同名变更已存在应询问用户是继续该变更走/opsx-continue还是新建。三、获取构建顺序openspec status --change --json创建脚手架后运行openspec status --change name --json解析返回的 JSON重点关注两个字段applyRequires实现开始前必须完成的 artifact ID 数组例如[tasks]。这是/opsx-ff的停止条件——只生成applyRequires覆盖的产物而非 schema 定义的全部可选产物artifacts所有 artifact 的列表含各自的statusdone/ready/blocked与依赖关系。artifacts中status: ready表示该 artifact 的前置依赖已满足、可以创建blocked表示仍有未满足的依赖。/opsx-ff的核心循环就是反复消费ready状态的 artifact直到applyRequires中每一项都变为done。四、核心循环按依赖顺序批量创建 artifacts4.1 用 TodoWrite 跟踪进度开始循环前先用TodoWrite 工具登记待创建的 artifacts使多步批量操作对用户可见、可追踪。4.2 获取单个 artifact 的指令对于每个status: ready的 artifact执行openspec instructions artifact-id --change name --json返回的 instructions JSON 包含六个关键字段字段含义Agent 的使用方式context项目背景仅作为约束参考不得写入输出文件rulesartifact 专属规则仅作为约束参考不得写入输出文件template输出文件应遵循的结构作为文件骨架直接套用instruction该 artifact 类型的 schema 级指导决定每个 artifact 的具体内容outputPathartifact 文件的写入位置按此路径落盘dependencies需要先读取的已完成 artifact写文件前必须通读以获取上下文一个关键的纪律是context与rules是写给 Agent 的约束而不是文件内容。openspec-ff-changeskill 对此特别强调不要将context、rules、project_context块复制进 artifact——它们指导你写什么但绝不应出现在输出中见 openspec-ff-change/SKILL.md。4.3 写 artifact先读依赖再按模板落盘每个 artifact 的创建流程读取dependencies中列出的已完成 artifact 文件获取上下文以template为结构骨架结合instruction的专项指导填充内容应用context和rules作为约束但不复制它们到文件向outputPath写入文件输出简短进度✓ Created artifact-id。以 spec-driven schema 为例/opsx-ff在默认 schema 下会生成proposal.md回答 Why / What Changes / Capabilities / Impact其中 Capabilities 部分至关重要——每个 capability 都会对应一个specs/capability/spec.mddesign.md记录技术决策、架构与实现方案tasks.md将实现拆解为可勾选的清单- [ ]条目。这是/opsx-continue中描述的同一套 artifact 模式见 opsx-continue.md区别仅在于/opsx-ff一次跑完整个序列。4.4 每步复查状态直到 apply-ready创建完一个 artifact 后重新运行openspec status --change name --json检查applyRequires数组中的每个 artifact ID 在artifacts数组中是否都已status: done未全部完成 → 继续消费下一个readyartifact全部完成 → 立即停止循环不需要生成 schema 定义的全部 artifacts。4.5 循环中的用户介入点如果某个 artifact 的上下文严重不清晰例如 proposal 的 Capabilities 无法从用户描述中推导应使用AskUserQuestion 工具澄清然后继续创建。文档同时给出倾向性指引在上下文关键处不明确时才问其余情况优先做出合理决策以保持节奏prefer making reasonable decisions to keep momentum。五、收尾展示最终状态与交接给实施阶段所有applyRequires产物完成后运行人类可读的状态展示openspec status --change name随后向用户输出一段结构化总结必须包含四部分变更名称与位置openspec/changes/name/已创建的 artifacts 清单每个附一句简述就绪声明All artifacts created! Ready for implementation.下一步提示Run/opsx-applyto start implementing.最后一条提示将工作流无缝衔接到实施阶段/opsx-apply会读取openspec status --json确定 schema运行openspec instructions apply --change name --json获取任务列表与上下文文件然后逐项勾选完成任务见 opsx-apply.md。实现完成后还可以继续走/opsx-verify核对、/opsx-sync同步 delta specs、/opsx-archive归档的后续链路。六、Artifact 创建准则Artifact Creation Guidelines批量创建时需遵循以下准则它们保证了产物质量与依赖一致性严格遵循instruction字段每个 artifact 类型的 schema 决定了它应包含什么按 schema 填写先读依赖再创建写新 artifact 前必须通读其依赖 artifacts确保上下文连贯以template为起点将模板作为结构起点基于上下文填充而非从零编写约束与内容分离context、rules用于指导写作不得混入产物文件本身。七、护栏Guardrails快进不等于草率/opsx-ff在追求速度的同时也设置了六条硬性护栏创建全部实现所需 artifacts以 schema 的apply.requires为准缺一不可总是先读依赖再创建禁止跳过上下文直接产出关键歧义才提问上下文严重不清时询问用户但优先自主决策以保持推进同名变更先确认若同名变更已存在询问用户是继续它还是新建写后校验每个 artifact 写入后必须验证文件确实存在再进入下一个Verify each artifact file exists after writing before proceeding to next。最后一条写后校验与openspec-ff-changeskill 中的表述一脉相承它把文件落盘从假设变为可验证事实是批量流程可靠性的一道重要防线。八、快速参考/opsx-ff完整命令序列# 1. 创建变更目录 openspec new change name # 2. 读取构建顺序applyRequires artifacts 状态 openspec status --change name --json # 3. 循环对每个 statusready 的 artifact openspec instructions artifact-id --change name --json # 读取 dependencies → 按 template 填充 → 写入 outputPath → 校验文件存在 # 4. 重复第 2 步直至 applyRequires 全部 done然后 openspec status --change name结语/opsx-ff是 Rivet Actors 仓库 OpenSpec 工作流中提速与保真之间的平衡点它通过一次调用完成 artifact 批量化创建把 AI Agent 从逐 artifact 交互中解放出来同时用applyRequires停止条件、依赖顺序循环、写后校验和约束-内容分离等机制守住文档质量底线。理解它的执行协议就掌握了在该仓库中从一句话需求到可实施任务清单的最短路径而它与/opsx-new、/opsx-continue、/opsx-apply、/opsx-verify、/opsx-archive构成的完整生命周期正是这套实验性工作流在真实项目中的落地形态。【免费下载链接】actorsRivet Actors are the primitive for stateful workloads. Built for AI agents, collaborative apps, and durable execution.项目地址: https://gitcode.com/GitHub_Trending/riv/actors创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
