create-vibe-workflow 0.1.0 → 0.2.0

package/dist/templates/claude-md/CLAUDE.zh-CN.md

@@ -1,46 +1,51 @@
-<!-- WORKFLOW-START -->
-<!-- 此区域由 create-vibe-workflow 自动生成，重跑 CLI 时会更新 -->
-
-## AI 协作工具链
-
-本项目使用多层 AI 工具协作体系：
-
-```
-你的业务需求
-  ↓
-① OpenSpec ─── 把想法变成结构化的需求规格和任务清单
-  ↓
-② gstack ───── 虚拟团队角色审查（CEO审查/设计审查/工程审查）
-  ↓
-③ Superpowers ─ 强制执行正确的开发流程（TDD/系统调试/验证）
-```
-
-### 标准开发流程
-
-```
-① 需求澄清（OpenSpec）→ ② 计划拆分 → ③ 研究复用
-→ ④ TodoList编写 → ⑤ TDD开发 → ⑥ 代码审查
-→ ⑦ 安全审查 → ⑧ 文档反写 → ⑨ 提交归档
-```
-
-### 常用命令
-
-| 场景 | 命令 |
-|------|------|
-| 开发新功能 | `/opsx:propose` 开始 |
-| 修 Bug | 自动触发 `systematic-debugging` |
-| 审查代码 | `/review` |
-| 验收功能 | `/qa` |
-| 准备发布 | `/ship` |
-| 安全审查 | `/cso` |
-
-## 技术栈
-
-- 语言: TypeScript 5.x (strict mode)
-- 前端: Next.js 15 (App Router) + shadcn/ui + Tailwind CSS
-- 后端: NestJS 11 (REST API)
-- 数据库: PostgreSQL 16+ + Drizzle ORM
-- 校验: Zod（前后端共享 schema）
-- 测试: Vitest (单元) + Playwright (E2E)
-
-<!-- WORKFLOW-END -->
+<!-- WORKFLOW-START -->
+<!-- 此区域由 create-vibe-workflow 自动生成，重跑 CLI 时会更新 -->
+
+## AI 协作工具链
+
+本项目使用多层 AI 工具协作体系，确保代码质量和开发纪律：
+
+```
+你的业务需求
+  ↓
+① 需求规格化 — 把想法变成结构化需求
+  ↓
+② 计划审查 — 拆解任务、验证假设、识别风险
+  ↓
+③ 流程纪律 — TDD / 文档反写 / 安全检查 / 代码审查
+```
+
+### 标准开发流程
+
+> 完整 9 步流程（含各步骤完成标志 / 跳过条件）见 `.claude/rules/development-workflow.md`
+
+### 常用命令
+
+| 场景 | 命令 | 说明 |
+|------|------|------|
+| 开发新功能 | 从第①步开始 | 先澄清需求，再拆计划 |
+| 修 Bug | 先写复现步骤 → ⑤→⑥ | 遵循 TDD + 审查流程 |
+| 代码审查 | 第⑥步 | 写完代码立即执行 |
+| 安全检查 | 第⑦步 | 敏感模块必须执行 |
+| 提交代码 | 第⑧→⑨步 | 同步文档后再提交 |
+
+## 技术栈
+
+- **语言**: TypeScript 5.x (strict mode)
+- **前端**: Next.js 15 (App Router) + shadcn/ui + Tailwind CSS
+- **后端**: NestJS 11 (REST API)
+- **数据库**: PostgreSQL 16+ + Drizzle ORM
+- **校验**: Zod（前后端共享 schema）
+- **测试**: Vitest (单元) + Playwright (E2E)
+
+## 项目约定
+
+| 约定 | 说明 |
+|------|------|
+| 代码风格 | 见 `.claude/rules/coding-style.md` |
+| Git 规范 | 见 `.claude/rules/git-workflow.md` |
+| 测试要求 | 见 `.claude/rules/testing.md` |
+| 安全标准 | 见 `.claude/rules/security.md`（仅 auth/finance/system 模块强制执行） |
+| 设计模式 | 统一使用 Repository + Service 层 |
+
+<!-- WORKFLOW-END -->

package/dist/templates/claude-md/next-only/CLAUDE.zh-CN.md

@@ -0,0 +1,46 @@
+<!-- WORKFLOW-START -->
+<!-- 此区域由 create-vibe-workflow 自动生成，重跑 CLI 时会更新 -->
+
+## AI 协作工具链
+
+本项目使用多层 AI 工具协作体系：
+
+```
+你的业务需求
+  ↓
+① 需求规格化 — 把想法变成结构化需求
+  ↓
+② 计划审查 — 拆解任务、验证假设
+  ↓
+③ 流程纪律 — TDD / 文档反写 / 安全检查
+```
+
+### 标准开发流程
+
+```
+① 需求澄清 → ② 计划拆分 → ③ 研究复用
+→ ④ TodoList编写 → ⑤ TDD开发 → ⑥ 代码审查
+→ ⑦ 安全审查 → ⑧ 文档反写 → ⑨ 提交归档
+```
+
+### 常用命令
+
+| 场景 | 命令 |
+|------|------|
+| 开发新功能 | 从第①步开始，先写 PRD/用户故事 |
+| 修 Bug | 先写复现步骤，再修 |
+| 审查代码 | 每次写完代码后执行 |
+| 提交代码 | 检查文档同步后提交 |
+
+## 技术栈
+
+- 语言: TypeScript 5.x (strict mode)
+- 框架: Next.js 15 (App Router)
+- UI: shadcn/ui + Tailwind CSS 4
+- 样式: CSS Modules / Tailwind CSS
+- 状态管理: React hooks + Server State (SWR/TanStack Query)
+- 校验: Zod schema
+- 测试: Vitest (单元) + Playwright (E2E)
+- 部署: Vercel
+
+<!-- WORKFLOW-END -->

package/dist/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/dist/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/dist/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` → 不确定 → 建议先做小实验验证