sdd-full 1.0.0 → 1.1.0

package/skills/release-flow/SKILL.md

@@ -0,0 +1,402 @@
+---
+name: "release-flow"
+description: "发布流程管理技能，管理整个发布生命周期。Invoke when you need to manage the full release lifecycle."
+---
+
+# release-flow - 发布流程管理技能
+
+## 概述
+
+本技能专注于管理整个发布生命周期，从发布计划到发布总结，确保发布过程规范、可控、可追溯。
+
+---
+
+## 与其他技能的衔接
+
+### 前置技能
+- **sdd-deploy** - 部署SDD已创建
+- **quality-gate** - 质量检查已通过
+
+### 后置技能
+- 发布完成
+- 复盘总结
+
+---
+
+## 核心功能
+
+### 1. 发布计划制定
+- 发布版本规划
+- 发布时间安排
+- 发布范围确定
+- 风险评估
+- 资源分配
+
+### 2. 发布风险评估
+- 功能风险分析
+- 技术风险分析
+- 业务风险分析
+- 风险等级判定
+- 风险应对措施
+
+### 3. 发布通知管理
+- 发布前通知
+- 发布中更新
+- 发布后通知
+- 异常通知
+- 通知记录
+
+### 4. 发布清单管理
+- 发布前检查清单
+- 发布中执行清单
+- 发布后验证清单
+- 回滚准备清单
+
+### 5. 发布后验证
+- 冒烟测试
+- 功能验证
+- 性能验证
+- 安全验证
+- 数据验证
+
+### 6. 发布回滚触发
+- 回滚触发条件
+- 回滚决策流程
+- 回滚执行监督
+- 回滚结果确认
+- 回滚记录
+
+### 7. 发布复盘流程
+- 发布情况总结
+- 问题分析
+- 经验教训
+- 改进计划
+- 流程优化建议
+
+---
+
+## 发布计划模板
+
+### 发布计划文档
+```markdown
+# 发布计划 - v1.0.0
+
+## 1. 发布概述
+- 版本号：v1.0.0
+- 发布时间：2024-01-01 14:00
+- 发布负责人：[姓名]
+- 发布类型：[新功能/修复/优化/重大变更]
+
+## 2. 发布内容
+### 新功能
+- 功能A：描述
+- 功能B：描述
+
+### 修复
+- Bug#123：描述
+- Bug#124：描述
+
+### 优化
+- 优化项1：描述
+- 优化项2：描述
+
+## 3. 发布时间安排
+| 时间节点 | 任务 | 负责人 |
+|---------|------|-------|
+| T-3天 | 发布计划确认 | 全员 |
+| T-2天 | 代码冻结 | 开发 |
+| T-1天 | 测试完成 | 测试 |
+| T-0天 | 发布执行 | 运维 |
+| T+1天 | 发布验证 | 全员 |
+
+## 4. 风险评估
+| 风险 | 等级 | 概率 | 影响 | 应对措施 |
+|-----|------|------|------|---------|
+| 数据库迁移失败 | P0 | 低 | 严重 | 准备回滚脚本，提前测试 |
+| 第三方服务异常 | P1 | 中 | 重要 | 提前沟通，准备降级方案 |
+
+## 5. 回滚计划
+- 回滚触发条件：见回滚方案
+- 回滚窗口：发布后24小时内
+- 回滚责任人：[姓名]
+```
+
+---
+
+## 发布检查清单模板
+
+### 发布前检查清单
+```markdown
+# 发布前检查清单 - v1.0.0
+
+## 代码检查
+- [ ] 所有代码已合并到发布分支
+- [ ] 无未提交代码
+- [ ] 代码已通过评审
+- [ ] 无已知阻断性bug
+
+## 测试检查
+- [ ] 所有测试用例通过
+- [ ] 测试覆盖率达标
+- [ ] 性能测试通过
+- [ ] 安全测试通过
+
+## 文档检查
+- [ ] 更新日志已编写
+- [ ] 用户文档已更新
+- [ ] API文档已更新
+- [ ] 运维文档已准备
+
+## 发布准备
+- [ ] 回滚方案已准备
+- [ ] 数据备份已完成
+- [ ] 监控告警已配置
+- [ ] 发布通知已发送
+- [ ] 相关人员已到位
+
+## 审批
+- [ ] 发布计划已审批
+- [ ] 风险评估已完成
+- [ ] 业务方同意发布
+- [ ] 负责人已签字
+```
+
+---
+
+## 发布记录模板
+
+### 发布记录文档
+```markdown
+# 发布记录 - v1.0.0
+
+## 1. 基本信息
+- 版本号：v1.0.0
+- 发布时间：2024-01-01 14:00
+- 发布耗时：30分钟
+- 发布状态：[成功/部分成功/失败/回滚]
+- 发布人：[姓名]
+
+## 2. 发布执行记录
+| 时间 | 操作 | 执行结果 | 备注 |
+|-----|------|---------|------|
+| 14:00 | 开始发布 | - | - |
+| 14:05 | 数据库迁移 | 成功 | - |
+| 14:15 | 部署应用 | 成功 | - |
+| 14:25 | 冒烟测试 | 成功 | - |
+| 14:30 | 发布完成 | 成功 | - |
+
+## 3. 发布后验证
+- [ ] 功能正常
+- [ ] 性能达标
+- [ ] 监控正常
+- [ ] 日志无错误
+- [ ] 用户反馈正常
+
+## 4. 问题记录
+| 问题 | 严重程度 | 处理方式 | 状态 |
+|-----|---------|---------|------|
+| 问题A | 轻微 | 后续修复 | 待处理 |
+
+## 5. 发布总结
+- 发布是否顺利：[是/否]
+- 主要问题：[描述]
+- 下次改进：[建议]
+```
+
+---
+
+## 回滚记录模板
+
+### 回滚记录文档
+```markdown
+# 回滚记录 - v1.0.0
+
+## 1. 回滚概述
+- 原发布版本：v1.0.0
+- 回滚到版本：v0.9.0
+- 回滚时间：2024-01-01 15:00
+- 回滚原因：[描述]
+- 回滚负责人：[姓名]
+
+## 2. 回滚触发条件
+- [ ] 核心功能不可用
+- [ ] 性能严重下降
+- [ ] 数据错误
+- [ ] 用户投诉激增
+
+## 3. 回滚执行记录
+| 时间 | 操作 | 执行结果 | 备注 |
+|-----|------|---------|------|
+| 15:00 | 触发回滚决策 | - | - |
+| 15:05 | 停止服务 | 成功 | - |
+| 15:10 | 恢复数据 | 成功 | - |
+| 15:20 | 部署旧版本 | 成功 | - |
+| 15:25 | 验证功能 | 成功 | - |
+| 15:30 | 回滚完成 | 成功 | - |
+
+## 4. 回滚结果验证
+- [ ] 应用版本正确
+- [ ] 数据恢复正常
+- [ ] 功能正常
+- [ ] 性能正常
+- [ ] 监控正常
+
+## 5. 回滚原因分析
+- 根因：[描述]
+- 预防措施：[建议]
+
+## 6. 后续计划
+- 修复问题：[时间]
+- 重新发布：[时间]
+```
+
+---
+
+## 发布复盘模板
+
+### 发布复盘文档
+```markdown
+# 发布复盘 - v1.0.0
+
+## 1. 复盘基本信息
+- 复盘时间：2024-01-02
+- 参与人员：[名单]
+- 发布版本：v1.0.0
+- 发布时间：2024-01-01
+- 发布结果：[成功/部分成功/失败/回滚]
+
+## 2. 发布情况总结
+### 做得好的
+- [ ] 方面1：描述
+- [ ] 方面2：描述
+
+### 可以改进的
+- [ ] 方面3：描述
+- [ ] 方面4：描述
+
+## 3. 问题分析
+| 问题 | 根因 | 影响 | 建议 |
+|-----|------|------|------|
+| 问题1 | 描述 | 描述 | 建议 |
+| 问题2 | 描述 | 描述 | 建议 |
+
+## 4. 经验教训
+- 教训1：描述
+- 教训2：描述
+- 教训3：描述
+
+## 5. 改进计划
+### 短期改进（1-2周）
+- [ ] 改进项1：负责人 - 截止时间
+- [ ] 改进项2：负责人 - 截止时间
+
+### 中期改进（1-2月）
+- [ ] 改进项3：负责人 - 截止时间
+- [ ] 改进项4：负责人 - 截止时间
+
+## 6. 流程优化建议
+- 建议1：描述
+- 建议2：描述
+- 建议3：描述
+
+## 7. 行动计划
+| 行动项 | 负责人 | 截止日期 | 状态 |
+|-------|-------|---------|------|
+| 行动1 | [姓名] | 2024-01-10 | 待开始 |
+| 行动2 | [姓名] | 2024-01-20 | 待开始 |
+```
+
+---
+
+## 发布生命周期管理
+
+### 发布状态流转
+```
+规划中 → 准备中 → 已就绪 → 发布中 → 已发布 → 验证中 → 已完成
+                        ↓
+                      回滚中 → 已回滚
+```
+
+### 发布阶段说明
+| 阶段 | 描述 | 关键动作 |
+|-----|------|---------|
+| 规划中 | 发布计划制定 | 制定计划、风险评估 |
+| 准备中 | 发布准备 | 代码冻结、测试完成 |
+| 已就绪 | 准备好发布 | 检查清单完成、审批通过 |
+| 发布中 | 执行发布 | 执行部署、监控状态 |
+| 已发布 | 发布完成 | 发布执行完成 |
+| 验证中 | 发布后验证 | 冒烟测试、功能验证 |
+| 已完成 | 发布结束 | 验证通过、复盘总结 |
+| 回滚中 | 执行回滚 | 触发回滚、执行回滚 |
+| 已回滚 | 回滚完成 | 回滚验证、分析总结 |
+
+---
+
+## 使用步骤
+
+### 步骤1：发布规划
+- 制定发布计划
+- 评估发布风险
+- 确定发布内容
+- 安排发布时间
+
+### 步骤2：发布准备
+- 完成代码冻结
+- 确保测试通过
+- 准备发布清单
+- 发送发布通知
+
+### 步骤3：执行发布
+- 执行发布检查清单
+- 执行发布操作
+- 监控发布状态
+- 处理发布问题
+
+### 步骤4：发布验证
+- 执行冒烟测试
+- 验证功能正常
+- 检查监控数据
+- 收集用户反馈
+
+### 步骤5：发布总结
+- 记录发布情况
+- 进行发布复盘
+- 总结经验教训
+- 制定改进计划
+
+---
+
+## 与其他技能的集成
+
+### 与sdd-deploy集成
+```
+sdd-deploy → 部署SDD → release-flow → 发布计划
+```
+
+### 与quality-gate集成
+```
+quality-gate → 质量通过 → release-flow → 发布执行
+```
+
+---
+
+## 最佳实践
+
+1. 每个发布都要有计划
+2. 发布前一定要有回滚方案
+3. 发布后要及时验证和总结
+4. 发布记录要完整可追溯
+5. 定期回顾和优化发布流程
+
+---
+
+## 常见问题
+
+### Q：什么时候可以发布？
+A：质量门禁通过，风险可控，相关方同意，准备工作完成
+
+### Q：发布中遇到问题怎么办？
+A：首先评估问题严重性，小问题继续发布并记录，严重问题考虑暂停或回滚
+
+### Q：发布后多久可以确认没问题？
+A：通常观察24-48小时，重点监控前几小时，有问题及时发现和处理

package/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: requesting-code-review
+description: 在完成任务、实现主要功能或合并前使用，以验证工作是否满足要求
+---
+
+# 请求代码审查
+
+调度 superpowers:code-reviewer 子代理，在问题扩散前捕获它们。审查者获得精确设计的评估上下文 - 绝不是你的会话历史。这使审查者专注于工作产品，而不是你的思考过程，并保留你自己的上下文以继续工作。
+
+**核心原则：** 尽早审查，经常审查。
+
+## 何时请求审查
+
+**必须：**
+- 子代理驱动开发中的每个任务后
+- 完成主要功能后
+- 合并到 main 之前
+
+**可选但有价值：**
+- 卡住时（新鲜视角）
+- 重构前（基线检查）
+- 修复复杂错误后
+
+## 如何请求
+
+**1. 获取 git SHAs：**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. 调度代码审查子代理：**
+
+使用 Task 工具与 superpowers:code-reviewer 类型，填写 `code-reviewer.md` 中的模板
+
+**占位符：**
+- `{WHAT_WAS_IMPLEMENTED}` - 你刚刚构建的内容
+- `{PLAN_OR_REQUIREMENTS}` - 它应该做什么
+- `{BASE_SHA}` - 起始提交
+- `{HEAD_SHA}` - 结束提交
+- `{DESCRIPTION}` - 简短摘要
+
+**3. 根据反馈行动：**
+- 立即修复关键问题
+- 在继续之前修复重要问题
+- 记录次要问题以便以后处理
+- 如果审查者错误，反驳（带有理由）
+
+## 示例
+
+```
+[刚刚完成任务 2：添加验证函数]
+
+你：让我在继续之前请求代码审查。
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[调度 superpowers:code-reviewer 子代理]
+  WHAT_WAS_IMPLEMENTED: 对话索引的验证和修复函数
+  PLAN_OR_REQUIREMENTS: docs/superpowers/plans/deployment-plan.md 中的任务 2
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: 添加了 verifyIndex() 和 repairIndex()，具有 4 种问题类型
+
+[子代理返回]:
+  优势：干净的架构，真实测试
+  问题：
+    重要：缺少进度指示器
+    次要：报告间隔的魔法数字 (100)
+  评估：可以继续
+
+你：[修复进度指示器]
+[继续到任务 3]
+```
+
+## 与工作流集成
+
+**子代理驱动开发：**
+- 每个任务后审查
+- 在问题复合前捕获它们
+- 在移至下一个任务前修复
+
+**执行计划：**
+- 每批（3 个任务）后审查
+- 获取反馈，应用，继续
+
+**临时开发：**
+- 合并前审查
+- 卡住时审查
+
+## 红旗
+
+**永远不要：**
+- 因为"简单"而跳过审查
+- 忽略关键问题
+- 带着未修复的重要问题继续
+- 与有效的技术反馈争论
+
+**如果审查者错误：**
+- 用技术推理反驳
+- 展示证明它有效的代码/测试
+- 请求澄清
+
+请参阅模板：requesting-code-review/code-reviewer.md

package/skills/requirement-completion-officer/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: 需求补全
+description: Analyzes user requirements, identifies missing information, and asks core questions to complete the requirements. Invoke when user presents a new project or feature request that needs clarification.
+---
+
+# 需求补全官
+
+## 核心功能
+
+本技能用于分析用户提出的需求，识别其中缺失的关键信息，并按优先级提出最核心的问题，帮助用户补全需求，为后续的方案设计和实现提供清晰的指导。
+
+## 执行规则
+
+1. **禁止立刻给方案**：当用户提出需求时，首先进行分析，不直接提供解决方案
+2. **识别缺失信息**：判断需求中缺失的关键信息
+3. **优先级提问**：按优先级只问最核心的3-7个问题，不冗余
+4. **主动补全维度**：重点覆盖以下维度：
+   - 核心目标
+   - 服务对象
+   - 使用场景与约束
+   - 输入与输出要求
+   - 成功验收标准
+   - 时间/预算限制
+   - 技术/资源限制
+   - 风险边界与必选/可选要求
+5. **结构化梳理**：若需求模糊，先结构化梳理为：
+   - 目标
+   - 已知条件
+   - 缺失信息
+   - 建议补充项
+6. **信息完整后再输出方案**：确保信息完整后，再输出正式方案
+7. **不擅自补设定**：不确定的信息直接询问用户
+8. **输出风格**：短、直接、结构化
+
+## 使用流程
+
+1. **接收需求**：用户提出新的项目或功能需求
+2. **初步分析**：快速浏览需求，判断是否清晰完整
+3. **结构化梳理**：将需求拆解为目标、已知条件、缺失信息和建议补充项
+4. **优先级提问**：针对缺失信息，按重要性提出3-7个核心问题
+5. **收集反馈**：等待用户回答问题
+6. **信息整合**：根据用户反馈，整合完整的需求信息
+7. **方案输出**：信息完整后，输出正式的解决方案
+
+## 应用场景
+
+- 产品经理提出新功能需求
+- 开发人员需要明确项目范围
+- 设计师需要了解设计约束
+- 项目管理者需要确定项目边界
+
+## 输出格式示例
+
+### 需求分析
+
+**目标**：
+- [用户提出的核心目标]
+
+**已知条件**：
+- [已明确的需求信息]
+
+**缺失信息**：
+- [需要补充的关键信息]
+
+**建议补充项**：
+- [建议用户提供的额外信息]
+
+### 核心问题
+
+1. [问题1]
+2. [问题2]
+3. [问题3]
+4. [问题4]
+5. [问题5]
+
+## 注意事项
+
+- 保持客观中立，不偏向任何特定解决方案
+- 聚焦于需求本身，不深入技术实现细节
+- 尊重用户的专业知识，避免提出过于基础的问题
+- 及时调整问题优先级，根据用户反馈动态调整分析方向
+- 确保所有问题都与需求的核心目标相关
+
+## 示例
+
+### 输入
+用户："我需要一个电商APP的购物车功能"
+
+### 输出
+
+**需求分析**
+
+**目标**：
+- 实现电商APP的购物车功能
+
+**已知条件**：
+- 应用类型：电商APP
+- 功能模块：购物车
+
+**缺失信息**：
+- 核心目标：购物车的具体功能需求和业务逻辑
+- 服务对象：目标用户群体
+- 使用场景：用户如何添加、管理和结算商品
+- 输入与输出：商品添加方式和结算流程
+- 成功验收标准：功能验证方法
+- 技术/资源限制：技术栈和开发资源
+- 风险边界：异常处理和边界情况
+
+**建议补充项**：
+- 与其他模块的集成需求
+- 性能要求和响应时间
+- 安全考虑和数据保护
+
+**核心问题**
+
+1. 购物车需要支持哪些核心功能？（如添加商品、修改数量、删除商品、优惠券使用等）
+2. 目标用户群体是什么？（如普通消费者、企业用户等）
+3. 购物车的使用场景有哪些？（如移动端、PC端、不同网络环境等）
+4. 购物车与结算流程的集成方式是什么？
+5. 有哪些技术栈和开发资源限制？
+6. 性能要求是什么？（如响应时间、并发处理能力等）
+7. 有哪些安全和数据保护要求？