sdd-full 4.2.0 → 4.3.1

package/skills/release-ops/finishing-a-development-branch/SKILL.md

@@ -0,0 +1,202 @@
+【claude code调用标识：finishing-a-development-branch】【trae调用标识：finishing-a-development-branch+完成开发分支】【流程场景：5.代码发布】
+
+---
+name: finishing-a-development-branch
+description: 当实现完成、所有测试通过且你需要决定如何集成工作时使用 - 通过呈现合并、PR 或清理的结构化选项来指导开发工作的完成
+---
+
+# 完成开发分支
+
+## 概述
+
+通过呈现清晰的选项并处理选定的工作流来指导开发工作的完成。
+
+**核心原则：** 验证测试 → 呈现选项 → 执行选择 → 清理。
+
+**开始时宣布：** "我正在使用 finishing-a-development-branch 技能来完成这项工作。"
+
+## 流程
+
+### 步骤 1：验证测试
+
+**在呈现选项之前，验证测试通过：**
+
+```bash
+# 运行项目的测试套件
+npm test / cargo test / pytest / go test ./...
+```
+
+**如果测试失败：**
+```
+测试失败（<N> 个失败）。完成前必须修复：
+
+[显示失败]
+
+在测试通过之前无法继续合并/PR。
+```
+
+停止。不要继续到步骤 2。
+
+**如果测试通过：** 继续到步骤 2。
+
+### 步骤 2：确定基础分支
+
+```bash
+# 尝试常见的基础分支
+git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
+```
+
+或询问："此分支从 main 分支分离 - 是否正确？"
+
+### 步骤 3：呈现选项
+
+呈现以下 4 个选项：
+
+```
+实现完成。你想做什么？
+
+1. 本地合并回 <base-branch>
+2. 推送并创建 Pull Request
+3. 保持分支不变（我稍后处理）
+4. 放弃此工作
+
+选择哪个选项？
+```
+
+**不要添加解释** - 保持选项简洁。
+
+### 步骤 4：执行选择
+
+#### 选项 1：本地合并
+
+```bash
+# 切换到基础分支
+git checkout <base-branch>
+
+# 拉取最新
+git pull
+
+# 合并功能分支
+git merge <feature-branch>
+
+# 验证合并结果的测试
+<test command>
+
+# 如果测试通过
+git branch -d <feature-branch>
+```
+
+然后：清理 worktree（步骤 5）
+
+#### 选项 2：推送并创建 PR
+
+```bash
+# 推送分支
+git push -u origin <feature-branch>
+
+# 创建 PR
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+## 摘要
+<2-3 个要点说明更改内容>
+
+## 测试计划
+- [ ] <验证步骤>
+EOF
+)"
+```
+
+然后：清理 worktree（步骤 5）
+
+#### 选项 3：保持不变
+
+报告："保持分支 <name>。Worktree 保存在 <path>。"
+
+**不要清理 worktree。**
+
+#### 选项 4：放弃
+
+**首先确认：**
+```
+这将永久删除：
+- 分支 <name>
+- 所有提交：<commit-list>
+- Worktree 位于 <path>
+
+输入 'discard' 确认。
+```
+
+等待确切的确认。
+
+如果确认：
+```bash
+git checkout <base-branch>
+git branch -D <feature-branch>
+```
+
+然后：清理 worktree（步骤 5）
+
+### 步骤 5：清理 Worktree
+
+**对于选项 1、2、4：**
+
+检查是否在 worktree 中：
+```bash
+git worktree list | grep $(git branch --show-current)
+```
+
+如果是：
+```bash
+git worktree remove <worktree-path>
+```
+
+**对于选项 3：** 保持 worktree。
+
+## 快速参考
+
+| 选项 | 合并 | 推送 | 保持 Worktree | 清理分支 |
+|------|------|------|---------------|----------|
+| 1. 本地合并 | ✓ | - | - | ✓ |
+| 2. 创建 PR | - | ✓ | ✓ | - |
+| 3. 保持不变 | - | - | ✓ | - |
+| 4. 放弃 | - | - | - | ✓ (强制) |
+
+## 常见错误
+
+**跳过测试验证**
+- **问题：** 合并损坏的代码，创建失败的 PR
+- **修复：** 在提供选项之前始终验证测试
+
+**开放式问题**
+- **问题：** "我接下来应该做什么？" → 模棱两可
+- **修复：** 呈现确切的 4 个结构化选项
+
+**自动 worktree 清理**
+- **问题：** 在可能需要时删除 worktree（选项 2、3）
+- **修复：** 仅为选项 1 和 4 清理
+
+**放弃时无确认**
+- **问题：** 意外删除工作
+- **修复：** 要求输入 "discard" 确认
+
+## 红旗
+
+**永远不要：**
+- 带着失败的测试继续
+- 不验证结果测试就合并
+- 未经确认删除工作
+- 未经明确请求强制推送
+
+**始终：**
+- 在提供选项之前验证测试
+- 呈现确切的 4 个选项
+- 为选项 4 获取输入确认
+- 仅为选项 1 和 4 清理 worktree
+
+## 集成
+
+**被调用：**
+- **subagent-driven-development**（步骤 7）- 所有任务完成后
+- **executing-plans**（步骤 5）- 所有批次完成后
+
+**配对：**
+- **using-git-worktrees** - 清理该技能创建的 worktree

package/skills/release-ops/release-flow/SKILL.md

@@ -0,0 +1,404 @@
+【claude code调用标识：release-flow】【trae调用标识：release-flow+发布流程管理】【流程场景：1.完整3阶段SDD流程、5.代码发布】
+
+---
+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小时，重点监控前几小时，有问题及时发现和处理