人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本篇技术指南围绕 ccg-workflow 仓库中.agents/skills/openspec-onboard/SKILL.md这一引导式教学技能展开完整讲解 OpenSpecOPSX从「想法」到「实现」再到「归档」的整条变更生命周期包括前置检查、任务挑选、四类制品proposal / specs / design / tasks的编写规范、实现阶段的执行节奏与优雅退出的兜底策略。读完本文你将掌握如何用一次真实的仓库任务带领或被带领完成首个 OpenSpec 变更周期并能对照仓库内 9 个配套技能文件explore / new / ff / continue / apply / verify / archive / sync 等理解每一个命令背后的工作流设计。一、openspec-onboard 技能定位在真实代码库中学会 OpenSpecopenspec-onboard 是 ccg-workflow 仓库.agents/skills/目录下的引导式onboarding技能其核心定位不是讲解概念而是带着用户在真实代码库中走完一个完整的 OpenSpec 变更周期——边做真实工作边解释每一步。技能的 frontmatter 元数据也明确了使用前提license: MITcompatibility: Requires openspec CLI必须安装 OpenSpec CLI 才能运行generatedBy: 1.1.1由 OpenSpec 1.1.1 生成它与仓库内其他 8 个 openspec-* 技能组成一套完整的工作流家族技能文件仓库相对路径职责.agents/skills/openspec-onboard/SKILL.md引导式教学走完完整周期.agents/skills/openspec-explore/SKILL.md探索模式实现前的思考.agents/skills/openspec-new-change/SKILL.md新建变更逐步生成制品.agents/skills/openspec-ff-change/SKILL.md快速通道一次性生成全部制品.agents/skills/openspec-continue-change/SKILL.md续写变更的下一个制品.agents/skills/openspec-apply-change/SKILL.md按任务清单实现代码.agents/skills/openspec-verify-change/SKILL.md校验实现与制品的一致性.agents/skills/openspec-archive-change/SKILL.md归档已完成变更.agents/skills/openspec-sync-specs/SKILL.md将 delta 规格同步到主规格.agents/skills/openspec-bulk-archive-change/SKILL.md批量归档在 ccg-workflow 项目中这套 OpenSpec 技能与项目的多模型协作体系深度绑定项目模板命令 templates/commands/spec-init.md 明确写出 OPSX provides the specification framework; CCG adds multi-model collaborationOPSX 提供规格框架CCG 叠加多模型协作并提供了/ccg:spec-research、/ccg:spec-plan、/ccg:spec-impl、/ccg:spec-review等一系列封装命令。二、Preflight动手前的初始化检查onboard 的第一步不是直接开始教学而是检查 OpenSpec 是否已在当前项目中初始化。技能给出的检查命令是openspec status --json 21 || echo NOT_INITIALIZED若输出NOT_INITIALIZED或命令失败技能要求立即停止并提示用户先执行初始化OpenSpec isnt set up in this project yet. Runopenspec initfirst, then come back to/opsx:onboard.关于初始化本身可以参考仓库内 templates/commands/spec-init.md 的详细步骤OpenSpec CLI 通过npx fission-ai/openspec --version校验未安装时执行npm install -g fission-ai/openspeclatest初始化命令为npx fission-ai/openspec initv1.2 支持交互式选择 profilecore默认包含 propose / explore / apply / archive 四个核心工作流custom可自由挑选子集之后可用openspec config profile调整。同时注意OpenSpec CLI 的命令是openspec不是opsx这一点在 spec-init.md 中被反复强调。初始化验证包括三件事openspec/目录存在、.claude/skills/下存在openspec-*技能、.claude/commands/opsx/下存在 OPSX 命令。三、Phase 1-2欢迎与真实任务挑选欢迎信息初始化确认后技能要求向用户展示一段欢迎语明确本次旅程的六步计划与时间预期约 15-20 分钟1. Pick a small, real task in your codebase 2. Explore the problem briefly 3. Create a change (the container for our work) 4. Build the artifacts: proposal → specs → design → tasks 5. Implement the tasks 6. Archive the completed change代码库分析六类快速获胜机会任务挑选阶段要求对代码库进行真实扫描优先寻找以下六类小改进机会TODO/FIXME 注释在代码文件中搜索TODO、FIXME、HACK、XXX缺失的错误处理吞掉异常的catch块、缺少 try-catch 的危险操作没有测试的函数交叉比对src/与测试目录类型问题TypeScript 中的any类型: any、as any调试残留非调试代码中的console.log、console.debug、debugger缺失的输入校验没有校验的用户输入处理同时查看近期 git 活动辅助判断git log --oneline -10 2/dev/null || echo No git history给出 3-4 个具体建议扫描后向用户呈现 3-4 个候选任务每个任务标注位置src/path/to/file.ts:42、范围估算如 ~1-2 files, ~20-30 lines和推荐理由最后一个选项永远是 Something else?把选择权交还用户。若找不到明显任务则回退为开放式提问Whats something small youve been meaning to add or fix?范围护栏Scope Guardrail若用户选了一个过大的任务大型特性、多日工作量技能提供了一套软性护栏话术指出任务价值但建议缩小并给出三个选项——切小找出最小可用切片、换一个、坚持做提示会耗时更久。关键原则是这是软护栏用户坚持就要尊重其选择——因为教学目标是走通流程而不是替用户决策范围。四、Phase 3探索演示Explore Demo选定任务后正式创建变更前技能要求花 1-2 分钟演示探索模式explore mode阅读相关文件、按需绘制 ASCII 图、记录注意事项。探索模式的完整理念定义在 .agents/skills/openspec-explore/SKILL.md 中——它强调This is a stance, not a workflow这是一种姿态不是一套流程没有固定步骤、没有强制输出。核心纪律是Explore mode is for thinking, not implementing可以读文件、搜代码、调查代码库但绝不允许写实现代码用户一旦要求实现必须提醒先退出探索模式用/opsx:new或/opsx:ff开启变更探索时可以应要求创建 OpenSpec 制品proposal / design / specs因为记录思考不等于实现功能探索模式有四个标准入口模糊想法画协作频谱图辅助定位、具体问题画当前流程/架构图找症结、实现中途卡壳读变更制品追踪任务、方案对比如 SQLite vs Postgres用约束矩阵给出结论探索模式与变更的衔接点也很明确openspec list --json检查现有变更决策成型后可自然过渡到/opsx:new或/opsx:ff探索中发现的新需求、设计决策、范围变化、新工作会分别被引导捕获到specs/capability/spec.md、design.md、proposal.md、tasks.md中但只提供捕获建议不自动落盘。本阶段结束时技能要求PAUSE等待用户确认后再继续。五、Phase 4创建变更容器Create the Change变更change是 OpenSpec 的核心容器概念——它承载围绕某件工作的一切思考与规划位于openspec/changes/name/目录内含四类制品openspec/changes/name/ ├── proposal.md ← Why were doing this (空待填写) ├── design.md ← How well build it (空) ├── specs/ ← Detailed requirements (空) └── tasks.md ← Implementation checklist (空)创建命令是openspec new change derived-name其中derived-name是从任务描述推导出的 kebab-case 名称例如 add user authentication →add-user-auth。.agents/skills/openspec-new-change/SKILL.md 补充了更多细节默认使用 spec-driven schema省略--schema只有用户显式提及特定 schema 或询问 show workflows运行openspec schemas --json时才加--schema name名称非法非 kebab-case或与已有变更重名时都要先处理。创建后可运行openspec status --change name查看各制品的就绪状态ready / done / blocked。六、Phase 5-8四大制品的生成规范Phase 5Proposal —— 回答为什么proposal 是工作的电梯演讲记录why为何做与what高层面上涉及什么。模板结构为## Why [1-2 句话说明问题/机会] ## What Changes [将要发生变化的要点列表] ## Capabilities ### New Capabilities - capability-name: [简要描述] ### Modified Capabilities !-- 若修改现有行为 -- ## Impact - src/path/to/file.ts: [改动内容] - [其他受影响文件]关键点Capabilities一节至关重要——.agents/skills/openspec-continue-change/SKILL.md 明确指出每个列出的 capability 都需要一个对应的 spec 文件。草稿需先经用户确认批准后保存openspec instructions proposal --change name --jsoninstructions命令会返回context项目背景约束、rules制品专属规则、template输出文件结构、instructionschema 指引、outputPath写入路径、dependencies需先阅读的已完成制品等关键字段。注意context和rules是约束 Agent 的输入绝不能复制进制品文件本身——这是 ff/continue 技能中反复强调的纪律。Phase 6Specs —— 用 WHEN/THEN/AND 定义做什么specs 用可测试的 requirement/scenario 格式定义要构建什么。小任务通常只需一个 spec 文件创建方式mkdir -p openspec/changes/name/specs/capability-name规格文件模板## ADDED Requirements ### Requirement: Name 系统应该做什么的描述 #### Scenario: Scenario name - **WHEN** 触发条件 - **THEN** 预期结果 - **AND** 额外的预期结果WHEN/THEN/AND 格式让需求天然可测试——你可以把每个 scenario 直接读成一条测试用例。这里写的是delta spec增量规格与主规格openspec/specs/capability/spec.md相对.agents/skills/openspec-sync-specs/SKILL.md 展示了 delta spec 的完整四种区块ADDED / MODIFIED / REMOVED / RENAMED Requirements以及智能合并原则例如只为已有需求追加一个 scenario时只需在 MODIFIED 区块里写这一个 scenario无需复制已有场景——delta 表达的是意图而非整体替换。Phase 7Design —— 记录怎么做design 记录技术决策、权衡与实现路径。小变更的设计可以很简短——不是每个变更都需要深度设计讨论。模板## Context [当前状态简述] ## Goals / Non-Goals **Goals:** - [目标] **Non-Goals:** - [明确排除的范围] ## Decisions ### Decision 1: [关键决策] [方案与理由]Phase 8Tasks —— 拆成实现清单tasks 把工作拆成驱动 apply 阶段的复选框任务要求小而清晰、按逻辑顺序排列## 1. [Category or file] - [ ] 1.1 [具体任务] - [ ] 1.2 [具体任务] ## 2. Verify - [ ] 2.1 [验证步骤]每个复选框都会成为 apply 阶段的一个工作单元。Tasks 生成后PAUSE等用户确认再保存到tasks.md。七、Phase 9Apply实现阶段实现阶段的原则是旁白要轻——不过度解释每一行代码但要自然引用 specs/design 如何指导实现The spec says X, so Im doing Y。每个任务的执行节奏是宣布Working on task N: [description]在代码库中实施改动自然地关联 specs/design 的决策在 tasks.md 中勾选- [ ]→- [x]简短汇报✓ Task N complete.agents/skills/openspec-apply-change/SKILL.md 给出了更工程化的版本先openspec status --change name --json解析schemaName与任务所在制品再openspec instructions apply --change name --json获取contextFilesspec-driven schema 下通常是 proposal、specs、design、tasks、进度统计total / complete / remaining与动态指令对三种状态分别处理——blocked缺制品建议转 continue、all_done祝贺并建议归档、否则进入实现循环。实现中遇到任务不清晰、暴露设计问题、报错或阻塞、用户打断时都应暂停。pause 时的输出模板包含问题描述与选项列表。该技能还特别强调fluid workflow integrationapply 可以在制品未全部完成时就被调用只要有 tasks 存在也可以与制品更新交错进行——不被阶段锁死。八、Phase 10归档Archive变更完成后归档将其从openspec/changes/移动到openspec/changes/archive/YYYY-MM-DD-name/openspec archive name归档后的变更成为项目的决策历史——日后总能回溯理解某功能为什么这么建。.agents/skills/openspec-archive-change/SKILL.md 补充了归档前的四道检查制品是否全部doneopenspec status --change name --json、tasks.md 是否有未完成复选框、以及delta spec 与主规格的同步评估若 delta specs 存在需先对比openspec/specs/capability/spec.md并展示变更摘要提供 Sync now (recommended) / Archive without syncing 选项用户选择同步则走 openspec-sync-specs 逻辑然后无论如何继续归档。归档实现上等价于mkdir -p openspec/changes/archive mv openspec/changes/name openspec/changes/archive/YYYY-MM-DD-name目标目录已存在时直接报错建议改期或重命名。.openspec.yaml随目录一并移动得以保留。九、Phase 11复盘与命令参考一个完整周期包含八个环节Explore思考→ New创建容器→ ProposalWHY→ SpecsWHAT→ DesignHOW→ Tasks拆步→ Apply实现→ Archive留存记录。同样的节奏适用于任何规模的变更——小修复或大特性皆然。技能内置的完整命令参考表CommandWhat it does/opsx:exploreThink through problems before/during work/opsx:newStart a new change, step through artifacts/opsx:ffFast-forward: create all artifacts at once/opsx:continueContinue working on an existing change/opsx:applyImplement tasks from a change/opsx:verifyVerify implementation matches artifacts/opsx:archiveArchive a completed change其中/opsx:verify对应 .agents/skills/openspec-verify-change/SKILL.md从完整性任务与规格覆盖、正确性需求实现映射与场景覆盖、一致性设计遵循与代码模式三个维度生成报告问题分 CRITICAL / WARNING / SUGGESTION 三级且每条都必须附带具体、可执行的建议含文件/行号引用。启发式原则包括不确定时优先降级SUGGESTION WARNING CRITICAL和优雅降级——只有 tasks 时只查任务完成度有 tasks specs 时查前两维全套制品才查三维并始终注明跳过了哪些检查及原因。十、优雅退出中途停止与跳过教程onboard 技能为两类常见情况准备了兜底话术核心是不施压用户中途想停告知变更已保存于openspec/changes/name/后续可用/opsx:continue name续写制品、/opsx:apply name直接跳到实现若 tasks 已存在——工作不会丢随时回来。用户只想要命令速查直接给出精简版命令表CommandWhat it does/opsx:exploreThink through problems (no code changes)/opsx:new nameStart a new change, step by step/opsx:ff nameFast-forward: all artifacts at once/opsx:continue nameContinue an existing change/opsx:apply nameImplement tasks/opsx:verify nameVerify implementation/opsx:archive nameArchive when done十一、Guardrails教学式引导的七条铁律技能在结尾给出了引导式教学的核心纪律这也是评判 onboard 会话质量的标准遵循 EXPLAIN → DO → SHOW → PAUSE 模式在关键转换点探索后、proposal 草稿后、tasks 后、归档后必须暂停实现阶段旁白保持轻量教而不训teach without lecturing不跳阶段即使变更很小也要走完流程——目标是教学在标记点暂停确认但不过度暂停优雅处理退出绝不施压用户继续使用真实代码库任务不模拟、不用假例子温和调整范围引导走向更小的任务但尊重用户选择十二、在 ccg-workflow 中落地从 onboard 到完整协作工作流openspec-onboard 是整个 OpenSpec 技能族的第一课学完之后的进阶路径清晰可见用/opsx:new或/opsx:ff开启真实变更、用/opsx:continue续写、/opsx:apply实现、/opsx:verify校验、/opsx:archive归档、/opsx:sync同步规格。而在 ccg-workflow 项目中这套 OpenSpec 流程被进一步封装为多模型协作命令。仓库模板 templates/commands/spec-init.md 展示了完整的初始化与接力路径初始化后依次执行/ccg:spec-research description研究→/ccg:spec-plan规划与设计→/ccg:spec-impl实现内置自动评审与归档另有随时可用的独立双模型评审/ccg:spec-review。这些命令与 openspec-onboard 的关系可以这样理解onboard 解决学会 OpenSpec 节奏的问题CCG 封装命令解决在多模型协作中高效跑这个节奏的问题——规格框架来自 OPSX协作能力来自 CCG二者叠加正是本项目Claude 编排 Codex 后端 Gemini 前端多模型协作开发体系的根基。相关参考文件主文档 .agents/skills/openspec-onboard/SKILL.md配套技能 openspec-explore、openspec-new-change、openspec-ff-change、openspec-continue-change、openspec-apply-change、openspec-verify-change、openspec-archive-change、openspec-sync-specs以及 CCG 初始化命令模板 templates/commands/spec-init.md。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐基于 OpenSpec 工作流的变更归档实战ccg-workflow 中 openspec-archive-change 技能全解析基于 OpenSpec 工作流的变更归档实战ccg workflow 中 openspec archive change 技能全解析 本指南以 ccg wor基于 OpenSpec 的引导式变更工作流解读 riv/actors 仓库中的 openspec-onboard Agent 技能基于 OpenSpec 的引导式变更工作流解读 riv/actors 仓库中的 openspec onboard Agent 技能 本文面向希望为 AI 编码后端AI Agent人工智能流程编排WebSocketccg-workflow 中的 OpenSpec 变更实施技能openspec-apply-change 完整操作指南ccg workflow 中的 OpenSpec 变更实施技能openspec apply change 完整操作指南 导读 openspec apply c人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇10个Electron应用优化技巧Caprine开发者实战经验分享下一篇ffsend蓝绿部署策略零停机更新实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本篇技术指南围绕 ccg-workflow 仓库中.agents/skills/openspec-onboard/SKILL.md这一引导式教学技能展开完整讲解 OpenSpecOPSX从「想法」到「实现」再到「归档」的整条变更生命周期包括前置检查、任务挑选、四类制品proposal / specs / design / tasks的编写规范、实现阶段的执行节奏与优雅退出的兜底策略。读完本文你将掌握如何用一次真实的仓库任务带领或被带领完成首个 OpenSpec 变更周期并能对照仓库内 9 个配套技能文件explore / new / ff / continue / apply / verify / archive / sync 等理解每一个命令背后的工作流设计。一、openspec-onboard 技能定位在真实代码库中学会 OpenSpecopenspec-onboard 是 ccg-workflow 仓库.agents/skills/目录下的引导式onboarding技能其核心定位不是讲解概念而是带着用户在真实代码库中走完一个完整的 OpenSpec 变更周期——边做真实工作边解释每一步。技能的 frontmatter 元数据也明确了使用前提license: MITcompatibility: Requires openspec CLI必须安装 OpenSpec CLI 才能运行generatedBy: 1.1.1由 OpenSpec 1.1.1 生成它与仓库内其他 8 个 openspec-* 技能组成一套完整的工作流家族技能文件仓库相对路径职责.agents/skills/openspec-onboard/SKILL.md引导式教学走完完整周期.agents/skills/openspec-explore/SKILL.md探索模式实现前的思考.agents/skills/openspec-new-change/SKILL.md新建变更逐步生成制品.agents/skills/openspec-ff-change/SKILL.md快速通道一次性生成全部制品.agents/skills/openspec-continue-change/SKILL.md续写变更的下一个制品.agents/skills/openspec-apply-change/SKILL.md按任务清单实现代码.agents/skills/openspec-verify-change/SKILL.md校验实现与制品的一致性.agents/skills/openspec-archive-change/SKILL.md归档已完成变更.agents/skills/openspec-sync-specs/SKILL.md将 delta 规格同步到主规格.agents/skills/openspec-bulk-archive-change/SKILL.md批量归档在 ccg-workflow 项目中这套 OpenSpec 技能与项目的多模型协作体系深度绑定项目模板命令 templates/commands/spec-init.md 明确写出 OPSX provides the specification framework; CCG adds multi-model collaborationOPSX 提供规格框架CCG 叠加多模型协作并提供了/ccg:spec-research、/ccg:spec-plan、/ccg:spec-impl、/ccg:spec-review等一系列封装命令。二、Preflight动手前的初始化检查onboard 的第一步不是直接开始教学而是检查 OpenSpec 是否已在当前项目中初始化。技能给出的检查命令是openspec status --json 21 || echo NOT_INITIALIZED若输出NOT_INITIALIZED或命令失败技能要求立即停止并提示用户先执行初始化OpenSpec isnt set up in this project yet. Runopenspec initfirst, then come back to/opsx:onboard.关于初始化本身可以参考仓库内 templates/commands/spec-init.md 的详细步骤OpenSpec CLI 通过npx fission-ai/openspec --version校验未安装时执行npm install -g fission-ai/openspeclatest初始化命令为npx fission-ai/openspec initv1.2 支持交互式选择 profilecore默认包含 propose / explore / apply / archive 四个核心工作流custom可自由挑选子集之后可用openspec config profile调整。同时注意OpenSpec CLI 的命令是openspec不是opsx这一点在 spec-init.md 中被反复强调。初始化验证包括三件事openspec/目录存在、.claude/skills/下存在openspec-*技能、.claude/commands/opsx/下存在 OPSX 命令。三、Phase 1-2欢迎与真实任务挑选欢迎信息初始化确认后技能要求向用户展示一段欢迎语明确本次旅程的六步计划与时间预期约 15-20 分钟1. Pick a small, real task in your codebase 2. Explore the problem briefly 3. Create a change (the container for our work) 4. Build the artifacts: proposal → specs → design → tasks 5. Implement the tasks 6. Archive the completed change代码库分析六类快速获胜机会任务挑选阶段要求对代码库进行真实扫描优先寻找以下六类小改进机会TODO/FIXME 注释在代码文件中搜索TODO、FIXME、HACK、XXX缺失的错误处理吞掉异常的catch块、缺少 try-catch 的危险操作没有测试的函数交叉比对src/与测试目录类型问题TypeScript 中的any类型: any、as any调试残留非调试代码中的console.log、console.debug、debugger缺失的输入校验没有校验的用户输入处理同时查看近期 git 活动辅助判断git log --oneline -10 2/dev/null || echo No git history给出 3-4 个具体建议扫描后向用户呈现 3-4 个候选任务每个任务标注位置src/path/to/file.ts:42、范围估算如 ~1-2 files, ~20-30 lines和推荐理由最后一个选项永远是 Something else?把选择权交还用户。若找不到明显任务则回退为开放式提问Whats something small youve been meaning to add or fix?范围护栏Scope Guardrail若用户选了一个过大的任务大型特性、多日工作量技能提供了一套软性护栏话术指出任务价值但建议缩小并给出三个选项——切小找出最小可用切片、换一个、坚持做提示会耗时更久。关键原则是这是软护栏用户坚持就要尊重其选择——因为教学目标是走通流程而不是替用户决策范围。四、Phase 3探索演示Explore Demo选定任务后正式创建变更前技能要求花 1-2 分钟演示探索模式explore mode阅读相关文件、按需绘制 ASCII 图、记录注意事项。探索模式的完整理念定义在 .agents/skills/openspec-explore/SKILL.md 中——它强调This is a stance, not a workflow这是一种姿态不是一套流程没有固定步骤、没有强制输出。核心纪律是Explore mode is for thinking, not implementing可以读文件、搜代码、调查代码库但绝不允许写实现代码用户一旦要求实现必须提醒先退出探索模式用/opsx:new或/opsx:ff开启变更探索时可以应要求创建 OpenSpec 制品proposal / design / specs因为记录思考不等于实现功能探索模式有四个标准入口模糊想法画协作频谱图辅助定位、具体问题画当前流程/架构图找症结、实现中途卡壳读变更制品追踪任务、方案对比如 SQLite vs Postgres用约束矩阵给出结论探索模式与变更的衔接点也很明确openspec list --json检查现有变更决策成型后可自然过渡到/opsx:new或/opsx:ff探索中发现的新需求、设计决策、范围变化、新工作会分别被引导捕获到specs/capability/spec.md、design.md、proposal.md、tasks.md中但只提供捕获建议不自动落盘。本阶段结束时技能要求PAUSE等待用户确认后再继续。五、Phase 4创建变更容器Create the Change变更change是 OpenSpec 的核心容器概念——它承载围绕某件工作的一切思考与规划位于openspec/changes/name/目录内含四类制品openspec/changes/name/ ├── proposal.md ← Why were doing this (空待填写) ├── design.md ← How well build it (空) ├── specs/ ← Detailed requirements (空) └── tasks.md ← Implementation checklist (空)创建命令是openspec new change derived-name其中derived-name是从任务描述推导出的 kebab-case 名称例如 add user authentication →add-user-auth。.agents/skills/openspec-new-change/SKILL.md 补充了更多细节默认使用 spec-driven schema省略--schema只有用户显式提及特定 schema 或询问 show workflows运行openspec schemas --json时才加--schema name名称非法非 kebab-case或与已有变更重名时都要先处理。创建后可运行openspec status --change name查看各制品的就绪状态ready / done / blocked。六、Phase 5-8四大制品的生成规范Phase 5Proposal —— 回答为什么proposal 是工作的电梯演讲记录why为何做与what高层面上涉及什么。模板结构为## Why [1-2 句话说明问题/机会] ## What Changes [将要发生变化的要点列表] ## Capabilities ### New Capabilities - capability-name: [简要描述] ### Modified Capabilities !-- 若修改现有行为 -- ## Impact - src/path/to/file.ts: [改动内容] - [其他受影响文件]关键点Capabilities一节至关重要——.agents/skills/openspec-continue-change/SKILL.md 明确指出每个列出的 capability 都需要一个对应的 spec 文件。草稿需先经用户确认批准后保存openspec instructions proposal --change name --jsoninstructions命令会返回context项目背景约束、rules制品专属规则、template输出文件结构、instructionschema 指引、outputPath写入路径、dependencies需先阅读的已完成制品等关键字段。注意context和rules是约束 Agent 的输入绝不能复制进制品文件本身——这是 ff/continue 技能中反复强调的纪律。Phase 6Specs —— 用 WHEN/THEN/AND 定义做什么specs 用可测试的 requirement/scenario 格式定义要构建什么。小任务通常只需一个 spec 文件创建方式mkdir -p openspec/changes/name/specs/capability-name规格文件模板## ADDED Requirements ### Requirement: Name 系统应该做什么的描述 #### Scenario: Scenario name - **WHEN** 触发条件 - **THEN** 预期结果 - **AND** 额外的预期结果WHEN/THEN/AND 格式让需求天然可测试——你可以把每个 scenario 直接读成一条测试用例。这里写的是delta spec增量规格与主规格openspec/specs/capability/spec.md相对.agents/skills/openspec-sync-specs/SKILL.md 展示了 delta spec 的完整四种区块ADDED / MODIFIED / REMOVED / RENAMED Requirements以及智能合并原则例如只为已有需求追加一个 scenario时只需在 MODIFIED 区块里写这一个 scenario无需复制已有场景——delta 表达的是意图而非整体替换。Phase 7Design —— 记录怎么做design 记录技术决策、权衡与实现路径。小变更的设计可以很简短——不是每个变更都需要深度设计讨论。模板## Context [当前状态简述] ## Goals / Non-Goals **Goals:** - [目标] **Non-Goals:** - [明确排除的范围] ## Decisions ### Decision 1: [关键决策] [方案与理由]Phase 8Tasks —— 拆成实现清单tasks 把工作拆成驱动 apply 阶段的复选框任务要求小而清晰、按逻辑顺序排列## 1. [Category or file] - [ ] 1.1 [具体任务] - [ ] 1.2 [具体任务] ## 2. Verify - [ ] 2.1 [验证步骤]每个复选框都会成为 apply 阶段的一个工作单元。Tasks 生成后PAUSE等用户确认再保存到tasks.md。七、Phase 9Apply实现阶段实现阶段的原则是旁白要轻——不过度解释每一行代码但要自然引用 specs/design 如何指导实现The spec says X, so Im doing Y。每个任务的执行节奏是宣布Working on task N: [description]在代码库中实施改动自然地关联 specs/design 的决策在 tasks.md 中勾选- [ ]→- [x]简短汇报✓ Task N complete.agents/skills/openspec-apply-change/SKILL.md 给出了更工程化的版本先openspec status --change name --json解析schemaName与任务所在制品再openspec instructions apply --change name --json获取contextFilesspec-driven schema 下通常是 proposal、specs、design、tasks、进度统计total / complete / remaining与动态指令对三种状态分别处理——blocked缺制品建议转 continue、all_done祝贺并建议归档、否则进入实现循环。实现中遇到任务不清晰、暴露设计问题、报错或阻塞、用户打断时都应暂停。pause 时的输出模板包含问题描述与选项列表。该技能还特别强调fluid workflow integrationapply 可以在制品未全部完成时就被调用只要有 tasks 存在也可以与制品更新交错进行——不被阶段锁死。八、Phase 10归档Archive变更完成后归档将其从openspec/changes/移动到openspec/changes/archive/YYYY-MM-DD-name/openspec archive name归档后的变更成为项目的决策历史——日后总能回溯理解某功能为什么这么建。.agents/skills/openspec-archive-change/SKILL.md 补充了归档前的四道检查制品是否全部doneopenspec status --change name --json、tasks.md 是否有未完成复选框、以及delta spec 与主规格的同步评估若 delta specs 存在需先对比openspec/specs/capability/spec.md并展示变更摘要提供 Sync now (recommended) / Archive without syncing 选项用户选择同步则走 openspec-sync-specs 逻辑然后无论如何继续归档。归档实现上等价于mkdir -p openspec/changes/archive mv openspec/changes/name openspec/changes/archive/YYYY-MM-DD-name目标目录已存在时直接报错建议改期或重命名。.openspec.yaml随目录一并移动得以保留。九、Phase 11复盘与命令参考一个完整周期包含八个环节Explore思考→ New创建容器→ ProposalWHY→ SpecsWHAT→ DesignHOW→ Tasks拆步→ Apply实现→ Archive留存记录。同样的节奏适用于任何规模的变更——小修复或大特性皆然。技能内置的完整命令参考表CommandWhat it does/opsx:exploreThink through problems before/during work/opsx:newStart a new change, step through artifacts/opsx:ffFast-forward: create all artifacts at once/opsx:continueContinue working on an existing change/opsx:applyImplement tasks from a change/opsx:verifyVerify implementation matches artifacts/opsx:archiveArchive a completed change其中/opsx:verify对应 .agents/skills/openspec-verify-change/SKILL.md从完整性任务与规格覆盖、正确性需求实现映射与场景覆盖、一致性设计遵循与代码模式三个维度生成报告问题分 CRITICAL / WARNING / SUGGESTION 三级且每条都必须附带具体、可执行的建议含文件/行号引用。启发式原则包括不确定时优先降级SUGGESTION WARNING CRITICAL和优雅降级——只有 tasks 时只查任务完成度有 tasks specs 时查前两维全套制品才查三维并始终注明跳过了哪些检查及原因。十、优雅退出中途停止与跳过教程onboard 技能为两类常见情况准备了兜底话术核心是不施压用户中途想停告知变更已保存于openspec/changes/name/后续可用/opsx:continue name续写制品、/opsx:apply name直接跳到实现若 tasks 已存在——工作不会丢随时回来。用户只想要命令速查直接给出精简版命令表CommandWhat it does/opsx:exploreThink through problems (no code changes)/opsx:new nameStart a new change, step by step/opsx:ff nameFast-forward: all artifacts at once/opsx:continue nameContinue an existing change/opsx:apply nameImplement tasks/opsx:verify nameVerify implementation/opsx:archive nameArchive when done十一、Guardrails教学式引导的七条铁律技能在结尾给出了引导式教学的核心纪律这也是评判 onboard 会话质量的标准遵循 EXPLAIN → DO → SHOW → PAUSE 模式在关键转换点探索后、proposal 草稿后、tasks 后、归档后必须暂停实现阶段旁白保持轻量教而不训teach without lecturing不跳阶段即使变更很小也要走完流程——目标是教学在标记点暂停确认但不过度暂停优雅处理退出绝不施压用户继续使用真实代码库任务不模拟、不用假例子温和调整范围引导走向更小的任务但尊重用户选择十二、在 ccg-workflow 中落地从 onboard 到完整协作工作流openspec-onboard 是整个 OpenSpec 技能族的第一课学完之后的进阶路径清晰可见用/opsx:new或/opsx:ff开启真实变更、用/opsx:continue续写、/opsx:apply实现、/opsx:verify校验、/opsx:archive归档、/opsx:sync同步规格。而在 ccg-workflow 项目中这套 OpenSpec 流程被进一步封装为多模型协作命令。仓库模板 templates/commands/spec-init.md 展示了完整的初始化与接力路径初始化后依次执行/ccg:spec-research description研究→/ccg:spec-plan规划与设计→/ccg:spec-impl实现内置自动评审与归档另有随时可用的独立双模型评审/ccg:spec-review。这些命令与 openspec-onboard 的关系可以这样理解onboard 解决学会 OpenSpec 节奏的问题CCG 封装命令解决在多模型协作中高效跑这个节奏的问题——规格框架来自 OPSX协作能力来自 CCG二者叠加正是本项目Claude 编排 Codex 后端 Gemini 前端多模型协作开发体系的根基。相关参考文件主文档 .agents/skills/openspec-onboard/SKILL.md配套技能 openspec-explore、openspec-new-change、openspec-ff-change、openspec-continue-change、openspec-apply-change、openspec-verify-change、openspec-archive-change、openspec-sync-specs以及 CCG 初始化命令模板 templates/commands/spec-init.md。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐基于 OpenSpec 工作流的变更归档实战ccg-workflow 中 openspec-archive-change 技能全解析基于 OpenSpec 工作流的变更归档实战ccg workflow 中 openspec archive change 技能全解析 本指南以 ccg wor基于 OpenSpec 的引导式变更工作流解读 riv/actors 仓库中的 openspec-onboard Agent 技能基于 OpenSpec 的引导式变更工作流解读 riv/actors 仓库中的 openspec onboard Agent 技能 本文面向希望为 AI 编码后端AI Agent人工智能流程编排WebSocketccg-workflow 中的 OpenSpec 变更实施技能openspec-apply-change 完整操作指南ccg workflow 中的 OpenSpec 变更实施技能openspec apply change 完整操作指南 导读 openspec apply c人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇10个Electron应用优化技巧Caprine开发者实战经验分享下一篇ffsend蓝绿部署策略零停机更新实现创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
