OPSX Fast Forward 工作流详解/opsx:ff 命令如何一键生成 OpenSpec 变更制品【免费下载链接】actorsRivet Actors are the primitive for stateful workloads. Built for AI agents, collaborative apps, and durable execution.项目地址: https://gitcode.com/GitHub_Trending/riv/actors导读本文以 Rivet Actors 仓库中的 .claude/commands/opsx/ff.md 为核心系统拆解/opsx:ffOPSX Fast Forward命令的输入语义、五步执行流程、制品依赖编排机制与护栏约束并结合.claude/commands/opsx/命令家族与.opencode/skills/下的对应 Skill还原一条从「新建变更」到「验证归档」的完整规格驱动spec-driven开发链路。读完你既能直接上手使用该命令也能理解 OpenSpec 制品流水线在 AI Agent 协作场景下的底层设计。一、OPSX 与 Fast Forward 的定位/opsx:ff是 Rivet Actors 仓库内置的 AI 工作流命令之一定义在 .claude/commands/opsx/ff.md。其 frontmatter 声明如下字段值nameOPSX: Fast ForwarddescriptionCreate a change and generate all artifacts needed for implementation in one gocategoryWorkflowtags[workflow, artifacts, experimental]其中 OPSX 指OpenSpec eXperimental实验性的制品驱动工作流ff即Fast Forward快进它把通常需要多轮交互逐个创建的制品生成过程压缩成一次执行——一次性生成从零到「可以动手实现」所需的全部制品。在该仓库中这一能力同时存在两套等价形态Claude Code 命令.claude/commands/opsx/ff.md本文主体OpenCode Skill.opencode/skills/openspec-ff-change/SKILL.md同一流程的 Skill 版元数据标注license: MIT、generatedBy: 1.1.1、compatibility: Requires openspec CLI。两者的步骤、输出与护栏完全一致本文以 Claude Code 命令版为准逐层展开。二、命令的输入语义变更名还是需求描述/opsx:ff接受两种输入形式语义如下变更名kebab-case例如/opsx:ff add-user-auth自然语言描述例如/opsx:ff 我想加一个用户认证功能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。这一步是后续所有制品质量的前提——制品内容高度依赖对变更意图的准确捕获。三、五步执行流程逐层拆解ff.md将整个快进过程编排为 5 个步骤下面逐一展开并说明其背后的机制。第 1 步澄清需求并派生变更名同「输入语义」一节无输入时先提问再根据回答派生 kebab-case 变更名。这一步产出的是后续所有命令的name参数。第 2 步创建变更目录openspec new change name该命令会在openspec/changes/name/下创建一个脚手架变更目录scaffolded change。这是 OpenSpec CLI 提供的核心命令也是整个 OPSX 工作流的数据起点——所有后续制品都写入这个目录中。第 3 步获取制品构建顺序openspec status --change name --json解析 JSON 输出可以得到两个关键结构字段含义示例applyRequires进入实现阶段apply之前必须完成的制品 ID 数组[tasks]artifacts全部制品的清单包含各自的状态与依赖关系各制品的status、dependenciesartifacts数组中的每个制品都有一个状态构成整个流水线的调度依据详见下一节的状态机。这一步回答的核心问题是该 schema 下需要创建哪些制品、它们之间的依赖顺序是什么、做到哪一步才能开始写代码。第 4 步按依赖顺序循环创建制品核心循环这是ff与new、continue最本质的区别所在。new只搭脚手架便停手continue每次只创建一个制品而ff用一个循环把 apply-ready 之前的所有制品一次跑完使用TodoWrite 工具登记制品进度按依赖顺序遍历制品无待决依赖的制品优先对每个状态为ready依赖已满足的制品拉取生成指令openspec instructions artifact-id --change name --jsonopenspec instructions返回的 JSON 是制品的生成配方包含 6 个关键字段字段作用使用方式context项目背景作为 Agent 的约束不写入输出文件rules制品专属规则作为 Agent 的约束不写入输出文件template输出文件应遵循的结构作为文件骨架直接使用instruction该制品类型的 schema 级指导决定制品内容的写法outputPath制品应写入的位置落盘路径dependencies已完成、需先阅读的制品创建前必须读取以获取上下文拿到指令后Agent 的执行顺序是先读取dependencies中列出的已完成制品→ 以template为结构 → 在context与rules的约束下填充内容 → 写入outputPath并输出简短进度✓ Created artifact-id循环终止条件每创建完一个制品重新执行openspec status --change name --json检查applyRequires中的每个制品 ID 在artifacts数组中是否都已status: done。全部完成即停止不贪多。循环中的分支处理如果某个制品因上下文不清晰而需要用户输入则使用AskUserQuestion 工具澄清后继续创建。第 5 步展示最终状态openspec status --change name以人类可读格式收尾向用户汇报整个变更的制品完成情况。四、制品状态机与依赖编排将第 3、4 步的机制抽象出来OPSX 制品流水线本质是一个依赖驱动的有向无环图调度┌──────────┐ │ blocked │ 依赖未满足等待上游制品完成 └──────────┘ │ 依赖全部完成 ▼ ┌──────────┐ │ ready │ 可以取指令并生成 └──────────┘ │ 文件落盘 ▼ ┌──────────┐ │ done │ 制品完成解锁下游 └──────────┘关键设计点只处理ready制品每次迭代优先选取无待决依赖的制品天然保证了拓扑序每步都回读 status创建后重新查询状态是唯一的进度事实来源避免 Agent 凭记忆推进以applyRequires为终点done状态只在applyRequires全覆盖时才触发循环退出既不会漏制品也不会越界生成实现阶段才需要的东西。以continue.md中记录的spec-driven schema为例典型制品序列为proposal.md → specs/capability/spec.md → design.md → tasks.md其中tasks.md勾选式任务清单通常就是applyRequires里的最后一块拼图。ff会把这条链路一次走完而tasks.md里的- [ ]复选框正是下一阶段apply的消费对象见第六节。五、制品内容边界template 与约束的分离ff.md在「Artifact Creation Guidelines」中明确了生成内容时的三条纪律遵循instruction字段每个制品类型由 schema 定义其应包含的内容instruction是权威指南先读依赖制品创建新制品前必须读取其依赖制品保证上下文连贯、术语一致template 只是起点以template为骨架结合上下文填充而非照抄模板原文。特别值得注意的是约束与内容的严格分离context、rules是写给Agent写作者的约束指导「怎么写」但绝不能作为内容粘贴进制品文件。这是 OPSX 保证制品文件干净、可被后续apply/verify直接消费的关键约定。六、收尾输出与交接格式所有制品创建完成后Agent 需要输出结构化摘要ff.md规定的要素如下变更名与位置如add-user-authopenspec/changes/add-user-auth/制品清单逐个列出已创建的制品及一句话描述就绪声明All artifacts created! Ready for implementation.交接提示提示用户运行/opsx:apply开始实现OpenCode 版对应提示为/opsx-apply。七、护栏Guardrails逐条解读ff.md定义了 5 条护栏约束 Agent 在快进过程中的行为边界护栏意图创建 schema 的apply.requires定义的全部制品防止少建导致实现阶段缺上下文创建新制品前总是先读依赖制品保证制品间的信息传递不丢失上下文严重不清时提问但优先做合理决策以保持节奏在「准确」与「效率」之间取平衡同名变更已存在时询问是继续还是新建避免目录冲突与内容覆盖写入后校验制品文件确实存在再进入下一步防止静默写盘失败污染状态机这些护栏共同塑造了ff的快而不莽它能一口气跑完整个制品流水线但在需求不明、命名冲突、写盘失败等关键节点会主动停下确认。八、与 OPSX 命令家族串联从新建到归档的完整生命周期ff不是孤立命令。在 .claude/commands/opsx/ 下共有 10 个命令构成完整的 OPSX 生命周期命令阶段职责关键行为/opsx:explore探索只思考不实现想法成熟后引导进入new/ff/opsx:new启动搭脚手架、展示首个制品模板创建 0 个制品/opsx:ff本文启动快进一次性生成全部applyRequires制品/opsx:continue推进每次只创建下一个ready制品/opsx:apply实现消费tasks制品逐项勾选- [ ] → - [x]/opsx:verify验证按 Completeness / Correctness / Coherence 三维度出报告CRITICAL / WARNING / SUGGESTION/opsx:archive归档实现验证通过后归档变更/opsx:bulk-archive批量归档一次归档多个已完成变更/opsx:sync同步将变更的 delta specs 同步回主规格/opsx:onboard接入引导新项目初始化 OPSX 环境典型的端到端链路为explore → new / ff → continue → apply → verify → archive / syncff在这条链路上承担「启动阶段的高吞吐路径」当用户对变更已经有清晰想法、不想一步步等待制品逐个创建时用ff一步到位而当变更需要边做边想、分阶段确认时new 多次continue才是更稳妥的选择。apply阶段还会根据实现进展反向建议更新制品apply.md 中称为 Fluid Workflow Integration说明整个模型是可回流的而非僵化的线性流水线。九、在 Rivet Actors 仓库中的落地形态与前置条件从仓库结构可以确认OPSX 工具链在该仓库中是双环境同构部署的Claude Code 侧.claude/commands/opsx/下 10 个命令 MarkdownOpenCode 侧.opencode/skills/下 9 个openspec-*Skillopenspec-ff-change、openspec-apply-change、openspec-verify-change、openspec-new-change、openspec-continue-change、openspec-explore、openspec-sync-specs、openspec-archive-change、openspec-bulk-archive-change、openspec-onboard。以 .opencode/skills/openspec-ff-change/SKILL.md 为例其 frontmatter 额外标注了compatibility: Requires openspec CLI——前置条件是需要安装 openspec CLI所有openspec new/status/instructions命令均依赖它generatedBy: 1.1.1——该 Skill 由 openspec 工具链 1.1.1 版本生成可据此判断工具链版本对应关系license: MIT——Skill 本身以 MIT 协议发布。实际使用前提可归纳为三点已安装 openspec CLI、AI 客户端支持该命令目录约定Claude Code 的.claude/commands或 OpenCode 的.opencode/skills、以及接受其experimental标签所暗示的 API 与流程可能随版本演进。对于想为本仓库贡献 AI 驱动开发能力的开发者直接复用这套双环境命令定义即可无需重复发明工作流。小结/opsx:ff的价值在于把 OpenSpec 的制品生成从多轮人工驱动压缩为一次依赖感知的自动流水线它以openspec new建立数据目录以openspec status --json获取调度图以openspec instructions --json驱动每个制品的生成并以applyRequires作为明确的终点信号。配合apply、verify、archive等命令家族ff让「一个变更从想法到可实现的制品全集」在 AI Agent 的一次会话内即可完成是规格驱动开发在 AI 协作场景下的一项具体、可落地的工程实践。【免费下载链接】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），仅供参考 OPSX Fast Forward 工作流详解：/opsx:ff 命令如何一键生成 OpenSpec 变更制品
OPSX Fast Forward 工作流详解/opsx:ff 命令如何一键生成 OpenSpec 变更制品【免费下载链接】actorsRivet Actors are the primitive for stateful workloads. Built for AI agents, collaborative apps, and durable execution.项目地址: https://gitcode.com/GitHub_Trending/riv/actors导读本文以 Rivet Actors 仓库中的 .claude/commands/opsx/ff.md 为核心系统拆解/opsx:ffOPSX Fast Forward命令的输入语义、五步执行流程、制品依赖编排机制与护栏约束并结合.claude/commands/opsx/命令家族与.opencode/skills/下的对应 Skill还原一条从「新建变更」到「验证归档」的完整规格驱动spec-driven开发链路。读完你既能直接上手使用该命令也能理解 OpenSpec 制品流水线在 AI Agent 协作场景下的底层设计。一、OPSX 与 Fast Forward 的定位/opsx:ff是 Rivet Actors 仓库内置的 AI 工作流命令之一定义在 .claude/commands/opsx/ff.md。其 frontmatter 声明如下字段值nameOPSX: Fast ForwarddescriptionCreate a change and generate all artifacts needed for implementation in one gocategoryWorkflowtags[workflow, artifacts, experimental]其中 OPSX 指OpenSpec eXperimental实验性的制品驱动工作流ff即Fast Forward快进它把通常需要多轮交互逐个创建的制品生成过程压缩成一次执行——一次性生成从零到「可以动手实现」所需的全部制品。在该仓库中这一能力同时存在两套等价形态Claude Code 命令.claude/commands/opsx/ff.md本文主体OpenCode Skill.opencode/skills/openspec-ff-change/SKILL.md同一流程的 Skill 版元数据标注license: MIT、generatedBy: 1.1.1、compatibility: Requires openspec CLI。两者的步骤、输出与护栏完全一致本文以 Claude Code 命令版为准逐层展开。二、命令的输入语义变更名还是需求描述/opsx:ff接受两种输入形式语义如下变更名kebab-case例如/opsx:ff add-user-auth自然语言描述例如/opsx:ff 我想加一个用户认证功能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。这一步是后续所有制品质量的前提——制品内容高度依赖对变更意图的准确捕获。三、五步执行流程逐层拆解ff.md将整个快进过程编排为 5 个步骤下面逐一展开并说明其背后的机制。第 1 步澄清需求并派生变更名同「输入语义」一节无输入时先提问再根据回答派生 kebab-case 变更名。这一步产出的是后续所有命令的name参数。第 2 步创建变更目录openspec new change name该命令会在openspec/changes/name/下创建一个脚手架变更目录scaffolded change。这是 OpenSpec CLI 提供的核心命令也是整个 OPSX 工作流的数据起点——所有后续制品都写入这个目录中。第 3 步获取制品构建顺序openspec status --change name --json解析 JSON 输出可以得到两个关键结构字段含义示例applyRequires进入实现阶段apply之前必须完成的制品 ID 数组[tasks]artifacts全部制品的清单包含各自的状态与依赖关系各制品的status、dependenciesartifacts数组中的每个制品都有一个状态构成整个流水线的调度依据详见下一节的状态机。这一步回答的核心问题是该 schema 下需要创建哪些制品、它们之间的依赖顺序是什么、做到哪一步才能开始写代码。第 4 步按依赖顺序循环创建制品核心循环这是ff与new、continue最本质的区别所在。new只搭脚手架便停手continue每次只创建一个制品而ff用一个循环把 apply-ready 之前的所有制品一次跑完使用TodoWrite 工具登记制品进度按依赖顺序遍历制品无待决依赖的制品优先对每个状态为ready依赖已满足的制品拉取生成指令openspec instructions artifact-id --change name --jsonopenspec instructions返回的 JSON 是制品的生成配方包含 6 个关键字段字段作用使用方式context项目背景作为 Agent 的约束不写入输出文件rules制品专属规则作为 Agent 的约束不写入输出文件template输出文件应遵循的结构作为文件骨架直接使用instruction该制品类型的 schema 级指导决定制品内容的写法outputPath制品应写入的位置落盘路径dependencies已完成、需先阅读的制品创建前必须读取以获取上下文拿到指令后Agent 的执行顺序是先读取dependencies中列出的已完成制品→ 以template为结构 → 在context与rules的约束下填充内容 → 写入outputPath并输出简短进度✓ Created artifact-id循环终止条件每创建完一个制品重新执行openspec status --change name --json检查applyRequires中的每个制品 ID 在artifacts数组中是否都已status: done。全部完成即停止不贪多。循环中的分支处理如果某个制品因上下文不清晰而需要用户输入则使用AskUserQuestion 工具澄清后继续创建。第 5 步展示最终状态openspec status --change name以人类可读格式收尾向用户汇报整个变更的制品完成情况。四、制品状态机与依赖编排将第 3、4 步的机制抽象出来OPSX 制品流水线本质是一个依赖驱动的有向无环图调度┌──────────┐ │ blocked │ 依赖未满足等待上游制品完成 └──────────┘ │ 依赖全部完成 ▼ ┌──────────┐ │ ready │ 可以取指令并生成 └──────────┘ │ 文件落盘 ▼ ┌──────────┐ │ done │ 制品完成解锁下游 └──────────┘关键设计点只处理ready制品每次迭代优先选取无待决依赖的制品天然保证了拓扑序每步都回读 status创建后重新查询状态是唯一的进度事实来源避免 Agent 凭记忆推进以applyRequires为终点done状态只在applyRequires全覆盖时才触发循环退出既不会漏制品也不会越界生成实现阶段才需要的东西。以continue.md中记录的spec-driven schema为例典型制品序列为proposal.md → specs/capability/spec.md → design.md → tasks.md其中tasks.md勾选式任务清单通常就是applyRequires里的最后一块拼图。ff会把这条链路一次走完而tasks.md里的- [ ]复选框正是下一阶段apply的消费对象见第六节。五、制品内容边界template 与约束的分离ff.md在「Artifact Creation Guidelines」中明确了生成内容时的三条纪律遵循instruction字段每个制品类型由 schema 定义其应包含的内容instruction是权威指南先读依赖制品创建新制品前必须读取其依赖制品保证上下文连贯、术语一致template 只是起点以template为骨架结合上下文填充而非照抄模板原文。特别值得注意的是约束与内容的严格分离context、rules是写给Agent写作者的约束指导「怎么写」但绝不能作为内容粘贴进制品文件。这是 OPSX 保证制品文件干净、可被后续apply/verify直接消费的关键约定。六、收尾输出与交接格式所有制品创建完成后Agent 需要输出结构化摘要ff.md规定的要素如下变更名与位置如add-user-authopenspec/changes/add-user-auth/制品清单逐个列出已创建的制品及一句话描述就绪声明All artifacts created! Ready for implementation.交接提示提示用户运行/opsx:apply开始实现OpenCode 版对应提示为/opsx-apply。七、护栏Guardrails逐条解读ff.md定义了 5 条护栏约束 Agent 在快进过程中的行为边界护栏意图创建 schema 的apply.requires定义的全部制品防止少建导致实现阶段缺上下文创建新制品前总是先读依赖制品保证制品间的信息传递不丢失上下文严重不清时提问但优先做合理决策以保持节奏在「准确」与「效率」之间取平衡同名变更已存在时询问是继续还是新建避免目录冲突与内容覆盖写入后校验制品文件确实存在再进入下一步防止静默写盘失败污染状态机这些护栏共同塑造了ff的快而不莽它能一口气跑完整个制品流水线但在需求不明、命名冲突、写盘失败等关键节点会主动停下确认。八、与 OPSX 命令家族串联从新建到归档的完整生命周期ff不是孤立命令。在 .claude/commands/opsx/ 下共有 10 个命令构成完整的 OPSX 生命周期命令阶段职责关键行为/opsx:explore探索只思考不实现想法成熟后引导进入new/ff/opsx:new启动搭脚手架、展示首个制品模板创建 0 个制品/opsx:ff本文启动快进一次性生成全部applyRequires制品/opsx:continue推进每次只创建下一个ready制品/opsx:apply实现消费tasks制品逐项勾选- [ ] → - [x]/opsx:verify验证按 Completeness / Correctness / Coherence 三维度出报告CRITICAL / WARNING / SUGGESTION/opsx:archive归档实现验证通过后归档变更/opsx:bulk-archive批量归档一次归档多个已完成变更/opsx:sync同步将变更的 delta specs 同步回主规格/opsx:onboard接入引导新项目初始化 OPSX 环境典型的端到端链路为explore → new / ff → continue → apply → verify → archive / syncff在这条链路上承担「启动阶段的高吞吐路径」当用户对变更已经有清晰想法、不想一步步等待制品逐个创建时用ff一步到位而当变更需要边做边想、分阶段确认时new 多次continue才是更稳妥的选择。apply阶段还会根据实现进展反向建议更新制品apply.md 中称为 Fluid Workflow Integration说明整个模型是可回流的而非僵化的线性流水线。九、在 Rivet Actors 仓库中的落地形态与前置条件从仓库结构可以确认OPSX 工具链在该仓库中是双环境同构部署的Claude Code 侧.claude/commands/opsx/下 10 个命令 MarkdownOpenCode 侧.opencode/skills/下 9 个openspec-*Skillopenspec-ff-change、openspec-apply-change、openspec-verify-change、openspec-new-change、openspec-continue-change、openspec-explore、openspec-sync-specs、openspec-archive-change、openspec-bulk-archive-change、openspec-onboard。以 .opencode/skills/openspec-ff-change/SKILL.md 为例其 frontmatter 额外标注了compatibility: Requires openspec CLI——前置条件是需要安装 openspec CLI所有openspec new/status/instructions命令均依赖它generatedBy: 1.1.1——该 Skill 由 openspec 工具链 1.1.1 版本生成可据此判断工具链版本对应关系license: MIT——Skill 本身以 MIT 协议发布。实际使用前提可归纳为三点已安装 openspec CLI、AI 客户端支持该命令目录约定Claude Code 的.claude/commands或 OpenCode 的.opencode/skills、以及接受其experimental标签所暗示的 API 与流程可能随版本演进。对于想为本仓库贡献 AI 驱动开发能力的开发者直接复用这套双环境命令定义即可无需重复发明工作流。小结/opsx:ff的价值在于把 OpenSpec 的制品生成从多轮人工驱动压缩为一次依赖感知的自动流水线它以openspec new建立数据目录以openspec status --json获取调度图以openspec instructions --json驱动每个制品的生成并以applyRequires作为明确的终点信号。配合apply、verify、archive等命令家族ff让「一个变更从想法到可实现的制品全集」在 AI Agent 的一次会话内即可完成是规格驱动开发在 AI 协作场景下的一项具体、可落地的工程实践。【免费下载链接】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），仅供参考