create-vibe-workflow 0.1.0 → 0.2.0

package/templates/claude-md/node-api/CLAUDE.zh-CN.md

@@ -0,0 +1,47 @@
+<!-- WORKFLOW-START -->
+<!-- 此区域由 create-vibe-workflow 自动生成，重跑 CLI 时会更新 -->
+
+## AI 协作工具链
+
+本项目使用多层 AI 工具协作体系：
+
+```
+你的业务需求
+  ↓
+① 需求规格化 — 把想法变成结构化需求
+  ↓
+② 计划审查 — 拆解任务、验证假设
+  ↓
+③ 流程纪律 — TDD / 文档反写 / 安全检查
+```
+
+### 标准开发流程
+
+```
+① 需求澄清 → ② 计划拆分 → ③ 研究复用
+→ ④ TodoList编写 → ⑤ TDD开发 → ⑥ 代码审查
+→ ⑦ 安全审查 → ⑧ 文档反写 → ⑨ 提交归档
+```
+
+### 常用命令
+
+| 场景 | 命令 |
+|------|------|
+| 开发新功能 | 从第①步开始，先写 PRD/用户故事 |
+| 修 Bug | 先写复现步骤，再修 |
+| 审查代码 | 每次写完代码后执行 |
+| 提交代码 | 检查文档同步后提交 |
+
+## 技术栈
+
+- 语言: TypeScript 5.x (strict mode)
+- 运行时: Node.js 20+ (LTS)
+- 框架: Express / Fastify (REST API)
+- 数据库: PostgreSQL 16+ / MySQL / SQLite（按需）
+- ORM: Drizzle ORM / Prisma
+- 校验: Zod schema（可前后端共享）
+- 认证: JWT / Session-based
+- 测试: Vitest (单元+集成)
+- 部署: Docker + PM2 / Systemd
+
+<!-- WORKFLOW-END -->

package/templates/commands/gstack/cso.md.ejs

@@ -0,0 +1,213 @@
+---
+name: "CSO"
+description: "首席安全官模式 — 基础设施优先的安全审计。源自 gstack /cso"
+category: "Security"
+tags: ["安全", "审计", "OWASP", "STRIDE", "gstack"]
+---
+
+# CSO
+
+## 职责
+
+以首席安全官（Chief Security Officer）视角执行基础设施级安全审计。覆盖代码、依赖、CI/CD 和架构层面的安全风险。
+
+## 触发条件
+
+| 条件 | 操作 |
+|------|------|
+| 修改了 auth/认证模块 | **必须**运行 |
+| 修改了 finance/支付模块 | **必须**运行 |
+| 修改了 system/系统管理模块 | **必须**运行 |
+| 涉及用户数据处理 | **必须**运行 |
+| 其他模块 | **可以**跳过 |
+
+如果不需要安全审查，跳过此步骤。
+
+## 工作模式
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 面向非专业编程人员（Vibe Coder）
+
+安全审查就是"检查你的项目有没有被攻击的风险"：
+- 会用通俗语言解释每个安全问题——"这个像你家门没锁"
+- 修复建议是可操作的具体步骤
+- 不要担心发现很多问题——早发现比晚上线出问题好得多
+- 重点关注：密码泄露、数据泄露、权限漏洞
+` : `
+### 面向专业开发者
+
+- 两层模式：daily（零噪音，高置信度）和 comprehensive（深度扫描）
+- 关注架构层面的安全设计，而非具体代码风格
+- 评估威胁模型，而不仅仅是漏洞扫描
+` %>
+
+## 两种运行模式
+
+### Daily 模式（默认）
+
+**适用**：每次提交前快速检查
+**置信度门槛**：8/10——只报告高置信度问题
+**检查范围**：核心安全项
+
+```bash
+# 运行 daily 模式
+/cso
+# 或
+/cso daily
+```
+
+### Comprehensive 模式
+
+**适用**：月度深度安全审查 / 大版本发布前
+**置信度门槛**：2/10——任何可疑项都报告
+**检查范围**：全部 5 个阶段
+
+```bash
+# 运行 comprehensive 模式
+/cso comprehensive
+# 或
+/cso full
+```
+
+## 步骤
+
+### 阶段 1：Secrets Archaeology（密钥考古）
+
+扫描所有代码、配置文件和 git 历史中的敏感信息：
+
+```
+### 扫描内容
+
+□ 代码中硬编码的 API Key（搜索模式：/sk-[a-zA-Z0-9]{20,}|api[-_]?key|api_key/）
+□ 密码硬编码（搜索模式：/password\s*[=:]["']\w+/）
+□ Token 硬编码（搜索模式：/token\s*[=:]["']\w+/）
+□ 私钥文件（*.key, *.pem, *.pfx, *.p12）
+□ .env 文件是否被提交到 git 历史
+```
+
+**Daily 模式**：只扫描工作区变更文件。
+**Comprehensive 模式**：扫描整个代码库 + `git log --all -p` 搜索历史。
+
+### 阶段 2：依赖供应链安全
+
+```
+### 检查项
+
+□ 已知漏洞（运行 npm audit / pip audit / cargo audit）
+□ 未固定版本（package.json 中的 ^ ~ 前缀）
+□ 过期的依赖（超过 1 年未更新）
+□ 引入的新的依赖是否有安全记录
+□ devDependencies 是否包含不应出现在 production 的包
+```
+
+```bash
+# 根据项目语言运行
+npm audit 2>&1 | tail -20
+# 或
+pnpm audit 2>&1 | tail -20
+# 或其他语言的依赖审计
+```
+
+### 阶段 3：CI/CD 管道安全
+
+```
+### 检查项
+
+□ CI 中是否暴露了环境变量（如 PR 中打印 env）
+□ CI 脚本是否有注入风险（如 eval 用户输入）
+□ CI 是否有 artifact 泄露风险
+□ 是否使用了有风险的 GitHub Actions（unpinned third-party actions）
+□ CI 中是否缓存了凭证/token
+```
+
+**检查文件**：`.github/workflows/`、`.gitlab-ci.yml`、`Jenkinsfile` 等。
+
+### 阶段 4：OWASP Top 10 快速扫描
+
+| 类别 | 检查项 |
+|------|--------|
+| **A01: Broken Access Control** | API 端点是否都有权限检查？IDOR 风险？ |
+| **A02: Cryptographic Failures** | 密码是否 hash？传输是否用 HTTPS？ |
+| **A03: Injection** | SQL/NoSQL/Command 注入风险？ |
+| **A04: Insecure Design** | 是否有速率限制？是否有重放攻击防护？ |
+| **A05: Security Misconfiguration** | 是否留有 debug 端点？CORS 配置？ |
+| **A06: Vulnerable Components** | 依赖版本是否过旧？ |
+| **A07: Auth Failures** | Session 管理？MFA？暴力破解防护？ |
+| **A08: Data Integrity Failures** | 是否有反序列化风险？签名验证？ |
+| **A09: Logging Failures** | 是否有审计日志？异常检测？ |
+| **A10: SSRF** | 是否允许用户指定 URL 请求？ |
+
+**Daily 模式**：只检查被修改的模块相关条目。
+**Comprehensive 模式**：检查所有条目。
+
+### 阶段 5：STRIDE 威胁模型（仅 Comprehensive）
+
+如果涉及 auth / finance / system 模块，执行 STRIDE 威胁建模：
+
+| 威胁 | 问题 | 评估 |
+|------|------|------|
+| **S**poofing（伪造） | 能否伪造身份？ | ✅ / ⚠️ / ❌ |
+| **T**ampering（篡改） | 能否篡改数据？ | ✅ / ⚠️ / ❌ |
+| **R**epudiation（抵赖） | 能否否认操作？ | ✅ / ⚠️ / ❌ |
+| **I**nformation Disclosure（信息泄露） | 数据是否泄露？ | ✅ / ⚠️ / ❌ |
+| **D**enial of Service（拒绝服务） | 能否让服务不可用？ | ✅ / ⚠️ / ❌ |
+| **E**levation of Privilege（权限提升） | 能否越权操作？ | ✅ / ⚠️ / ❌ |
+
+每个威胁评估包括：
+- 受影响的功能
+- 攻击向量
+- 影响范围
+- 缓解措施
+
+## 输出报告
+
+```
+## CSO 审计报告
+
+模式：Daily / Comprehensive
+范围：<模块列表>
+
+### 阶段 1：Secrets Archaeology  ✅ / ❌
+  发现：<N> 个问题
+
+### 阶段 2：Dependency Supply Chain  ✅ / ❌
+  发现：<N> 个问题
+
+### 阶段 3：CI/CD Security  ✅ / ❌ / ⏭ 跳过
+  发现：<N> 个问题
+
+### 阶段 4：OWASP Top 10  ✅ / ❌
+  发现：<N> 个问题
+
+### 阶段 5：STRIDE Threat Model  ✅ / ❌ / ⏭ 跳过
+  发现：<N> 个问题
+
+---
+
+### 需要立即修复（CRITICAL）
+
+1. <问题> — <修复步骤>
+
+### 建议修复（HIGH）
+
+1. <问题> — <修复步骤>
+
+### 安全评级：A / B / C / D / F
+```
+
+## 安全评级标准
+
+| 级别 | 标准 |
+|------|------|
+| A | 零 CRITICAL，零 HIGH |
+| B | 零 CRITICAL，1-3 个 HIGH |
+| C | 1 个 CRITICAL 或 4+ 个 HIGH |
+| D | 2+ 个 CRITICAL |
+| F | 涉及数据泄露/权限提升的 CRITICAL |
+
+## 提示
+
+- Daily 模式保持零噪音——只报告需要关注的问题
+- Comprehensive 模式用于月审或大版本发布前
+- 发现 secrets 泄露后立即指导用户轮换密钥
+- 不要为了检查而检查——每个问题要提供可操作的修复步骤

package/templates/commands/gstack/office-hours.md.ejs

@@ -0,0 +1,109 @@
+---
+name: "Office Hours"
+description: "YC Office Hours — 产品需求验证：值不值得做，最小切口是什么，用户是否有迫切需求"
+category: "Planning"
+tags: ["需求", "策略", "验证", "gstack"]
+---
+
+# Office Hours
+
+## 职责
+
+在动手写代码之前，先验证这个想法是否值得做。来自 gstack `/office-hours`。
+
+核心问题：**在投入大量时间之前，确认你要解决的确实是真正的问题。**
+
+## 两种模式
+
+### Startup 模式（新产品/新功能探索）
+
+用六个强制性问题挑战需求假设：
+
+1. **需求现实** — 用户现在用什么方式解决这个问题？（如果没有现行的替代方案，可能不是真需求）
+2. **现状束缚** — 用户为什么不能/不愿意继续用现有方案？
+3. **迫切程度** — 这个问题有多痛？用户愿意花多少钱/时间解决？
+4. **最小切口** — 最窄的场景是什么？只做一件什么事就能验证？
+5. **观察方式** — 你怎么知道用户真的用了、真的需要？
+6. **未来适配** — 6 个月后这个方案还能持续满足吗？
+
+### Builder 模式（业余项目/Hackathon/学习项目）
+
+面向构建者的设计思考：
+
+1. 你想创造什么体验？
+2. 相似的项目有哪些？你与它们的不同是什么？
+3. 你手里有哪些工具/资源/技能？
+4. 如果只做 20%，实现 80% 的体验——砍掉哪 80%？
+5. 你个人最兴奋的 1 个点是什么？（聚焦那个点）
+
+## 工作模式
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 面向非专业编程人员（Vibe Coder）
+
+- 用生活化的语言提问，不要用 "demand validation"、"market sizing" 之类的词
+- 用户可能描述的是"我想做一个 XX 工具"，你不知道是市场还是个人需求
+- 帮用户分清"真需求"和"一时兴起"
+- 如果需求不够聚焦，帮用户缩小到最小可用版本
+- 用类比和举例帮用户理解
+` : `
+### 面向专业开发者
+
+- 可以直接讨论 TAM、竞争格局、商业模式
+- 关注技术可行性和资源约束
+- 可以一起做竞品分析和技术预研
+` %>
+
+## 步骤
+
+### 1. 理解需求
+
+用户描述想做什么。不要急于挑战，先完整理解。
+
+### 2. 选择模式
+
+根据需求的成熟度选择模式：
+- 用户很确定要做 → Startup 模式
+- 用户还在探索/不确定 → Builder 模式
+- 用户可以自己选
+
+### 3. 逐问题讨论
+
+一个问题一个问题地引导讨论。每轮只问一个问题，等用户回答后再继续。
+
+### 4. 产出决策记录
+
+讨论结束后，将结论写入 `docs/designs/YYYY-MM-DD-<topic>-office-hours.md`：
+
+```markdown
+# Office Hours: <主题>
+日期: YYYY-MM-DD
+
+## 核心判断
+<值不值得做？为什么？>
+
+## 最小切口
+<P0 是什么？>
+
+## 关键风险
+<最可能失败的原因？>
+
+## 下一步
+<做什么？>
+```
+
+## 什么时候用 / 什么时候不用
+
+| 用 `/office-hours` | 跳过 |
+|-------------------|------|
+| 新功能想法 | Bug 修复 |
+| 新产品方向 | 纯技术重构 |
+| 用户说"我想做 X..." | 用户说"修复 Y" |
+| 不确定优先级 | 需求已在 PRD 中明确 |
+| 探讨"值不值得做" | 已经确定了要做，只需"怎么做" |
+
+## 与其他命令的关系
+
+- `/office-hours` → 确认值得做 → `/brainstorm` → 方案设计
+- `/office-hours` → 确认不值得做 → 记录原因，不用再深入
+- `/office-hours` → 不确定 → 建议先做小实验验证

package/templates/commands/gstack/review.md.ejs

@@ -0,0 +1,192 @@
+---
+name: "Review"
+description: "Pre-landing PR 代码审查 — 分析 git diff 的结构性问题。源自 gstack /review"
+category: "Quality"
+tags: ["审查", "代码质量", "PR", "gstack"]
+---
+
+# Review
+
+## 职责
+
+在 PR 合并前对代码变更进行结构化审查。分析 git diff 中的结构性问题、安全风险、性能隐患，并分类定级。
+
+## 工作模式
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 面向非专业编程人员（Vibe Coder）
+
+审查就是"找人帮你检查代码有没有问题"：
+- 每个问题会用通俗语言解释
+- 同时展示"有问题的代码"和"修改后的代码"——对比看
+- 告诉你问题严重程度：红色的要必须修，黄色的最好修，蓝色的可修可不修
+- 不要觉得被批评——审查是为了保护你的代码质量
+- 如果看不懂某个问题，直接问，我会解释
+` : `
+### 面向专业开发者
+
+- 关注结构性问题和业务逻辑正确性
+- 按 CRITICAL / HIGH / MEDIUM / LOW 定级
+- 只阻断 CRITICAL 和 HIGH 级别问题
+- 提供具体的行级反馈
+` %>
+
+## 步骤
+
+### 步骤 1：获取变更范围
+
+确定要审查的 diff：
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 获取变更内容
+
+运行以下命令获取所有变更：
+
+\`\`\`bash
+git diff main...HEAD
+\`\`\`
+
+（如果用的是 master 分支，把 main 换成 master）
+` : `
+\`\`\`bash
+git diff <base-branch>...HEAD
+\`\`\`
+
+自动检测 base branch（master/main），如果检测失败，让用户指定。
+` %>
+
+同时获取变更列表：
+
+```bash
+git diff --name-only <base-branch>...HEAD
+git diff --stat <base-branch>...HEAD
+```
+
+### 步骤 2：结构化分析
+
+从以下维度分析每次变更：
+
+#### 1. SQL 安全（如有数据库变更）
+
+```
+□ 缺少索引：WHERE/ORDER BY/JOIN 列是否已有索引？
+□ N+1 查询：是否有循环中查询数据库？
+□ 迁移风险：数据迁移是否可回滚？
+□ SQL 注入：是否使用了参数化查询？
+```
+
+#### 2. LLM 信任边界违规
+
+```
+□ 用户输入直接拼接到 prompt/系统指令中？
+□ 是否有 prompt injection 风险？
+□ LLM 输出是否经过验证再使用？
+□ 敏感数据是否可能通过 prompt 泄露？
+```
+
+#### 3. 条件副作用
+
+```
+□ 条件判断中是否有副作用（赋值、API 调用）？
+□ 短路求值是否可能导致意外的跳过？
+□ if/else 分支是否覆盖了所有可能？
+```
+
+#### 4. 错误处理
+
+```
+□ 所有可能失败的操作都有 try-catch？
+□ 错误信息是否泄露了敏感信息？
+□ 失败路径是否会导致资源泄漏（连接未关闭、文件句柄未释放）？
+□ 是否有静默吞错误（空的 catch 块）？
+```
+
+#### 5. 安全
+
+```
+□ 认证：新的 API 端点是否有权限检查？
+□ 输入验证：用户输入是否经过验证？
+□ 敏感数据：日志中是否记录了密码/token？
+□ XSS/CSRF：前端是否做了输出转义？
+```
+
+### 步骤 3：问题分类定级
+
+每个问题按以下标准分类：
+
+| 级别 | 含义 | 动作 | 颜色 |
+|------|------|------|------|
+| **CRITICAL** | 必须修复 — 会导致数据丢失/安全漏洞/生产故障 | 阻断合并 | 🔴 |
+| **HIGH** | 强烈建议修复 — 大概率引发 bug | 建议修复 | 🟠 |
+| **MEDIUM** | 值得修复 — 未来可能出问题 | 考虑修复 | 🟡 |
+| **LOW** | 风格偏好 — 不影响功能 | 可忽略 | 🔵 |
+
+**问题报告格式：**
+
+```
+### [CRITICAL] <问题简述>
+- **文件**: `path/to/file.ts:L42-L48`
+- **问题**: <详细说明>
+- **风险**: 如果不修复会导致...
+- **修复建议**:
+
+  ```diff
+  - // 有问题的代码
+  + // 修复后的代码
+  ```
+
+---
+
+### [HIGH] <问题简述>
+- **文件**: `path/to/file.ts:L100`
+- **问题**: <详细说明>
+- **修复建议**: <具体建议>
+---
+```
+
+### 步骤 4：生成审查报告
+
+```
+## Review 报告
+
+分支：feature/xxx → <base-branch>
+变更文件：N 个 | 新增：+N | 删除：-N
+
+### 摘要
+
+- CRITICAL：N 个（必须修复）
+- HIGH：N 个（建议修复）
+- MEDIUM：N 个（考虑修复）
+- LOW：N 个（风格偏好）
+
+### 详细问题
+
+[CRITICAL] ...
+[HIGH] ...
+[MEDIUM] ...
+[LOW] ...
+
+### 总体评价
+
+<简短评价代码质量，建议接收/条件接收/拒绝>
+```
+
+### 步骤 5：重新审查
+
+用户修复问题后，再次运行 `/review` 确认所有 CRITICAL/HIGH 问题已修复。重复直到通过。
+
+## 阻断规则
+
+**以下情况必须标记为 CRITICAL：**
+- 密码/token/密钥硬编码
+- SQL 注入漏洞
+- 认证绕过（无权限检查的 API）
+- 可能导致数据丢失的变更
+- 严重 N+1 查询（循环中查询数据库）
+
+## 提示
+
+- 保持审查客观、专业。不评价编码风格偏好，除非项目有明确规范
+- 对于误报，在报告中说明"已确认为误报"
+- 如果 diff 很大（>500 行），聚焦在关键逻辑变更上
+- `/ship` 命令会自动调用 `/review`，并在有 CRITICAL 问题时中止