Summary
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
forztf/open-skilled-sdd
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引?
npx skills add forztf/open-skilled-sdd --skill openspec-proposal-creation-cn
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Propose a new change with all artifacts generated in one step. Use when the user wants to quick…
1.6K installsArchive a completed change in the experimental workflow. Use when the user wants to finalize an…
1.6K installsEnter explore mode - a thinking partner for exploring ideas, investigating problems, and clarif…
1.6K installsImplement tasks from an OpenSpec change. Use when the user wants to start implementing, continu…
1.6K installsUpdate an OpenSpec change by revising its existing planning artifacts and keeping them coherent…
1.6K installsSync delta specs from a change to main specs. Use when the user wants to update main specs with…
1.5K installsOther skills from forztf/open-skilled-sdd · top by installs.
npx skills add forztf/open-skilled-sdd
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
main
Files included with this skill beyond the listing page.
SKILL.md
7,849 B
SUMMARY.md
380 B
遵循规范驱动开发方法,生成完整的变更提案。
创建规范提案包含三类输出:
基本流程:生成变更 ID → 脚手架目录 → 起草提案 → 编写规范差异 → 验证结构
复制此清单并跟踪进度:
规划进度:
- [ ] 第 1 步:审阅现有规范
- [ ] 第 2 步:生成唯一的变更 ID
- [ ] 第 3 步:生成目录结构
- [ ] 第 4 步:起草 proposal.md(为什么、做什么、影响摘要)
- [ ] 第 5 步:创建 tasks.json 实施清单
- [ ] 第 6 步:编写 spec-delta.md 规范差异(ADDED/MODIFIED/REMOVED)
- [ ] 第 7 步:验证提案结构
- [ ] 第 8 步:向用户展示并请求审批
在创建提案前,了解当前状态:
# 列出所有现有规范
find spec/specs -name "spec.md" -type f
# 列出进行中的变更以避免冲突
find spec/changes -maxdepth 1 -type d -not -path "*/archive"
# 搜索相关需求
grep -r "### Requirement:" spec/specs/
选择具描述性、URL 安全的标识符:
格式:add-<feature>、fix-<issue>、update-<component>、remove-<feature>
示例:
add-user-authenticationfix-payment-validationupdate-api-rate-limitsremove-legacy-endpoints校验:检查是否冲突:
ls spec/changes/ | grep -i "<proposed-id>"
按标准结构创建变更目录:
# 将 {change-id} 替换为实际 ID
mkdir -p spec/changes/{change-id}/specs/{capability-name}
示例:
mkdir -p spec/changes/add-user-auth/specs/authentication
以 [templates/proposal.md](templates/proposal.md) 为起点。
必需章节:
语气:清晰、简洁、面向决策。避免不必要背景。
将实现拆分为具体、可测试的任务。使用 [templates/tasks.json](templates/tasks.json)。
格式:
# 实施任务
[ { "number": 1, "category": "阶段 1:基础设施", "task": "环境搭建任务 - 数据库架构、依赖等", "steps": [ { "step": "初始化 Git 仓库并配置 .gitignore", "completed": false }, { "step": "创建并激活 Python 虚拟环境", "completed": false }, { "step": "创建 requirements.txt 或 pyproject.toml 并安装依赖 (FastAPI, SQLAlchemy, Pydantic, Alembic 等)", "completed": false }, { "step": "设计初始数据库 ER 图", "completed": false }, { "step": "配置数据库连接字符串和环境变量 (.env)", "completed": false }, { "step": "初始化 Alembic 迁移环境", "completed": false } ], "passes": false } ]
最佳实践:
### 第 6 步:以 EARS 格式编写规范差异
这是最关键步骤。规范差异使用 **EARS 格式**(易于需求语法)。
**完整 EARS 指南**见 [reference/EARS_FORMAT.md](reference/EARS_FORMAT.md)
**差异操作**:
- `## ADDED Requirements` - 新增能力
- `## MODIFIED Requirements` - 行为变更(包含完整更新文本)
- `## REMOVED Requirements` - 弃用功能
**基本需求结构**:
WHEN 用户提交有效凭据, 系统 SHALL 认证用户并创建会话。
GIVEN 用户邮箱为 "[email protected]" 且密码为 "correct123" WHEN 用户提交登录表单 THEN 系统创建已认证会话 AND 重定向至仪表盘
**用于验证的模式**见 [reference/VALIDATION_PATTERNS.md](reference/VALIDATION_PATTERNS.md)
### 第 7 步:验证提案结构
在展示给用户前运行以下检查:
结构清单:
spec/changes/{change-id}/### Requirement: <name> 格式#### Scenario: 格式(四个井号)
**自动化检查**:
grep -c "## ADDED\|MODIFIED\|REMOVED" spec/changes/{change-id}/specs/**/*.md
grep -n "#### Scenario:" spec/changes/{change-id}/specs/**/*.md
grep -n "### Requirement:" spec/changes/{change-id}/specs/**/*.md
### 第 8 步:提交用户评审
清晰总结提案:
Change ID:{change-id} Scope:{简要描述}
创建的文件:
下一步: 请评审提案。如认可或修正后,请回复 "openspec开发" 或 "按顺序完成任务" 开始实施。
## 进阶主题
**EARS 格式细节**:见 [reference/EARS_FORMAT.md](reference/EARS_FORMAT.md)
**验证模式**:见 [reference/VALIDATION_PATTERNS.md](reference/VALIDATION_PATTERNS.md)
**完整示例**:见 [reference/EXAMPLES.md](reference/EXAMPLES.md)
## 常见模式
### 模式 1:新增功能提案
新增能力时:
- 使用 `ADDED Requirements` 差异
- 同时包含正向场景与错误处理
- 在场景中考虑边界情况
### 模式 2:破坏性变更提案
修改既有行为时:
- 使用 `MODIFIED Requirements` 差异
- 包含完整更新后的需求文本
- 在 proposal.md 中说明变更内容与原因
- 在 tasks.json 中考虑迁移任务
### 模式 3:弃用提案
移除功能时:
- 使用 `REMOVED Requirements` 差异
- 在 proposal.md 中记录移除理由
- 在 tasks.json 中包含清理任务
- 在影响部分考虑用户迁移
## 反模式避免
**不要**:
- 跳过验证检查(务必运行 grep 模式)
- 未先审阅现有规范就创建提案
- 使用含糊的任务描述(如"修一下")
- 编写不含场景的需求
- 忽略错误处理场景
- 在一个提案中混合多个无关变更
**要**:
- 在创建变更 ID 前检查冲突
- 编写具体、可测试的任务
- 同时包含正向与负向场景
- 一个提案只处理一个关注点
- 在展示前验证结构
## 文件模板
所有模板位于 `templates/` 目录:
- [proposal.md](templates/proposal.md) - 提案结构
- [tasks.json](templates/tasks.json) - 任务清单格式
- [spec-delta.md](templates/spec-delta.md) - 规范差异模板
## 参考资料
- [EARS_FORMAT.md](reference/EARS_FORMAT.md) - 完整 EARS 语法指南
- [VALIDATION_PATTERNS.md](reference/VALIDATION_PATTERNS.md) - Grep/bash 验证
- [EXAMPLES.md](reference/EXAMPLES.md) - 真实提案示例
---
**Token 预算**:此 SKILL.md 约 250 行,低于建议的 500 行上限。引用文件按需加载以逐步呈现。