OpenSpec 是面向 AI 编码助手的规格驱动开发 CLI。每项改动用独立目录保存 proposal、specs、design 和 tasks，开发者先审查需求与方案，再让代理实现并归档。它使用普通 Markdown，并为不同编码工具生成对应命令。
来源：github.com/Fission-AI/OpenSpec 查看 GitHub 仓库 → 📘 使用教程 →AI 编码任务一旦跨多个文件或会话，仅靠聊天历史很难保留需求边界。OpenSpec 用可提交的变更目录把计划与实现分开，还能覆盖已有代码库和多种编码助手。这些累计值不能解释为独立用户。
来源：github.com/Fission-AI/OpenSpecproposal.md 记录动机和范围，specs 保存需求与场景，design.md 记录技术方案，tasks.md 保存实现清单。归档后变更进入 openspec/changes/archive。
来源：github.com/Fission-AI/OpenSpec默认 profile 包含 explore 与 propose；典型流程用 propose 建立产物、apply 实现、archive 归档。扩展 profile 另有 new、continue、ff、verify 等命令。
来源：github.com/Fission-AI/OpenSpec同一动作会按客户端采用不同调用形式，openspec init 会打印已选择工具的实际命令；官方当前称支持 30 多种工具。
来源：github.com/Fission-AI/OpenSpecv1.13.1 加强配置注入、卡死文件和 .npmrc 更新重定向防护，并让 validate 检查缺失 delta、空场景和任务复选框等问题。
来源：github.com/Fission-AI/OpenSpec/releases/tag/v1.13.1Node.js CLI 通过 openspec init 在项目中建立 openspec 目录和客户端命令。变更材料以 Markdown 保存，schema 定义产物及其依赖；代理命令负责生成、继续、应用、校验和归档。项目代码是 TypeScript，发布为 @fission-ai/openspec，package.json 当前版本与 Latest release 都是 1.13.1。
来源：github.com/Fission-AI/OpenSpec；https://github.com/Fission-AI/OpenSpec…commander@inquirer/promptsfast-globyamlzod适合已有代码库中的跨文件功能、需要多人审查的需求变更，以及希望在多种编码助手之间复用同一套规格产物的团队。很小的一次性修改可能不值得创建完整的 proposal、design 和 tasks。Stores 跨仓库规划当前仍标为 beta。
来源：github.com/Fission-AI/OpenSpec2026-09-23 核对时，Latest release 是 v1.13.1，GitHub 页面显示 2026-09-17 发布；主分支 package.json 也是 1.13.1。该版重点是 CLI 安全加固、归档和校验可靠性、profile 感知命令以及 status 的下一步提示。
来源：github.com/Fission-AI/OpenSpec/releases/tag/v1.13.1；https://github.co…status: docs_only_official_sources_checked_not_installed | checked_at: 2026-09-23 | environment: 只阅读 Fission-AI/OpenSpec 官方 README、package.json、v1.13.1 release 与 GitHub Spec Kit 官方 README；未安装 npm 包，也未运行 openspec init | limitations: 没有观察 init 生成内容、客户端命令、propose/apply/archive、validate、安全加固或 Stores；教程中的结果描述来自官方资料，不是本机输出。 | observed_output: 官方 README 与 package.json 当前都要求 Node.js >=20.19.0；package.json 是 1.13.1，GitHub Releases 把 v1.13.1 标为 Latest，页面显示 2026-09-17 发布。
来源：github.com/Fission-AI/OpenSpec；https://github.com/Fission-AI/OpenSpec…相比 GitHub Spec Kit，OpenSpec 更集中在每项变更的 proposal、specs、design、tasks 与归档，并通过适配器覆盖多种编码助手。Spec Kit 官方当前把规格驱动开发、修复和想法评估作为独立流程入口，并要求 Python 3.11+ 与 uv。想在现有 Node 项目中采用轻量变更目录，可先试 OpenSpec；需要更宽的流程目录、扩展和 preset 体系时，可评估 Spec Kit。
来源：github.com/Fission-AI/OpenSpec；https://github.com/github/spec-kit/blo…OpenSpec 适合把中等以上改动变成可审查的规格记录。首次接入应选一个真实但低风险的功能，从 propose 到 archive 走完一轮，并检查生成文件是否让审查更清楚；若团队只是机械提交模板而不读规格，工具不会改善结果。
来源：github.com/Fission-AI/OpenSpec官方说明不同客户端会改写命令形式，Codex 可能显示 $openspec-propose，Cursor 或 GitHub Copilot 可能使用 /opsx-propose。以 openspec init 为所选工具打印的命令为准。
propose 建立提案、规格、设计和任务；apply 按已审查的任务实现；archive 在完成验证后归档变更并更新规格。不要跳过人工审查直接把 propose 接到 apply。
官方 release notes 记录了 config.yaml 指令注入、恶意文件让 update/archive 卡死，以及仓库 .npmrc 重定向更新检查等加固，同时加强归档和规格校验。
官方当前仍把 Stores 标为 beta。可以先在非关键跨仓库需求上验证权限、同步、回滚和代理读取方式，再决定是否纳入正式流程。