前言¶

需求聊完就动手写代码，写到一半发现验收标准没对齐，改一轮再改一轮。另一种情况是：团队想引入规范驱动开发（spec-driven development），但每个人理解的「规范」不一样，也没有一个固定流程。

OpenSpec-FissionAI 把这件事变成一个可执行的流程：先写 spec 与验收场景，再实现、校验、归档。它封装的是开源项目 OpenSpec（github.com/Fission-AI/OpenSpec，MIT 协议）的工作流。

这是什么¶

OpenSpec-FissionAI 是一个面向 WorkBuddy 的 Agent Skill，坐标 @user_8170ea13/openspec-fissionai，当前版本 1.2.2，由社区发布者 user_8170ea13 维护，来源标记为 community，分类 dev-programming。

它解决的问题是：在写代码之前，用 spec 把「做什么」先对齐。Skill 的描述里明确说明，它不是通用项目管理工具，也不替代 git。

核心功能¶

下面介绍的能力都来自该 Skill 的官方简介。

• 写 spec / 创建 spec：把一次改动的目标、范围先落成文本。
• 封装 OpenSpec 命令：new change、instructions、apply、validate、archive、status。对应规划代码改动、技术方案对齐、代码变更提案、验收场景与验收标准。
• 触发方式：当用户说「先设计后编码」「先对齐需求再动手」「动手前先规划」「规划这次改动」「写一个变更提案」「验收场景怎么写」时使用。
• 模糊意图也能触发：当提问模糊但意图指向 OpenSpec / spec 驱动开发与需求拆解时，Skill 会主动引导，不需要用户说出准确的命令词或技能名。

Skill 标签里 requires_api_key=false，说明不需要额外的 API Key 配置。

安装与启用¶

官方页面：https://www.skillhub.cn/skills/user_8170ea13/openspec-fissionai

当前抓取到的资料只给出了 SkillHub 页面地址和坐标，没有提供命令行安装命令、本地目录路径或配置文件字段。因此这里不写未经核实的安装步骤。需要确认安装方式时，以上述官方页面为准。

启用后在 WorkBuddy 内使用；该 Skill 面向 WorkBuddy 环境，资料中没有提到 Cursor、Codex CLI、Claude Code 的适配差异，这里不推测。

典型用法¶

OpenSpec 自身的命令来自开源项目 Fission-AI/OpenSpec，下面按 Skill 简介中列出的命令说明各自用途，具体参数以官方页面和 OpenSpec 文档为准。

openspec new change

新建一次变更（change），先明确这次要做什么。

openspec instructions

获取规范说明，用于对齐写法与流程。

openspec apply

按 spec 落地代码改动。

openspec validate

校验 spec 与改动是否符合要求。

openspec status

查看当前变更的状态。

openspec archive

变更完成后归档，把这一段规划收尾。

按顺序理解：先 new change 写清目标，再写验收场景与验收标准，然后 apply 实现，validate 校验，status 看进度，最后 archive 归档。

适用场景与注意¶

适合想在动手前先规划清楚的人：规划代码改动、技术方案对齐、写代码变更提案、写验收场景和验收标准。

注意几点。

• 它不是通用项目管理工具，也不替代 git，代码版本管理仍要走 git。
• 它封装的是 OpenSpec 的工作流，不是 OpenSpec 本身，命令行为以 OpenSpec 官方文档为准。
• 触发依赖意图描述，需求描述过于含糊时可能需要多轮确认才能落到具体 spec。

结尾¶

OpenSpec-FissionAI 的价值在于把「先写 spec 再写代码」变成固定动作，而不是靠口头约定。官方地址：https://www.skillhub.cn/skills/user_8170ea13/openspec-fissionai，页面地址 https://api.skillhub.cn/user_8170ea13/openspec-fissionai。