企业官网建设流程全解析

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-ff是其中唯一一条"一次调用、批量产出"的命令，其定位介于/opsx-new（只建变更目录）与/opsx-continue（一次一个 artifact）之间：它自动完成/opsx-continue需要多次重复的全部循环。仓库还提供了等价的 skill 描述 openspec-ff-change/SKILL.md，两者协议一致，可互为印证。

一、输入处理：没有输入就先问清楚

/opsx-ff的参数有两种合法形式：

1. 变更名称（kebab-case），例如add-user-auth；
2. 用户对要构建内容的自然语言描述，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 的列表，含各自的status（done/ready/blocked）与依赖关系。

artifacts中status: "ready"表示该 artifact 的前置依赖已满足、可以创建；blocked表示仍有未满足的依赖。/opsx-ff的核心循环就是反复消费ready状态的 artifact，直到applyRequires中每一项都变为done。

四、核心循环：按依赖顺序批量创建 artifacts

4.1 用 TodoWrite 跟踪进度

开始循环前，先用TodoWrite 工具登记待创建的 artifacts，使多步批量操作对用户可见、可追踪。

4.2 获取单个 artifact 的指令

对于每个status: "ready"的 artifact，执行：

openspec instructions <artifact-id> --change "<name>" --json

返回的 instructions JSON 包含六个关键字段：

一个关键的纪律是：context与rules是写给 Agent 的约束，而不是文件内容。openspec-ff-changeskill 对此特别强调：不要将<context>、<rules>、<project_context>块复制进 artifact——它们指导你写什么，但绝不应出现在输出中（见 openspec-ff-change/SKILL.md）。

4.3 写 artifact：先读依赖，再按模板落盘

每个 artifact 的创建流程：

1. 读取dependencies中列出的已完成 artifact 文件，获取上下文；
2. 以template为结构骨架，结合instruction的专项指导填充内容；
3. 应用context和rules作为约束，但不复制它们到文件；
4. 向outputPath写入文件；
5. 输出简短进度：✓ Created <artifact-id>。

以 spec-driven schema 为例（/opsx-ff在默认 schema 下会生成）：proposal.md回答 Why / What Changes / Capabilities / Impact，其中 Capabilities 部分至关重要——每个 capability 都会对应一个specs/<capability>/spec.md；design.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>"

随后向用户输出一段结构化总结，必须包含四部分：

1. 变更名称与位置（openspec/changes/<name>/）；
2. 已创建的 artifacts 清单，每个附一句简述；
3. 就绪声明："All artifacts created! Ready for implementation."；
4. 下一步提示："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在追求速度的同时也设置了六条硬性护栏：

1. 创建全部实现所需 artifacts：以 schema 的apply.requires为准，缺一不可；
2. 总是先读依赖再创建：禁止跳过上下文直接产出；
3. 关键歧义才提问：上下文严重不清时询问用户，但优先自主决策以保持推进；
4. 同名变更先确认：若同名变更已存在，询问用户是继续它还是新建；
5. 写后校验：每个 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. 循环（对每个 status=ready 的 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