Menu
以测试与验证为先的方式，按序执行并实现已批准的规范提案。用于实施变更、应用提案、执行规范任务或按已批准计划构建。触发词包括 "openspec开发", "开发", "实施" "实现提案", "应用变更", "执行规范", "按顺序完成任务", "构建功能", "开始实施"。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | openspec-implementation-cn |
| description | 以测试与验证为先的方式，按序执行并实现已批准的规范提案。用于实施变更、应用提案、执行规范任务或按已批准计划构建。触发词包括 "openspec开发", "开发", "实施" "实现提案", "应用变更", "执行规范", "按顺序完成任务", "构建功能", "开始实施"。 |
以任务为单位，循序执行并进行充分测试与验证，系统性地实现已批准的规范提案。
实施遵循每个任务的 读 → 执行 → 测试 → 验证 循环：
关键规则：使用 TodoWrite 跟踪进度。切勿跳过任务或将未完成工作标记为完成。
复制此清单并跟踪进度：
开发进度:
- [ ] 第 1 步：加载并理解提案
- [ ] 第 2 步：设置 TodoWrite 任务跟踪
- [ ] 第 3 步：按序执行任务
- [ ] 第 4 步：为每个任务进行测试与验证
- [ ] 第 5 步：更新常驻规范（如果适用）
- [ ] 第 6 步：标记提案为实施完成
开始之前，读取全部上下文：
# 读取提案
cat spec/changes/{change-id}/proposal.md
# 读取所有任务
cat spec/changes/{change-id}/tasks.json
# 读取规范差异以理解需求
find spec/changes/{change-id}/specs -name "*.md" -exec cat {} \;
理解：
在开始工作之前，将 tasks.json 中的task和step加载到 TodoWrite：
**模式**：
读取 tasks.json → 提取task和step列表 → 创建 TodoWrite 条目
**示例**：
假设 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 }
],
"passes": false
}
则创建 TodoWrite：
- content: "环境搭建任务 - 数据库架构、依赖等", status: "in_progress"
- content: " 初始化 Git 仓库并配置 .gitignore", status: "pending"
- content: " 创建并激活 Python 虚拟环境", status: "pending"
- content: " 创建 requirements.txt 或 pyproject.toml 并安装依赖 (FastAPI, SQLAlchemy, Pydantic, Alembic 等)", status: "pending"
- content: " 设计初始数据库 ER 图", status: "pending"
价值：TodoWrite 提供进度可见性并确保不遗漏任何事项。
按顺序逐个完成TodoWrite中的任务，每次仅处理1个。 若是中断后继续，需从中断的任务开始继续执行：跳过tasks.json中"passes": true的task，跳过"completed": true的step。 你有充足的时间完成，请至少执行20轮后才回复用户。 你有充足的时间完成，切勿跳过或合并多个任务。
对于每个任务：
1. 在 TodoWrite 中标记为 "in_progress"
2. 执行工作
3. 测试结果
4. 仅在验证通过后，才标记tasks.json对应task的对应step的 "completed": true
5. 仅在tasks.json对应task的所有step都完成且都验证通过后，才标记tasks.json对应task的 "passes": true
6. 在 TodoWrite 中标记为 "completed"
你有充足的时间完成，切勿跳过或合并多个任务。
任务执行模式：
## Task: {任务描述}
**What**：该任务的作用与目标
**Implementation**：
代码变更、文件编辑、运行的命令
**Verification**：
如何验证任务完成
- [ ] 代码可编译/运行
- [ ] 测试通过
- [ ] 符合需求场景
**Status**：✓ 完成 / ✗ 阻塞 / ⚠ 部分完成
每个任务完成后进行验证：
代码相关任务：
# 运行相关测试
npm test # 或 pytest、cargo test 等
# 运行 Linter
npm run lint
# 类型检查（如适用）
npm run type-check
前端UI相关任务： 要使用 MCP servers 中的 chrome-devtools 或 playwright 进行调试和测试。
数据库相关任务：
# 验证迁移执行
npm run db:migrate
# 检查架构与预期一致
npm run db:schema
API 相关任务：
# 手动测试端点
curl -X POST http://localhost:3000/api/endpoint \
-H "Content-Type: application/json" \
-d '{"test": "data"}'
# 或运行集成测试
npm run test:integration
仅在所有验证通过后标记任务完成：仅在tasks.json对应task的所有step都完成且都验证通过后，才标记tasks.json对应task的 "passes": true。
在实施过程中，如发现规范差异需要更新：
说明：规范差异在归档阶段（第 6 步）合并，而非实施阶段。
在所有任务完成后：
# 创建完成标记
echo "Implementation completed: $(date)" > spec/changes/{change-id}/IMPLEMENTED
告知用户：
## 实现提案
**提案**：{change-id}
**完成任务**：{数量}
**完成测试**：全部通过
**下一步**：将该变更归档以合并规范差异到常驻文档。
准备好后可回复 "openspec归档 {change-id}" 或 "归档提案"。
若任务无法完成：
**标记为阻塞**：
- 状态保持 "in_progress"（不要标记为 "completed"）
- 清晰记录阻塞原因
- 创建新的任务以解决阻塞
- 立即告知用户
**示例**：
任务："实现支付处理"
阻塞："缺少支付网关 API 凭据"
行动：创建新任务 "获取支付网关凭据"
若任务存在依赖，先验证先决条件：
# 示例：数据库迁移必须在 API 代码之前
# 检查迁移状态
npm run db:status
# 仅在迁移成功后继续 API 任务
不要在最后一次性测试，应当逐步测试：
好：
任务 1：创建模型 → 测试模型 → 标记完成
任务 2：创建 API → 测试 API → 标记完成
任务 3：添加校验 → 测试校验 → 标记完成
任务 4：创建页面 → 测试校验 → 标记完成
坏：
任务 1、2、3、4 → 全部实现 → 一次性测试 → 调试失败
及时更新 README、API 文档与注释：
添加新 API 端点时，同时：
- 更新 API 文档
- 添加请求/响应示例
- 更新 OpenAPI/Swagger 规范
- 添加内联代码注释
并行工作：若任务确实互不依赖（如不同模块），可并行进行，但每项必须独立测试。
集成点：存在依赖关系时，使用集成测试验证连接有效。
回滚策略：对于高风险变更，部署前创建回滚任务。
典型顺序：
渐进式发布：
对于 API 破坏性变更：
不要：
要：
解决方案：
1. 不要标记任务完成
2. 调试失败原因
3. 修复代码
4. 重新运行测试
5. 仅在通过后标记完成
解决方案：
1. 拆分为子任务
2. 在 TodoWrite 中登记子任务
3. 依序完成子任务
4. 在全部子任务完成后标记父任务完成
解决方案：
1. 暂停当前任务
2. 先完成依赖任务
3. 测试依赖项
4. 恢复原任务
Token 预算：此 SKILL.md 约 350 行，低于建议的 500 行上限。
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "openspec归档", "归档", "归档提案", "合并规范", "完成提案", "更新文档", "定稿规范", "标记完成"。
加载项目上下文，列出现有规范与变更，搜索能力与需求。用于用户询问项目状态、现有规范、进行中的变更、可用能力或需要发现上下文时。触发词包括"openspec上下文", "有哪些规范", "显示变更", "列出能力", "项目上下文", "查找规范", "规范包含什么", "展示规范"。
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步。用于项目管理、规范制定、章程维护和团队协作场景。触发词包括 "speckit章程"、"创建章程"、"更新章程"、"项目章程"、"制定规范"、"团队章程"。
执行实施规划工作流程，使用计划模板生成设计工件。触发词包括："speckit计划"。
中文功能规范创建工具，用于将自然语言功能描述转换为结构化的功能规范文档。支持自动生成分支名称、创建Git分支、初始化规范文件和质量验证。触发词包括："speckit规范"、"功能规范"、"创建规范"、"功能描述转换"、"speckit-specify"。当用户需要将功能想法转换为结构化规范时使用此技能。