菜单
规格驱动开发(SDD)。实现任何功能或改动时使用——写代码前先就规格达成一致:在 openspec/changes/<id>/ 写 proposal、spec deltas、tasks(复杂时加 design),对齐后再严格按规格实现,完成后把 delta 归档进基线 specs/。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | openspec |
| description | 规格驱动开发(SDD)。实现任何功能或改动时使用——写代码前先就规格达成一致:在 openspec/changes/<id>/ 写 proposal、spec deltas、tasks(复杂时加 design),对齐后再严格按规格实现,完成后把 delta 归档进基线 specs/。 |
| license | MIT |
| source | https://github.com/Fission-AI/OpenSpec |
提炼自官方 OpenSpec(https://github.com/Fission-AI/OpenSpec)的约定、文件格式与流程。 核心:"Agree before you build" —— 改动的行为规格写清楚、与用户对齐后,再写实现代码。
openspec/
specs/ # 真相基线:系统【当前】如何工作(按 capability 分)
<capability>/spec.md
changes/ # 提案:对基线的【改动】,每个改动一个文件夹
<change-id>/
proposal.md # 为什么 + 改什么
design.md # 可选,仅复杂改动写(技术方案/取舍)
tasks.md # 实现清单
specs/<capability>/spec.md # 该改动对规格的 DELTA(ADDED/MODIFIED/REMOVED)
specs/ 是源头真相;changes/<id>/ 是尚未合并的改动。归档时 change 的 delta 合并进 specs/。
## Why
<动机:为什么要这个改动>
## What Changes
### 1. <子改动>
<说明>
### 2. <子改动>
...
## 1. <分组>
- [ ] 1.1 <小而可验证的任务>
- [ ] 1.2 ...
## 2. <分组>
- [ ] 2.1 ...
按 ADDED / MODIFIED / REMOVED / RENAMED 标 delta;每条 Requirement 用 SHALL,且至少含一个 Scenario:
## ADDED Requirements
### Requirement: <名称>
<The system SHALL ...>
#### Scenario: <场景名>
- **WHEN** <条件>
- **THEN** <预期>
- **AND** <附加预期>
## MODIFIED Requirements
### Requirement: <已存在的需求名>
<改后的 SHALL 描述 + 场景>
## REMOVED Requirements
### Requirement: <要删除的需求名>
绝不用 README.md 或自由 bullet 代替——必须是 spec.md,且用上面的 Requirement + Scenario(WHEN/THEN)结构。
仅当改动复杂、需要记录架构 / 关键决策 / 取舍时才写;简单改动跳过。
openspec/changes/<change-id>/ 建文件夹,写 proposal.md +(需要时)design.md + tasks.md + specs/<capability>/spec.md(delta)。分成"短到能读完"的小块给用户看,迭代到对齐。tasks.md 逐项实现,严格遵循 spec delta;每完成勾掉。若现实迫使偏离规格,先停下更新规格、重新对齐,别默默跑偏。openspec/specs/ 基线,并把 change 文件夹移入归档(如 openspec/changes/archive/)。
ADDED → 把该 Requirement 加入基线;MODIFIED → 用新内容替换基线里同名 Requirement;REMOVED → 从基线删除该 Requirement。## ADDED/MODIFIED/REMOVED 是只属于 change 里那份 delta 的标记。基线 specs/<capability>/spec.md 是当前真相,只保留当前的 Requirements / Scenario,不要带这些 delta 标记(用 ## Requirements 或直接列 ### Requirement: 即可)。换句话说:归档是"把 delta 应用进基线",不是"把 delta 整份拷进基线"。spec.md + 官方 Requirement/Scenario 格式,不是 README、不是自由条目。说明:deepx 无内置
openspecCLI;本 skill 把官方 OpenSpec 的目录结构、文件格式与流程落到普通文件操作上(在仓库里建openspec/目录与上述文件)。需要原生 CLI 体验(openspec init/propose/archive、校验)可另装官方工具。
当用户想「创建/生成一个 workflow(可复用的多子-agent 编排脚本)」时使用。讲清 deepx workflow 的 JavaScript 脚本格式、可用 API,以及如何用 Workflow 工具保存与运行。
当面对 2 个及以上彼此独立、无共享状态、无先后依赖、可并行处理的任务时使用。
当已有一份写好的实现计划、需要分步执行并在检查点处复核时使用。
当实现完成、测试全过、需要决定如何收尾集成时使用——给出合并 / 提 PR / 清理等结构化选项,引导完成开发收尾。
做有辨识度、生产级、高设计质量的前端界面。当用户要构建网页组件、页面、海报或应用(网站、落地页、仪表盘、React 组件、HTML/CSS 布局,或美化任何 Web UI)时使用。产出有创意、精致、避免千篇一律 AI 风格的代码与界面。
减少 LLM 常见编码错误的行为准则。在写代码、审查或重构时使用:避免过度复杂、做最小化精准改动、显式暴露假设、定义可验证的成功标准。