create-vibe-workflow 0.1.0 → 0.2.0

package/templates/skills/workflow/search-first/SKILL.md.ejs

@@ -0,0 +1,103 @@
+# Search-First — 研究优先于编码
+
+> 使用此 skill 时：在实现任何新功能之前、在引入新依赖之前、在解决不熟悉的错误之前。
+
+## 工作流
+
+开始编码之前，先执行研究：
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│  ① 需求分析   明确要解决的问题、输入输出、约束条件                     │
+│  ② 并行搜索   同时搜索多个渠道（GitHub / 包管理器 / 文档 / 项目内）  │
+│  ③ 方案评估   对比候选方案的匹配度、维护状态、学习成本                │
+│  ④ 决策       选择策略：复用/扩展/组合/自建                          │
+│  ⑤ 实现       开始编码                                              │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+## ① 需求分析 — 明确搜索目标
+
+在搜索前，先明确：
+
+```text
+- 要解决什么具体问题？
+- 输入是什么、输出是什么？
+- 有什么约束（性能、安全、兼容性）？
+- 是全新需求还是替代现有方案？
+- 是否有内部已有类似实现？
+```
+
+## ② 并行搜索 — 多源获取信息
+
+同时搜索以下渠道：
+
+### 搜索渠道清单
+
+| 渠道 | 场景 | 搜索什么 |
+|------|------|---------|
+| GitHub 代码搜索 | 寻找参考实现 | 类似功能的仓库、代码片段、Issue 讨论 |
+| 包管理器（npm/PyPI/crates.io 等） | 寻找可复用库 | 功能匹配的包、下载量、最近更新 |
+| 官方文档 | 确认 API 用法 | 版本迁移、配置项、最佳实践 |
+| 项目内代码 | 复用已有模式 | 相邻模块的实现方式、工具函数库 |
+| AI 知识库 | 模式/最佳实践 | 常用设计模式、已知解决方案 |
+
+### 搜索方法
+
+```text
+// GitHub 搜索示例
+搜索: "language:{lang} {keyword} implementation"
+搜索: "topic:{topic} language:{lang}"
+
+// 包管理器搜索
+搜索: "{keyword}" → 检查：最近更新、周下载量、依赖树大小
+
+// 项目内搜索
+搜索: 相邻功能模块的目录结构和使用模式
+搜索: 项目中已使用的类似库/工具
+```
+
+## ③ 方案评估 — 对比候选方案
+
+对每个候选方案，评估以下维度：
+
+| 维度 | 评估问题 |
+|------|---------|
+| 功能匹配 | 覆盖需求的百分之多少？ |
+| 维护状态 | 最近更新？Issue 响应？主仓库活跃？ |
+| 成熟度 | 版本号（<1.0 谨慎）、Star 数、被依赖数 |
+| 学习成本 | 文档质量、示例数量、概念复杂度 |
+| 集成成本 | 需要多少胶水代码？和现有技术栈兼容？ |
+| 安全 | 已知漏洞？权限模型？ |
+| 性能 | 基准测试？内存/CPU 影响？ |
+| 社区 | 问题是否有解答？Stack Overflow 讨论？ |
+
+## ④ 决策矩阵 — 选择策略
+
+| 情况 | 策略 | 行动 |
+|------|------|------|
+| 有成熟的库覆盖 90%+ 需求 | **采用（Adopt）** | 引入依赖，按文档使用 |
+| 有接近的库但需少量定制 | **扩展（Extend）** | 引入后包装/配置/插件 |
+| 多个库各覆盖一部分 | **组合（Compose）** | 引入多个库，编写胶水层 |
+| 没有合适的库 | **自建（Build）** | 参考调研结果自行实现 |
+
+### 不引入依赖的情况
+
+```text
+- 功能少于 50 行代码可实现
+- 库有已知安全漏洞且不及时修复
+- 库的依赖树过大（间接引入 >50 个包）
+- 库与项目技术栈不兼容
+- 只有一个函数需要但库是整个框架
+```
+
+## ⑤ 反模式
+
+| 反模式 | 问题 | 正确做法 |
+|--------|------|---------|
+| 已知有库但非要自建 | 浪费时间，维护成本高 | 先用库，不够再替换 |
+| 先写代码再搜索 | 可能走错方向 | 先搜索再编码 |
+| 只看第一个结果 | 错过更好的方案 | 至少对比 3 个候选 |
+| 引入大库只用小功能 | 膨胀依赖树 | 自己写或用微库 |
+| 不验证就采用 | 发现不匹配时已投入大量时间 | 先写 PoC 验证 |
+| 搜索完不看 License | 法律风险 | 确认 License 兼容性 |

package/templates/skills/workflow/security-review/SKILL.md.ejs

@@ -0,0 +1,146 @@
+# Security Review — 提交前安全检查
+
+> 使用此 skill 时：在准备提交代码前，或者修改了涉及认证/授权/用户数据/支付/外部 API 调用的代码时。
+
+## 安全检查清单
+
+以下所有检查项必须在每次提交前执行：
+
+### 1. 密钥管理
+
+```
+[ ] 无硬编码密钥（API Key、密码、Token、JWT Secret）
+[ ] 无硬编码数据库连接字符串
+[ ] 无硬编码第三方服务凭据
+[ ] 配置文件中无真实凭据（只有占位符或环境变量引用）
+```
+
+### 2. 输入验证
+
+```
+[ ] 所有用户输入使用 schema 校验（长度/格式/类型/范围）
+[ ] 文件上传有类型/大小限制
+[ ] 批量操作有数量上限
+[ ] URL 参数/路径参数已校验
+```
+
+### 3. SQL / NoSQL 注入防护
+
+```
+[ ] 使用参数化查询或 ORM 内置防护
+[ ] 无字符串拼接 SQL 语句
+[ ] NoSQL 查询使用参数化（非原始字符串注入）
+```
+
+### 4. XSS 防护
+
+```
+[ ] 用户生成内容输出时已转义
+[ ] 富文本内容经 HTML Sanitizer 过滤
+[ ] CSP（Content Security Policy）已配置
+[ ] 无 `innerHTML` / `dangerouslySetInnerHTML` 等危险 API
+```
+
+### 5. CSRF 防护
+
+```
+[ ] 有状态修改操作（POST/PUT/DELETE）有 CSRF 保护
+[ ] SameSite Cookie 已设置
+[ ] API 使用 Token 认证时无需额外 CSRF（但需确认）
+```
+
+### 6. 认证与授权
+
+```
+[ ] 认证失败的响应不泄露用户是否存在
+[ ] 令牌有有效期和刷新机制
+[ ] 每次操作验证资源所有权（防止 IDOR）
+[ ] 未认证用户无法访问受保护资源
+[ ] 权限不足的用户得到 403 而非 401
+```
+
+### 7. 速率限制
+
+```
+[ ] 认证端点有登录尝试限制
+[ ] 公开 API 端点有速率限制
+[ ] 文件上传端点有额外限制
+```
+
+### 8. 错误消息与日志
+
+```
+[ ] 错误消息不泄露内部细节（堆栈、路径、SQL、配置）
+[ ] 日志中不记录密码、Token、信用卡等敏感数据
+[ ] 生产环境关闭调试模式/详细错误
+```
+
+## 常见漏洞修复模板
+
+### 修复硬编码密钥
+
+```text
+// ❌ 错误
+apiKey = "sk-xxxxxxxxxxxxxxxx"
+
+// ✅ 正确
+apiKey = env("API_KEY")
+if apiKey is empty → throw "API_KEY not configured"
+```
+
+### 修复 SQL 注入
+
+```text
+// ❌ 错误
+query = "SELECT * FROM users WHERE id = '" + userId + "'"
+
+// ✅ 正确
+query = "SELECT * FROM users WHERE id = $1"
+execute(query, [userId])
+```
+
+### 修复 IDOR（越权）
+
+```text
+// ❌ 错误 — 只检查资源存在，不检查所有权
+resource = db.find(resourceId)
+return resource
+
+// ✅ 正确 — 验证当前用户拥有该资源
+resource = db.find(resourceId)
+if resource.ownerId != currentUserId → throw 403
+return resource
+```
+
+### 安全错误响应
+
+```text
+// ❌ 错误 — 泄露内部信息
+response 500: { "error": "Cannot read property 'x' of null at /src/services/user.js:42" }
+
+// ✅ 正确 — 泛化错误
+response 500: { "error": "Internal server error" }
+// 日志中保留完整信息供调试
+```
+
+## 安全扫描命令
+
+```bash
+# 依赖漏洞扫描
+audit                            # 检查依赖中的已知漏洞
+
+# 密钥扫描（防止敏感信息提交）
+# 使用 pre-commit hook 或 CI 中的密钥扫描工具
+
+# 静态安全分析
+lint --security                  # 运行安全规则集
+```
+
+## 严重程度分级
+
+| 级别 | 定义 | 行动要求 |
+|------|------|---------|
+| CRITICAL | 可直接导致数据泄露/服务入侵 | 必须修复，阻断提交 |
+| HIGH | 在特定条件下可被利用 | 必须修复 |
+| MEDIUM | 增加攻击面 | 建议修复 |
+| LOW | 最佳实践偏离 | 记录待办 |

package/templates/skills/workflow/strategic-compact/SKILL.md.ejs

@@ -0,0 +1,108 @@
+# Strategic Context Compaction — 上下文策略压缩
+
+> 使用此 skill 时：当上下文窗口使用超过 70%、或经历 30+ 轮对话、或在任务阶段切换时。
+
+## 什么是上下文压缩
+
+上下文压缩（Context Compaction）是指对话达到一定长度后，用户主动清理对话历史以释放上下文窗口的操作。作为 AI，你需要配合用户完成有意义的压缩，而不是简单地删除历史。
+
+## 什么时候该压缩
+
+```
+┌──────────────────────────────────────────────────────────┐
+│  触发条件                                                  │
+│  ✅ 任务阶段切换  （设计→实现、实现→测试、测试→审查）       │
+│  ✅ 长时间编码    （连续 30+ 轮对话未压缩）                 │
+│  ✅ 上下文告警    （看到"上下文接近限制"提示）               │
+│  ✅ 方向变更      （需求变更、技术方案更换）                 │
+│  ❌ 正在解决一个复杂 Bug — 先解决再压缩                    │
+└──────────────────────────────────────────────────────────┘
+```
+
+## 压缩中保留什么 vs 丢弃什么
+
+### 保留（Survives）
+
+```text
+✅ 项目核心结构
+   - 目录结构、模块组织方式
+   - 关键文件的用途和位置
+
+✅ 已做出的技术决策
+   - 架构选择及理由
+   - 约定和规范
+
+✅ 当前任务状态
+   - 哪些完成了、哪些进行中、哪些待办
+   - 当前遇到的阻塞问题（如果未解决）
+
+✅ 用户偏好和模式
+   - 用户喜欢的代码风格
+   - 用户对某些问题的处理方式
+
+✅ 关键上下文
+   - 当次对话的主要目标
+   - 项目 CLAUDE.md 中的规则
+```
+
+### 丢弃（Lost — 需重新加载）
+
+```text
+❌ 详细的实现步骤
+   - 具体写了哪些文件、哪些函数
+   - 修改的详细顺序
+
+❌ 调试过程
+   - 试过的错误方案
+   - 详细错误信息（除非当前仍相关）
+
+❌ 对话中的辅助内容
+   - 搜索结果的详细内容
+   - 文档片段
+
+❌ 确认性对话
+   - "好的"、"明白了"、"继续"
+   - 无信息量的来回确认
+```
+
+## 压缩后怎么做
+
+用户压缩后：
+
+```text
+1. 重新加载关键上下文
+   - 读取项目 CLAUDE.md
+   - 读取当前 todolist.md / PROGRESS.md
+   - 读取最近修改的关键文件
+
+2. 确认阶段
+   - "我们之前在实现 X 功能，当前进展到 Y 阶段"
+   - "下一个任务是 Z，继续吗？"
+
+3. 继续执行
+   - 从压缩前的断点继续
+   - 不要要求用户重复已经说过的话
+```
+
+## AI 端优化
+
+作为 AI，你可以主动帮助用户节省上下文空间：
+
+```text
+【精简回答】
+- 避免重复确认（用户说"继续"后直接执行）
+- 避免复述全部代码（只展示关键部分或 diff）
+- 避免罗列所有选项（先推荐，再问是否看其他）
+
+【用引用代替复制】
+- 使用 "参考 X 文件的 Y 函数" 代替粘贴整个函数
+- 使用文件路径引用已存在的代码
+
+【结构化输出】
+- 用表格/列表代替段落
+- 结果优先：先给结论，再给（可折叠的）细节
+
+【及时建议压缩】
+- 检测到轮数增加时主动提示："已进行 X 轮对话，建议压缩上下文"
+- 任务阶段切换时主动提示
+```

package/templates/skills/workflow/tdd-workflow/SKILL.md.ejs

@@ -0,0 +1,104 @@
+# TDD Workflow — Red-Green-Refactor
+
+> 使用此 skill 时：写入任何实现代码之前，必须先调用此 skill。
+
+## TDD 铁律
+
+**RED → GREEN → REFACTOR — 严格按顺序，不可跳过任一阶段。**
+
+```
+┌─────────────────────────────────────────────────────┐
+│  ① RED     写一个失败的测试                            │
+│  ② GREEN   写最简实现让测试通过                         │
+│  ③ REFACTOR 重构代码，保持测试通过                      │
+│  ④ LOOP    回到 ① 直到功能完成                         │
+└─────────────────────────────────────────────────────┘
+```
+
+### 阶段详解
+
+#### ① RED — 编写测试（先写！）
+
+- 根据功能验收标准写测试用例
+- 测试断言失败是正常的 — 功能还没实现
+- 测试粒度：一个测试验证一个行为
+- 命名格式：`{方法/组件名} — {场景} — {期望结果}`
+
+```text
+// 示例命名
+createUser — with valid data — returns user object with ID
+createUser — with duplicate email — throws ValidationError
+UserAvatar — when image fails to load — shows fallback initials
+```
+
+#### ② GREEN — 最简实现
+
+- 只写刚好够让测试通过的代码
+- 不要优化、不要抽象、不要加"将来可能需要"的功能
+- 可以硬编码返回值 — 后续测试会迫使你泛化
+- 本阶段的目标是**通过测试**，不是"写好代码"
+
+#### ③ REFACTOR — 清理代码
+
+- 测试通过后才能重构
+- 提取重复代码、优化命名、简化逻辑
+- 重构时不改行为（不改测试、不改 API）
+- 每步修改后跑测试确认没破坏任何东西
+
+## 测试类型决策矩阵
+
+| 要验证什么 | 测试类型 | 速度 | 写几个 | 是否需要 mock |
+|-----------|---------|------|--------|-------------|
+| 工具函数/纯逻辑 | Unit | 毫秒级 | 边界值全覆盖 | 否 |
+| 组件渲染逻辑 | Unit | 毫秒级 | 1-2 个 happy path | 否 |
+| 组件交互行为 | Integration | 毫秒级 | 关键路径 | 否 |
+| API 端点行为 | Integration | 秒级 | Happy + 错误路径 | 是（外部服务） |
+| 数据库操作 | Integration | 秒级 | CRUD + 约束 | 是（mock DB 或内存 DB） |
+| 跨服务流程 | E2E | 秒-分级 | 核心用户旅程 | 否（真实实例） |
+
+## 覆盖率要求
+
+- **单元测试**：纯逻辑层 ≥95%，组件层 ≥80%
+- **集成测试**：API 端点 100% 覆盖所有状态码路径
+- **E2E 测试**：核心用户旅程 100%
+
+> 不是数字游戏。覆盖率的目的是确保修改代码时测试能拦住回归。
+
+## 反模式（Anti-Patterns）
+
+| 反模式 | 说明 | 正确做法 |
+|--------|------|---------|
+| 先写实现再补测试 | 测试只是验证而非驱动 | 先写测试，让测试驱动设计 |
+| 测试依赖实现细节 | 重构时测试大面积红 | 测试行为而非实现 |
+| 一个测试测多个东西 | 失败时不知道问题在哪 | 一个断言一个测试 |
+| mock 过多 | 测试与实现耦合 | 只在边界层用 mock |
+| 忽略 RED 阶段 | 直接写实现再测 | RED 阶段验证测试本身没问题 |
+| 覆盖率 100% 强迫症 | 耗费精力在 trivial 代码上 | 按决策矩阵分配精力 |
+
+## CI 集成
+
+```text
+每次 push / PR 时自动运行：
+
+  [lint] → [type-check] → [unit-test] → [build] → [integration-test]
+
+门禁规则：
+  - 单元测试失败 → 阻断合并
+  - 集成测试失败 → 阻断合并
+  - 覆盖率低于阈值 → 警告（可配置是否阻断）
+```
+
+## 框架无关的测试结构模板
+
+```text
+src/
+├── __tests__/
+│   ├── unit/
+│   │   └── {module}.test.*        # 纯逻辑测试
+│   ├── integration/
+│   │   └── {module}.integration.* # 带 IO 的测试
+│   └── helpers/
+│       └── test-utils.*           # 测试工具函数
+└── e2e/
+    └── {feature}.spec.*           # E2E 测试
+```

package/templates/skills/workflow/verification-loop/SKILL.md.ejs

@@ -0,0 +1,144 @@
+# Verification Loop — 6 阶段验证闭环
+
+> 使用此 skill 时：在声称"完成"之前，必须执行此验证闭环。
+
+## 验证闭环
+
+每次修改后，按顺序执行 6 个阶段：
+
+```
+┌──────────────────────────────────────────────────────────┐
+│  ① BUILD     编译通过，无错误                              │
+│  ② TYPE-CHECK 类型检查通过，无 `any` 遗漏                   │
+│  ③ LINT      静态分析通过，无违反规则                       │
+│  ④ TEST      所有测试通过，覆盖率达标                       │
+│  ⑤ SECURITY  安全检查通过，无敏感信息泄露                    │
+│  ⑥ DIFF-REVIEW 变更审查，确认改动范围与需求一致              │
+└──────────────────────────────────────────────────────────┘
+```
+
+## 阶段详解
+
+### ① BUILD — 编译验证
+
+检查项目能否成功编译/转译。编译错误阻断后续所有步骤。
+
+```bash
+# 通用
+build                         # 项目构建命令
+build --no-cache              # 强制无缓存构建
+
+# 验证标准
+- 零编译错误
+- 零编译警告（或已确认可忽略）
+```
+
+### ② TYPE-CHECK — 类型检查
+
+静态类型检查确保类型安全。
+
+```bash
+# 通用
+type-check                    # 类型检查命令
+type-check --strict           # 严格模式
+
+# 验证标准
+- 零类型错误
+- 无显式 `any` 类型（除非有显式豁免注释）
+- 无未使用的变量/导入
+```
+
+### ③ LINT — 静态分析
+
+代码风格和潜在错误检查。
+
+```bash
+# 通用
+lint                           # 静态分析命令
+lint --fix                     # 自动修复可修复问题
+
+# 验证标准
+- 零错误（error）
+- 零警告（warning）或已确认的豁免
+- 无 `console.log`（生产代码中）
+- 无 TODO/FIXME 残留（除非有对应 issue 跟踪）
+```
+
+### ④ TEST — 测试验证
+
+确保行为正确性。
+
+```bash
+# 通用
+test                           # 运行所有测试
+test --coverage                # 带覆盖率报告
+test --changed                 # 仅运行受影响的测试（快速反馈）
+
+# 验证标准
+- 所有测试通过
+- 新增代码覆盖率 ≥80%
+- 总覆盖率不下降
+```
+
+### ⑤ SECURITY — 安全检查
+
+防止敏感信息泄露。
+
+```bash
+# 检查清单（手动/自动化）
+- 扫描硬编码密钥：git diff 中不应出现 token / password / secret
+- 检查新增依赖：确认无已知漏洞（`audit`）
+- 检查文件权限：配置文件不应包含真实凭据
+- 检查日志语句：不输出请求体、响应体、堆栈信息
+```
+
+### ⑥ DIFF-REVIEW — 变更审查
+
+最后审视改动的完整性。
+
+```bash
+# 审查命令
+diff --stat                    # 概览变更文件
+diff HEAD                      # 审查具体变更
+
+# 审查清单
+- [ ] 变更范围与需求一致（没有多余修改）
+- [ ] 无死代码/注释掉的代码
+- [ ] 无调试代码残留
+- [ ] 错误提示对用户友好
+- [ ] 边界情况已处理（空值、超长值、特殊字符）
+- [ ] 文档已同步（如有需要）
+```
+
+## 持续模式
+
+在开发过程中，可以在后台持续运行验证循环：
+
+```bash
+# 持续验证（文件变化时自动重跑）
+test --watch                   # 测试持续模式
+lint --watch                   # lint 持续模式
+build --watch                  # 构建持续模式
+```
+
+## 各阶段速度参考
+
+| 阶段 | 通常耗时 | 建议频率 |
+|------|---------|---------|
+| BUILD | 1-30s | 每次保存 |
+| TYPE-CHECK | 1-10s | 每次保存 |
+| LINT | 0.5-5s | 每次保存 |
+| TEST | 2-60s | 每次提交前 |
+| SECURITY | 1-5s | 每次提交前 |
+| DIFF-REVIEW | 10-30s | 每次提交前 |
+
+## 故障场景处理
+
+| 场景 | 动作 |
+|------|------|
+| BUILD 失败 | 修复语法/配置错误 → 重跑 ① |
+| TYPE-CHECK 失败 | 修正类型 → 重跑 ② |
+| LINT 报错 | 修复风格问题 → 重跑 ③ |
+| TEST 失败 | 分析失败原因 → 修实现或修测试 → 重跑 ④ |
+| 安全检查发现密钥 | 立即更换密钥 + 从 git 历史移除 → 重跑 ⑤ |
+| DIFF 发现多余改动 | 还原无关变更 → 重跑 ⑥ |