通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
使用规范驱动方法创建结构化变更提案。当用户说"规划"、"创建提案"或"新功能"时,生成 proposal.md、tasks.json 和 spec-delta.md 文件。
/plugin marketplace add forztf/open-skilled-sdd/plugin install open-skilled-sdd@open-skilled-sdd-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
reference/EARS_FORMAT.mdreference/VALIDATION_PATTERNS.mdtemplates/proposal.mdtemplates/spec-delta.mdtemplates/tasks.json遵循规范驱动开发方法,生成完整的变更提案。
创建规范提案包含三类输出:
基本流程:生成变更 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/tasks.json。
格式:
# 实施任务
```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
}
]
**最佳实践**:
- 每个任务可独立完成
- 为每个主要组件添加测试任务
- 为每个主要组件添加测试任务
- 包含测试与验证任务
- 按依赖排序(数据库先于 API 等)
- 通常 5-15 个任务;更多时应拆分
- 每次仅处理1个step
这是最关键步骤。规范差异使用 EARS 格式(易于需求语法)。
完整 EARS 指南见 reference/EARS_FORMAT.md
差异操作:
## ADDED Requirements - 新增能力## MODIFIED Requirements - 行为变更(包含完整更新文本)## REMOVED Requirements - 弃用功能基本需求结构:
## ADDED Requirements
### Requirement: 用户登录
WHEN 用户提交有效凭据,
系统 SHALL 认证用户并创建会话。
#### Scenario: 登录成功
GIVEN 用户邮箱为 "user@example.com" 且密码为 "correct123"
WHEN 用户提交登录表单
THEN 系统创建已认证会话
AND 重定向至仪表盘
用于验证的模式见 reference/VALIDATION_PATTERNS.md
在展示给用户前运行以下检查:
结构清单:
- [ ] 目录存在:`spec/changes/{change-id}/`
- [ ] proposal.md 包含 Why/What/Impact
- [ ] tasks.json 含编号任务列表(5-15 项)
- [ ] 规范差异包含操作标题(ADDED/MODIFIED/REMOVED)
- [ ] 需求遵循 `### Requirement: <name>` 格式
- [ ] 场景使用 `#### Scenario:` 格式(四个井号)
自动化检查:
# 统计差异操作(应 > 0)
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
清晰总结提案:
## Proposal Summary
**Change ID**:{change-id}
**Scope**:{简要描述}
**创建的文件**:
- spec/changes/{change-id}/proposal.md
- spec/changes/{change-id}/tasks.json
- spec/changes/{change-id}/specs/{capability}/spec-delta.md
**下一步**:
请评审提案。如认可或修正后,请回复 "openspec开发" 或 "按顺序完成任务" 开始实施。
EARS 格式细节:见 reference/EARS_FORMAT.md 验证模式:见 reference/VALIDATION_PATTERNS.md 完整示例:见 reference/EXAMPLES.md
新增能力时:
ADDED Requirements 差异修改既有行为时:
MODIFIED Requirements 差异移除功能时:
REMOVED Requirements 差异不要:
要:
所有模板位于 templates/ 目录:
Token 预算:此 SKILL.md 约 250 行,低于建议的 500 行上限。引用文件按需加载以逐步呈现。
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.