create-vibe-workflow 0.1.0 → 0.2.0

package/dist/templates/skills/advanced/diagnose/SKILL.md.ejs

@@ -0,0 +1,159 @@
+# Diagnose — 严格诊断循环
+
+> 使用此 skill 时：遇到 Bug、错误、异常行为，且原因不明确时。
+
+## 诊断循环
+
+```
+┌──────────────────────────────────────────────────────────┐
+│  ① 观察（Observe） 收集所有症状，不跳结论                  │
+│  ② 假设（Hypothesize） 提出一个可验证的根因假设           │
+│  ③ 验证（Verify） 设计最小实验验证/证伪假设               │
+│  ④ 修复（Fix） 确定根因后实施修复                        │
+│  ⑤ 确认（Confirm） 验证修复有效且不引入回归               │
+│  ↺ 未解决 → 回到 ①                                      │
+└──────────────────────────────────────────────────────────┘
+```
+
+## ① 观察 — 收集症状
+
+只收集事实，不跳入结论。
+
+### 必须收集的信息
+
+```text
+【症状】
+  - 实际行为是什么？
+  - 期望行为是什么？
+  - 差异在什么条件下出现？
+  - 是稳定的还是偶发的？
+
+【环境】
+  - 什么系统/版本？
+  - 什么输入？
+  - 什么配置？
+  - 什么数据量？
+
+【复现】
+  - 稳定可复现？
+  - 复现步骤是否最少？
+  - 在什么环境下可复现？
+
+【最近变更】
+  - 问题从什么时候开始？
+  - 之前改了什么？
+  - 关联的部署/发布？
+```
+
+### 禁止以下预判
+
+```text
+❌ "这个应该是 XXX 问题"
+❌ "上次也是这个原因"
+❌ "不用看日志就知道"
+❌ "肯定是 XXX 的问题"
+```
+
+## ② 假设 — 提出根因假设
+
+### 假设模板
+
+```text
+如果 [原因] → 那么 [预期现象]
+
+如果数据库连接池满了 → 那么所有数据库操作都会超时
+如果缓存未失效 → 那么返回的应该是旧数据
+如果权限检查顺序错误 → 那么登出用户也能访问
+```
+
+### 假设质量检查
+
+```text
+[ ] 假设可验证（有明确的预期现象）
+[ ] 假设可证伪（可以证明是错的）
+[ ] 假设符合已有事实（不矛盾）
+[ ] 只包含一个原因（而非多个可能原因混合）
+```
+
+## ③ 验证 — 设计最小实验
+
+### 实验设计原则
+
+```text
+每次只验证一个假设。
+
+最小实验 = 产生明确答案的最少工作量。
+
+好实验：
+  - 执行时间 < 30 秒（或极短）
+  - 结果明确（是/否，或具体数值）
+  - 不改变系统状态（只读）
+  - 可重复（同一输入同一结果）
+
+坏实验：
+  - 修改多处代码然后看效果
+  - 需要 10 分钟才能看到结果
+  - 结果是模糊的（"好像好了"）
+```
+
+### 典型的验证方法
+
+```text
+日志验证：
+  - 添加特定日志 → 重现场景 → 检查输出
+  - 注意生产环境不要添加 debug 级别日志
+
+单元测试：
+  - 对可疑函数写测试 → 断言预期行为
+
+隔离验证：
+  - 创建最小复现（去掉无关代码）
+  - 在独立环境中测试假设
+
+二分法：
+  - 注释掉一半代码 → 看问题是否还在
+  - 重复直到定位到具体行
+```
+
+## ④ 修复 — 实施修复
+
+```text
+确定根因后，只做最少修改。
+
+修复模板：
+  1. 理解为什么要这样写（原作者的意图是什么？）
+  2. 修改最小范围的代码
+  3. 添加测试覆盖这个边界情况
+  4. 确保现有测试仍然通过
+
+如果修复复杂（> 50 行）：
+  - 拆分为小步骤
+  - 每步验证
+```
+
+## ⑤ 确认 — 验证修复
+
+```text
+验证清单：
+  [ ] 原问题不再复现
+  [ ] 所有已有测试通过
+  [ ] 新增了防止回归的测试
+  [ ] 相邻功能不受影响
+  [ ] 边界情况已测试
+
+如果验证失败：
+  - 回到 ①，重新观察
+  - 标记原假设为证伪
+  - 提出新假设
+```
+
+## 反模式
+
+| 反模式 | 问题 | 正确做法 |
+|--------|------|---------|
+| 无假设直接改 | 盲目尝试，浪费时间 | 先假设再实验 |
+| 一次改多处 | 不知道哪处解决了问题 | 一次只改一处 |
+| 确认偏差 | 只找支持假设的证据 | 主动寻找证伪证据 |
+| 忽略简单原因 | 一上来就怀疑复杂原因 | 先排查简单可能（拼写、配置、版本） |
+| 修复后不验证 | 以为好了但实际上没 | 严格确认 |
+| 不写回归测试 | 下次同类问题再出现 | 每个修复加测试 |

package/dist/templates/skills/advanced/grill-with-docs/SKILL.md.ejs

@@ -0,0 +1,154 @@
+# Grill with Docs — 基于文档的对抗式审查
+
+> 使用此 skill 时：在实现复杂功能之前、在 PR 合并之前、在不确定方案是否正确时。
+
+## 什么是"对抗式审查"
+
+通过严格的文档审查来挑战方案中的假设、模糊之处和遗漏。核心方法是：**AI 扮演"吹毛求疵的审查者"，用文档中的每一条要求来检查方案是否满足**。
+
+## 审查流程
+
+```
+┌──────────────────────────────────────────────────────────┐
+│  ① 加载文档   收集所有相关规格文档                        │
+│  ② 提取要求   从文档中提取出每条具体需求                  │
+│  ③ 对照检查   逐条对照方案是否满足需求                    │
+│  ④ 发现漏洞   标记不满足、模糊、矛盾之处                  │
+│  ⑤ 修复方案   修正方案直到满足所有文档要求                 │
+└──────────────────────────────────────────────────────────┘
+```
+
+## ① 加载文档
+
+收集所有相关文档：
+
+```text
+- PRD / 功能规格文档
+- API 设计文档
+- 数据库 Schema 文档
+- 安全规范文档
+- UI/UX 设计稿或线框图
+- 相关 Issue 和讨论
+- 上游/下游模块的接口文档
+```
+
+## ② 提取要求
+
+从文档中提取每一条具体需求，分类记录：
+
+### 分类
+
+```text
+【功能需求（F）】
+  文档中明确要求的功能点
+  例："用户可以重置密码"
+
+【非功能需求（NF）】
+  性能、安全、可用性、兼容性
+  例："页面加载时间 < 2 秒"
+
+【约束条件（C）】
+  技术选型、架构限制、团队规范
+  例："必须使用 XXX 框架"
+
+【边界条件（B）】
+  错误路径、极限情况、异常处理
+  例："当数据库不可用时显示降级页面"
+```
+
+### 提取示例
+
+```text
+PRD 原文：
+"用户可以通过邮箱或手机号注册，注册后需要验证邮箱或手机。
+如果用户使用邮箱注册，需要发送验证邮件；如果使用手机号注册，需要发送短信验证码。
+验证成功后用户才能登录。"
+
+提取为：
+  [F-1] 用户可以用邮箱注册
+  [F-2] 用户可以用手机号注册
+  [F-3] 邮箱注册需要发送验证邮件
+  [F-4] 手机注册需要发送短信验证码
+  [F-5] 用户验证成功后才能登录
+  [B-1] 如果邮件发送失败怎么办？（未明确）
+  [B-2] 如果短信发送失败怎么办？（未明确）
+```
+
+## ③ 对照检查
+
+| 要求 | 方案覆盖 | 状态 |
+|------|---------|------|
+| F-1: 邮箱注册 | UserController.register(email) 接收邮箱参数 | ✅ |
+| F-2: 手机注册 | UserController.register(phone) 接收手机参数 | ✅ |
+| F-3: 发送验证邮件 | 注册后调用 EmailService.sendVerification | ✅ |
+| F-4: 发送短信验证码 | 注册后调用 SMSService.sendCode | ✅ |
+| F-5: 验证后才能登录 | LoginGuard 检查用户 verified 状态 | ✅ |
+| B-1: 邮件发送失败 | 方案中未提及 | ❌ |
+| B-2: 短信发送失败 | 方案中未提及 | ❌ |
+
+## ④ 发现漏洞
+
+### 常见漏洞类型
+
+```text
+【遗漏】
+  文档中有的要求，方案中没有
+
+【模糊】
+  方案使用了模糊的表述（"合适的"、"合理的"、"按需"）
+
+【矛盾】
+  方案与文档冲突、不同文档之间冲突
+
+【未定义】
+  关键术语没有定义（"及时"、"大量"、"异常"）
+
+【假设】
+  方案基于未经验证的假设（"用户不会同时操作"）
+```
+
+### 追问模板
+
+```text
+关于遗漏：
+  "文档要求 X，但方案中没看到对应的实现。怎么处理的？"
+
+关于模糊：
+  "这里说'合适的错误处理'，具体是什么？是重试、降级还是报错？"
+
+关于矛盾：
+  "文档 A 说 X，方案这里用了 ~X。哪个是对的？"
+
+关于未定义：
+  "'及时通知用户'——具体是多长时间？"
+
+关于假设：
+  "方案假设了 X，如果 X 不成立会怎样？"
+```
+
+## ⑤ 修复方案
+
+```text
+对每个发现的漏洞，决定处理方式：
+
+修复：补充缺失的实现、明确模糊的表述、解决矛盾
+搁置：确认不是问题，记录理由（"这个场景不会发生因为……"）
+记录：标记为已知限制，后续版本处理
+
+修复核对清单：
+  [ ] 所有 F（功能需求）已覆盖
+  [ ] 所有 NF（非功能需求）已覆盖
+  [ ] 所有 C（约束条件）已满足
+  [ ] 所有 B（边界条件）已处理
+  [ ] 文档中没有模糊的术语
+  [ ] 方案中没有隐藏的假设
+```
+
+## 反模式
+
+| 反模式 | 问题 | 正确做法 |
+|--------|------|---------|
+| 只检查功能需求 | 遗漏安全和性能要求 | 全部类别都检查 |
+| 对自己方案过于宽容 | 跳过对自己不利的检查 | 假设方案有问题，努力去找 |
+| 忘记检查矛盾 | 方案内部不自洽 | 检查方案自身的一致性 |
+| 不更新文档 | 方案和文档不一致 | 改方案的同时更新文档 |

package/dist/templates/skills/advanced/improve-codebase-architecture/SKILL.md.ejs

@@ -0,0 +1,172 @@
+# Improve Codebase Architecture — 代码架构优化
+
+> 使用此 skill 时：代码库变得难以修改、每次改东西都影响多个模块、新需求难以添加时。
+
+## 核心理念
+
+使用两个概念分析架构健康度：
+
+```text
+【Depth（深度）】— 一个模块的职责有多集中
+  浅（Shallow）  → 模块做了太多不同的事，没有清晰的抽象
+  深（Deep）     → 模块封装了复杂逻辑，对外暴露简单接口
+
+  目标：模块深而窄（内部复杂但接口简单）
+
+【Seam（接缝）】— 在不修改代码的情况下改变行为的地方
+  好的接缝 → 可以通过配置/注入/参数改变行为
+  坏的接缝 → 必须修改代码才能改变行为
+
+  目标：关键变化点都有清晰的接缝
+```
+
+### 判断方法
+
+```text
+深度检测：
+  问：这个模块的接口有几个方法？
+  问：用一个句子能说清这个模块的职责吗？
+  问：这个模块隐藏了多少复杂性？
+
+  如果：
+    - 接口方法 > 10 → 可能太浅
+    - 一句话说不清职责 → 可能太浅
+    - 调用者需要了解实现细节 → 可能太浅
+
+接缝检测：
+  问：要改变这个行为，需要修改什么文件？
+  问：想用 mock 替换这个依赖，需要改代码吗？
+  问：添加同类功能要改几个地方？
+
+  如果：
+    - 改行为必须改具体实现文件 → 没有接缝
+    - 难以 mock → 没有接缝
+    - 加同类功能要改 N 个文件（N > 1）→ 没有接缝
+```
+
+## 重构优先级矩阵
+
+| 对业务影响 | 架构问题严重 | 架构问题轻微 |
+|-----------|------------|------------|
+| **变更频繁** | **立即重构（P0）** | **计划重构** |
+| **变更稀少** | 监控，等变更时再重构 | 忽略 |
+
+### 优先级说明
+
+```text
+P0 — 立即重构
+  症状：
+    - 每次改这个功能都很痛苦
+    - 频繁出现 Bug
+    - 修改一处需要同步改多处
+
+  做法：
+    - 提取清晰抽象
+    - 建立接缝
+    - 写测试固定行为
+
+P1 — 计划重构
+  症状：
+    - 代码难以理解但暂时不改
+    - 测试写起来费劲
+
+  做法：
+    - 在 todolist 中加入重构任务
+    - 等有相关需求时顺便重构
+
+P2 — 监控
+  症状：
+    - 代码不够理想但很少改
+    - 没有实际的痛苦
+
+  做法：
+    - 不做主动重构
+    - 下次改时评估是否需要重构
+```
+
+## 常见架构问题及修复
+
+### 上帝对象（God Object）
+
+```text
+症状：
+  - 一个模块/类/文件 > 800 行
+  - 一个模块做了多件事
+  - 团队所有人都在改同一个模块
+
+修复：
+  1. 识别出独立的职责
+  2. 逐个提取为新模块
+  3. 原模块只做编排
+  4. 每个新模块有自己的测试
+```
+
+### 循环依赖
+
+```text
+症状：
+  - A → B → A (直接或间接)
+  - 初始化时需要特殊顺序
+  - 修改 A 导致 B 异常
+
+修复：
+  1. 提取共用的部分为第三个模块
+  2. 或使用依赖倒置（接口定义在调用方）
+  3. 或引入事件机制解耦
+```
+
+### 隐式依赖
+
+```text
+症状：
+  - 需要按特定顺序调用方法
+  - 依赖全局/单例状态
+  - 构造函数做了大量初始化
+
+修复：
+  1. 显式参数化依赖
+  2. 依赖注入（构造函数参数）
+  3. 消除隐式的"必须按顺序调用"的约束
+```
+
+### 散弹式修改（Shotgun Surgery）
+
+```text
+症状：
+  - 改一个需求需要改 N 个文件（N > 3）
+  - 改完后总有一两个文件忘记改
+
+修复：
+  1. 识别变化的原因
+  2. 使用策略模式、钩子或配置集中变化点
+  3. 新加同类功能不用改已有代码（开闭原则）
+```
+
+## 优化流程
+
+```text
+1. 识别痛点
+   - 哪些模块改起来最痛苦？
+   - 团队抱怨最多的是什么？
+   - 测试最难写的是什么？
+
+2. 分析根因
+   - 使用 Depth/Seam 分析
+   - 识别违反了什么原则
+
+3. 制定方案
+   - 提取接口
+   - 拆分职责
+   - 集中变化点
+   - 消除隐式依赖
+
+4. 分步实施
+   - 先加测试（固定当前行为）
+   - 小步重构（每次只提取一个职责）
+   - 每个步骤都保持可运行
+
+5. 验证
+   - 所有测试通过
+   - 行为不变
+   - 新需求实现起来更顺畅
+```