Menü
Spec驱动的技能规范，所有变更和需求都需要有变更说明、变更方案、变更受益等规范文档
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
简洁风格技能，禁止废话，采用caveman式简短直接的表达方式
个人文档管理技能，管理变更记录、方案设计Spec文档、测试报告等，统一存放在docs目录下
项目启动管理技能，支持Java Spring Boot和Vue项目的启动、重启、关闭操作，保持原有端口不变
方案调研技能，对方案设计、功能实现进行多方案比对分析，至少3个方案，建议5个左右的方案比对，包括业界标杆方案、大厂实现方案等
基于OpenAPI规范生成API文档，支持Swagger UI和ReDoc展示
提供后端单元测试指导和生成能力，支持JUnit 5、Mockito等框架
| name | common-spec-driven |
| description | Spec驱动的技能规范，所有变更和需求都需要有变更说明、变更方案、变更受益等规范文档 |
| trigger | 需要对需求或变更进行规范管理时 |
| disable-when | 简单的代码修复或无需记录的小变更 |
| category | common |
| tags | ["spec","change","requirement","documentation","governance"] |
| requires | ["common-requirement-clarification"] |
Spec驱动的技能规范，确保所有需求变更、功能新增、技术改造都有完整的规范文档。包含变更说明、变更方案、变更受益、风险评估等核心要素。
定义变更的背景、原因和范围，确保所有相关人员理解变更的必要性。
详细描述变更的实现方案，包括技术选型、架构设计、接口定义等。
分析变更带来的业务价值和技术收益，量化评估变更效果。
识别变更可能带来的风险，制定缓解措施。
分析变更对系统各模块的影响，评估回归测试范围。
# [SPEC-XXX] 变更说明文档
## 1. 变更概述
- **变更编号**：SPEC-XXX
- **变更标题**：变更的简短描述
- **变更类型**：新增功能/需求变更/技术改造/Bug修复
- **优先级**：P0/P1/P2/P3
- **状态**：草稿/评审中/已批准/进行中/已完成
- **创建日期**：YYYY-MM-DD
- **负责人**：XXX
## 2. 变更背景
- 为什么需要这个变更？
- 当前存在什么问题？
- 业务驱动因素是什么？
## 3. 变更方案
### 3.1 技术方案
- 技术选型说明
- 架构设计图
- 核心类和方法设计
### 3.2 接口变更
- 新增/修改的 API 接口
- 参数变更说明
- 返回值变更说明
### 3.3 数据库变更
- 新增/修改的数据表
- 字段变更说明
- 数据迁移方案
### 3.4 部署方案
- 部署步骤
- 回滚方案
- 依赖版本要求
## 4. 变更受益
### 4.1 业务价值
- 提升的业务指标
- 用户体验改善
- 效率提升
### 4.2 技术收益
- 代码质量提升
- 架构优化
- 性能改善
### 4.3 量化指标
| 指标 | 变更前 | 变更后 | 提升幅度 |
|------|--------|--------|----------|
| 响应时间 | 500ms | 200ms | 60% |
## 5. 风险评估
| 风险项 | 风险等级 | 影响范围 | 缓解措施 |
|--------|----------|----------|----------|
| 数据库迁移失败 | 高 | 数据层 | 备份后迁移，准备回滚脚本 |
| 接口兼容性问题 | 中 | API层 | 提供版本兼容方案 |
## 6. 影响范围
### 6.1 模块影响
- [ ] 模块A
- [ ] 模块B
- [ ] 模块C
### 6.2 测试范围
- 新增测试用例数：XX
- 回归测试范围：XX
- 性能测试：是/否
## 7. 实施计划
| 阶段 | 时间 | 负责人 | 交付物 |
|------|------|--------|--------|
| 设计阶段 | YYYY-MM-DD | XXX | 技术方案文档 |
| 开发阶段 | YYYY-MM-DD | XXX | 代码提交 |
| 测试阶段 | YYYY-MM-DD | XXX | 测试报告 |
| 上线阶段 | YYYY-MM-DD | XXX | 上线验证 |
## 8. 验收标准
- [ ] 功能符合需求描述
- [ ] 性能指标达标
- [ ] 代码覆盖率 ≥ 80%
- [ ] 无重大 Bug
| 参数名 | 类型 | 必填 | 说明 |
|---|---|---|---|
| changeType | String | 是 | 变更类型：feature/change/refactor/bugfix |
| title | String | 是 | 变更标题 |
| description | String | 是 | 变更详细描述 |
| priority | String | 否 | 优先级：P0/P1/P2/P3，默认 P1 |
| owner | String | 否 | 负责人 |
| businessValue | String | 否 | 业务价值描述 |
{
"specId": "SPEC-001",
"title": "变更标题",
"changeType": "feature",
"priority": "P1",
"status": "draft",
"sections": {
"overview": {...},
"background": {...},
"solution": {...},
"benefits": {...},
"risks": [...],
"impact": {...},
"plan": [...],
"acceptance": [...]
},
"createdAt": "2024-01-15T10:00:00Z",
"owner": "张三"
}
需求提出 → Spec文档创建 → 方案评审 → 批准实施 → 开发测试 → 验收完成 → Spec归档
| 检查项 | 说明 | 状态 |
|---|---|---|
| 完整性 | Spec文档是否包含所有必需章节 | ✅/❌ |
| 清晰性 | 技术方案描述是否清晰 | ✅/❌ |
| 可行性 | 方案是否在技术和资源范围内可行 | ✅/❌ |
| 风险评估 | 是否识别了主要风险并制定缓解措施 | ✅/❌ |
| 验收标准 | 是否有明确可测试的验收标准 | ✅/❌ |
| 实施计划 | 是否有详细的实施计划和时间节点 | ✅/❌ |
| 类型 | 说明 | 适用场景 |
|---|---|---|
| feature | 新增功能 | 全新的业务功能开发 |
| change | 需求变更 | 现有功能的需求调整 |
| refactor | 技术改造 | 代码重构、架构优化 |
| bugfix | Bug修复 | 修复生产环境问题 |
| 优先级 | 说明 | 响应时间 |
|---|---|---|
| P0 | 紧急 - 影响核心业务 | 立即处理 |
| P1 | 高 - 影响重要功能 | 24小时内 |
| P2 | 中 - 一般功能变更 | 7天内 |
| P3 | 低 - 优化改进 | 按需安排 |
无需额外配置，基于模板引擎生成 Spec 文档。