sdd-full 1.0.0 → 1.2.0

package/skills/quality-gate/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: "quality-gate"
+description: "质量门禁技能，执行质量检查确保代码质量。Invoke when you need to run quality checks before deployment."
+---
+
+# quality-gate - 质量门禁技能
+
+## 概述
+
+本技能专注于执行质量检查，确保代码质量、测试覆盖、性能基准、安全标准等达到要求，作为发布前的最后一道关卡。
+
+---
+
+## 与其他技能的衔接
+
+### 前置技能
+- **sdd-code** - 代码已完成
+- **sdd-test** - 测试已完成
+
+### 后置技能
+- **sdd-deploy** - 部署执行
+
+---
+
+## 核心功能
+
+### 1. 代码质量检查
+- 代码规范检查
+- 静态代码分析
+- 代码复杂度分析
+- 代码重复检查
+
+### 2. 测试覆盖率检查
+- 单元测试覆盖率
+- 集成测试覆盖率
+- E2E测试覆盖率
+- 覆盖率趋势分析
+
+### 3. 性能基准检查
+- 响应时间基准
+- 吞吐量基准
+- 资源使用基准
+- 性能回归检查
+
+### 4. 安全漏洞扫描
+- 依赖安全检查
+- 静态安全扫描
+- 动态安全扫描
+- 安全配置检查
+
+### 5. 代码评审检查
+- 代码评审覆盖率
+- 评审意见处理
+- 评审流程合规性
+- 评审质量评估
+
+### 6. 文档完整性检查
+- 需求文档完整性
+- 设计文档完整性
+- API文档完整性
+- 用户文档完整性
+
+### 7. 发布前预检清单
+- 综合质量评估
+- 风险评估
+- 发布准备检查
+- 最终决策支持
+
+---
+
+## 检查清单模板
+
+### 代码质量检查清单
+```markdown
+# 代码质量检查清单
+
+## 代码规范检查
+- [ ] 代码符合项目编码规范
+- [ ] 命名规范（变量、函数、类）
+- [ ] 代码注释充分
+- [ ] 代码格式统一
+
+## 静态代码分析
+- [ ] 无高危告警
+- [ ] 无严重bug
+- [ ] 代码复杂度合理
+- [ ] 无潜在性能问题
+
+## 代码复杂度
+- [ ] 函数圈复杂度 < 10
+- [ ] 类职责单一
+- [ ] 模块耦合度低
+- [ ] 代码可读性良好
+
+## 代码重复检查
+- [ ] 代码重复率 < 5%
+- [ ] 无大面积重复代码
+- [ ] 公共逻辑已抽取
+```
+
+---
+
+### 测试覆盖率检查清单
+```markdown
+# 测试覆盖率检查清单
+
+## 单元测试覆盖
+- [ ] 语句覆盖率 ≥ 80%
+- [ ] 分支覆盖率 ≥ 75%
+- [ ] 函数覆盖率 ≥ 90%
+- [ ] 核心模块覆盖率 ≥ 95%
+
+## 集成测试覆盖
+- [ ] 主要接口都有测试
+- [ ] 核心业务流程有测试
+- [ ] 异常场景有测试
+
+## E2E测试覆盖
+- [ ] 核心用户旅程有测试
+- [ ] 关键功能路径有测试
+- [ ] 兼容性测试已完成
+
+## 覆盖率趋势
+- [ ] 覆盖率不低于上次发布
+- [ ] 无明显覆盖率下降
+- [ ] 新增代码有测试覆盖
+```
+
+---
+
+### 性能基准检查清单
+```markdown
+# 性能基准检查清单
+
+## 响应时间
+- [ ] API响应时间 ≤ 500ms（P95）
+- [ ] 页面加载时间 ≤ 2s
+- [ ] 数据库查询时间 ≤ 100ms
+- [ ] 关键操作响应时间达标
+
+## 吞吐量
+- [ ] 系统吞吐量 ≥ 100 TPS
+- [ ] 数据库吞吐量达标
+- [ ] 缓存命中率 ≥ 90%
+
+## 资源使用
+- [ ] CPU使用率 ≤ 70%（峰值）
+- [ ] 内存使用率 ≤ 80%（峰值）
+- [ ] 磁盘IO正常
+- [ ] 网络带宽正常
+
+## 性能回归
+- [ ] 性能不低于上一版本
+- [ ] 无明显性能下降
+- [ ] 性能瓶颈已识别
+```
+
+---
+
+### 安全漏洞扫描清单
+```markdown
+# 安全漏洞扫描清单
+
+## 依赖安全
+- [ ] 无已知高危漏洞
+- [ ] 依赖版本较新
+- [ ] 不再使用的依赖已移除
+
+## 静态安全扫描
+- [ ] 无高危安全问题
+- [ ] 输入验证完整
+- [ ] SQL注入防护到位
+- [ ] XSS防护到位
+
+## 动态安全扫描
+- [ ] 常见攻击测试通过
+- [ ] 认证授权机制安全
+- [ ] 数据传输加密
+- [ ] 敏感数据保护到位
+
+## 安全配置
+- [ ] 安全配置符合规范
+- [ ] 日志记录完整
+- [ ] 权限设置合理
+- [ ] 应急响应机制完善
+```
+
+---
+
+### 代码评审检查清单
+```markdown
+# 代码评审检查清单
+
+## 评审覆盖率
+- [ ] 所有代码都已评审
+- [ ] 核心代码多轮评审
+- [ ] 跨团队代码有评审
+
+## 评审意见处理
+- [ ] 所有评审意见已回复
+- [ ] 合理建议已采纳
+- [ ] 有争议的问题已解决
+
+## 评审流程合规性
+- [ ] 评审流程按规范执行
+- [ ] 评审记录完整
+- [ ] 评审时间合理
+
+## 评审质量
+- [ ] 评审发现真实问题
+- [ ] 评审建议有价值
+- [ ] 评审者资质符合要求
+```
+
+---
+
+### 文档完整性检查清单
+```markdown
+# 文档完整性检查清单
+
+## 需求文档
+- [ ] 需求描述清晰完整
+- [ ] 验收标准明确
+- [ ] 边界条件覆盖
+- [ ] 依赖关系说明清晰
+
+## 设计文档
+- [ ] 架构设计文档完整
+- [ ] 接口设计文档完整
+- [ ] 数据库设计文档完整
+- [ ] 关键设计决策有记录
+
+## API文档
+- [ ] API接口文档完整
+- [ ] 请求响应示例齐全
+- [ ] 错误码定义清晰
+- [ ] 版本说明清晰
+
+## 用户文档
+- [ ] 用户使用说明完整
+- [ ] 常见问题解答齐全
+- [ ] 更新日志完整
+- [ ] 文档与代码同步
+```
+
+---
+
+## 质量门判定标准
+
+### 通过标准
+- [ ] 所有检查项通过（P0-P1）
+- [ ] 测试覆盖率达标
+- [ ] 性能指标达标
+- [ ] 无高危安全漏洞
+- [ ] 风险可控
+
+### 条件通过标准
+- [ ] 少数P2项未通过但不影响发布
+- [ ] 有明确的后续修复计划
+- [ ] 风险评估通过
+- [ ] 相关负责人同意
+
+### 不通过标准
+- [ ] 任何P0项未通过
+- [ ] 存在阻断性bug
+- [ ] 测试覆盖率严重不足
+- [ ] 存在高危安全漏洞
+- [ ] 性能严重不达标
+
+---
+
+## 风险评估矩阵
+
+| 风险等级 | 严重程度 | 可能性 | 处理策略 |
+|---------|---------|--------|---------|
+| P0 | 严重 | 高 | 必须修复 |
+| P0 | 严重 | 中 | 必须修复 |
+| P0 | 严重 | 低 | 评估后决策 |
+| P1 | 重要 | 高 | 尽量修复 |
+| P1 | 重要 | 中 | 评估后决策 |
+| P1 | 重要 | 低 | 可后续修复 |
+| P2 | 一般 | 高 | 可后续修复 |
+| P2 | 一般 | 中 | 可后续修复 |
+| P2 | 一般 | 低 | 可后续修复 |
+
+---
+
+## 使用步骤
+
+### 步骤1：执行自动检查
+- 运行代码质量工具
+- 运行测试覆盖率工具
+- 运行安全扫描工具
+- 运行性能基准测试
+
+### 步骤2：执行人工检查
+- 代码评审检查
+- 文档完整性检查
+- 发布准备检查
+
+### 步骤3：生成质量报告
+- 汇总检查结果
+- 识别问题
+- 评估风险
+- 生成报告
+
+### 步骤4：质量门决策
+- 根据检查结果
+- 评估风险
+- 做出决策（通过/条件通过/不通过）
+- 通知相关团队
+
+---
+
+## 与其他技能的集成
+
+### 与sdd-test集成
+```
+sdd-test → 测试结果 → quality-gate → 质量检查
+```
+
+### 与sdd-deploy集成
+```
+quality-gate → 质量通过 → sdd-deploy → 部署执行
+```
+
+---
+
+## 最佳实践
+
+1. 质量门禁要定期更新
+2. 严格但不过于苛刻
+3. 持续改进检查标准
+4. 自动化为主人工为辅
+5. 质量标准要与业务目标对齐
+
+---
+
+## 常见问题
+
+### Q：质量门禁不通过怎么办？
+A：首先分析问题严重性，阻断性问题必须修复，其他问题评估风险后决策
+
+### Q：如何平衡质量和发布速度？
+A：优先级设置合理，P0必须通过，P1尽量通过，P2可后续修复
+
+### Q：质量检查应该什么时候做？
+A：开发过程中持续做，发布前集中做，定期回顾改进检查标准

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

@@ -0,0 +1,213 @@
+---
+name: receiving-code-review
+description: 在收到代码审查反馈时使用，在实施建议之前，特别是如果反馈似乎不清楚或技术上有问题 - 需要技术严谨性和验证，而不是表演性同意或盲目实施
+---
+
+# 代码审查接收
+
+## 概述
+
+代码审查需要技术评估，而不是情感表演。
+
+**核心原则：** 实施前验证。假设前询问。技术正确性优先于社交舒适度。
+
+## 响应模式
+
+```
+收到代码审查反馈时：
+
+1. 阅读：完整阅读反馈，不做出反应
+2. 理解：用自己的话重述要求（或询问）
+3. 验证：对照代码库现实进行检查
+4. 评估：对这个代码库技术上是否合理？
+5. 响应：技术确认或有理由的反驳
+6. 实施：一次一个项目，测试每个项目
+```
+
+## 禁止的响应
+
+**永远不要：**
+- "你绝对正确！"（明确违反 CLAUDE.md）
+- "好观点！" / "优秀的反馈！"（表演性的）
+- "让我现在实施那个"（验证前）
+
+**相反：**
+- 重述技术要求
+- 提出澄清问题
+- 如果错误，用技术推理反驳
+- 直接开始工作（行动 > 言语）
+
+## 处理不清楚的反馈
+
+```
+如果任何项目不清楚：
+  停止 - 暂时不要实施任何内容
+  要求澄清不清楚的项目
+
+原因：项目可能相关。部分理解 = 错误实施。
+```
+
+**示例：**
+```
+你的人类伙伴："修复 1-6"
+你理解 1,2,3,6。对 4,5 不清楚。
+
+❌ 错误：现在实施 1,2,3,6，稍后询问 4,5
+✅ 正确："我理解项目 1,2,3,6。在继续之前需要澄清 4 和 5。"
+```
+
+## 特定来源处理
+
+### 来自你的人类伙伴
+- **可信** - 理解后实施
+- **如果范围不清楚，仍要询问**
+- **无表演性同意**
+- **直接行动**或技术确认
+
+### 来自外部审查者
+```
+实施前：
+  1. 检查：对这个代码库技术上是否正确？
+  2. 检查：是否破坏现有功能？
+  3. 检查：当前实现的原因？
+  4. 检查：是否在所有平台/版本上工作？
+  5. 检查：审查者是否理解完整上下文？
+
+如果建议似乎错误：
+  用技术推理反驳
+
+如果无法轻松验证：
+  说明："没有 [X] 我无法验证这一点。我应该 [调查/询问/继续]？"
+
+如果与你的人类伙伴之前的决定冲突：
+  先停止并与你的人类伙伴讨论
+```
+
+**你的人类伙伴的规则：** "外部反馈 - 保持怀疑，但仔细检查"
+
+## "专业"功能的 YAGNI 检查
+
+```
+如果审查者建议"正确实施"：
+  在代码库中搜索实际使用
+
+  如果未使用："这个端点没有被调用。移除它（YAGNI）？"
+  如果使用：则正确实施
+```
+
+**你的人类伙伴的规则：** "你和审查者都向我报告。如果我们不需要这个功能，就不要添加它。"
+
+## 实施顺序
+
+```
+对于多项反馈：
+  1. 首先澄清任何不清楚的内容
+  2. 然后按以下顺序实施：
+     - 阻塞问题（中断，安全）
+     - 简单修复（拼写错误，导入）
+     - 复杂修复（重构，逻辑）
+  3. 单独测试每个修复
+  4. 验证无回归
+```
+
+## 何时反驳
+
+当以下情况时反驳：
+- 建议破坏现有功能
+- 审查者缺乏完整上下文
+- 违反 YAGNI（未使用的功能）
+- 对这个技术栈技术上不正确
+- 存在遗留/兼容性原因
+- 与你的人类伙伴的架构决策冲突
+
+**如何反驳：**
+- 使用技术推理，而非防御性
+- 提出具体问题
+- 引用工作测试/代码
+- 如果是架构问题，让你的人类伙伴参与
+
+**如果不愿意大声反驳的信号：** "Circle K 有奇怪的事情发生"
+
+## 确认正确的反馈
+
+当反馈正确时：
+```
+✅ "已修复。[对更改的简要描述]"
+✅ "好发现 - [具体问题]。在 [位置] 已修复。"
+✅ [直接修复并在代码中显示]
+
+❌ "你绝对正确！"
+❌ "好观点！"
+❌ "感谢发现那个！"
+❌ "感谢 [任何内容]"
+❌ 任何感谢表达
+```
+
+**为什么不感谢：** 行动说话。直接修复。代码本身表明你听到了反馈。
+
+**如果你发现自己要写"谢谢"：** 删除它。改为说明修复。
+
+## 优雅地纠正你的反驳
+
+如果你反驳了但错了：
+```
+✅ "你是对的 - 我检查了 [X]，它确实 [Y]。现在实施。"
+✅ "验证了这一点，你是正确的。我最初的理解是错误的，因为 [原因]。正在修复。"
+
+❌ 冗长的道歉
+❌ 为你反驳的原因辩护
+❌ 过度解释
+```
+
+事实陈述纠正并继续。
+
+## 常见错误
+
+| 错误 | 修复 |
+|------|------|
+| 表演性同意 | 说明要求或直接行动 |
+| 盲目实施 | 首先对照代码库验证 |
+| 批量实施而不测试 | 一次一个，测试每个 |
+| 假设审查者是对的 | 检查是否破坏事物 |
+| 避免反驳 | 技术正确性 > 舒适度 |
+| 部分实施 | 首先澄清所有项目 |
+| 无法验证，仍继续 | 说明限制，请求方向 |
+
+## 真实示例
+
+**表演性同意（错误）：**
+```
+审查者："移除遗留代码"
+❌ "你绝对正确！让我移除那个..."
+```
+
+**技术验证（正确）：**
+```
+审查者："移除遗留代码"
+✅ "检查中... 构建目标是 10.15+，此 API 需要 13+。需要遗留代码以保持向后兼容。当前实现的 bundle ID 错误 - 修复它还是放弃 13 之前的支持？"
+```
+
+**YAGNI（正确）：**
+```
+审查者："实施带有数据库、日期过滤器、CSV 导出的适当指标跟踪"
+✅ "搜索代码库 - 没有调用此端点。移除它（YAGNI）？还是我遗漏了使用情况？"
+```
+
+**不清楚的项目（正确）：**
+```
+你的人类伙伴："修复项目 1-6"
+你理解 1,2,3,6。对 4,5 不清楚。
+✅ "理解 1,2,3,6。在实施之前需要澄清 4 和 5。"
+```
+
+## GitHub 线程回复
+
+在 GitHub 上回复内联审查评论时，在评论线程中回复（`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`），而不是作为顶级 PR 评论。
+
+## 底线
+
+**外部反馈 = 要评估的建议，不是要遵循的命令。**
+
+验证。提问。然后实施。
+
+无表演性同意。始终保持技术严谨。