create-vibe-workflow 0.1.0 → 0.2.0

package/dist/templates/commands/opsx/explore.md.ejs

@@ -0,0 +1,84 @@
+---
+name: "OPSX: Explore"
+description: "以探索模式分析问题、研究代码、比较方案，不修改任何代码"
+category: "Workflow"
+tags: ["探索", "分析", "研究", "OpenSpec"]
+---
+
+# OPSX: Explore
+
+## 职责
+
+这是一个 **探索姿态**，不是固定工作流。当用户对某个问题还没有清晰想法时，用这个命令自由探索。**禁止修改任何代码或文件**。
+
+## 你可以做
+
+- ✅ **阅读代码**：理解现有实现、接口定义、模块结构
+- ✅ **搜索查询**：用 Grep / Glob 查找相关代码
+- ✅ **分析问题**：定位 Bug 根因、性能瓶颈、设计缺陷
+- ✅ **画图说明**：用 ASCII 图表（流程图、架构图、时序图）帮助理解
+- ✅ **提问澄清**：向用户询问更多细节
+- ✅ **方案对比**：列出多个方案的优劣，辅助决策
+- ✅ **技术调研**：分析某个库 / API / 模式的适用性
+- ✅ **风险评估**：识别实现某个功能可能的风险点
+- ✅ **阅读文档**：查看项目的文档、设计文档、PRD 等
+
+## 你不能做
+
+- ❌ **修改任何代码文件**
+- ❌ **创建新文件**
+- ❌ **运行修改文件的命令**（如代码生成器 scaffold）
+- ❌ **标记任务为完成**
+- ❌ **做出设计决策**（只能提供分析供用户决策）
+
+## 常见场景
+
+### 场景 1：模糊的想法
+
+用户说"我想要一个登录功能"，但不确定具体要什么。你可以：
+1. 检查项目是否有已有的认证方案
+2. 分析常见的登录方案（邮箱密码 / OAuth / 手机号）
+3. 列出每种方案的优劣
+4. 询问用户的具体需求
+
+### 场景 2：问题调查
+
+用户说"列表页面很慢"。你可以：
+1. 查看列表页面代码
+2. 分析数据查询、渲染逻辑
+3. 查找潜在性能瓶颈
+4. 给出优化建议（不实现）
+
+### 场景 3：方案比较
+
+用户说"用 Prisma 还是 Drizzle？"。你可以：
+1. 阅读项目现有数据库代码
+2. 对比两个 ORM 的特性和项目适配度
+3. 给出推荐和理由
+4. 让用户决策
+
+### 场景 4：代码理解
+
+用户说"这个模块怎么工作的？"你可以：
+1. 阅读模块代码
+2. 绘制数据流图
+3. 解释关键逻辑
+
+## 结束方式
+
+探索没有强制产出，可以自然结束：
+
+| 情况 | 做法 |
+|------|------|
+| 用户明确了想法 | 建议下一步运行 `/opsx:propose` |
+| 用户要做决策 | 提供分析摘要，让用户决策 |
+| 用户没有进一步问题 | 询问"还有什么需要探索的吗？" |
+| 用户决定实现 | 建议 `/opsx:propose` → `/opsx:apply` |
+
+## 提示
+
+- 探索时不预设结论，保持开放心态
+- 多问"为什么"，帮用户理清真实需求
+- 画 ASCII 图表非常有价值，比文字描述高效得多
+- 如果发现明显的问题（如安全漏洞），可以指出但 **不要修复**
+- 探索过程中如果用户提出"能不能帮我改一下"，提醒用户切换到 apply 模式

package/dist/templates/commands/opsx/propose.md.ejs

@@ -0,0 +1,185 @@
+---
+name: "OPSX: Propose"
+description: "将需求想法转化为结构化规格文档（提案 + 设计 + 任务拆解），项目根目录下的 openspec/changes/ 中"
+category: "Workflow"
+tags: ["需求", "规划", "规格", "OpenSpec"]
+---
+
+# OPSX: Propose
+
+## 职责
+
+将用户的一个需求想法（自然语言描述）转化为可执行的结构化规格文档。产出三个文件到 `openspec/changes/<change-name>/` 目录：
+
+| 文件 | 内容 |
+|------|------|
+| `proposal.md` | 做什么 & 为什么做、范围界定、P0/P1 优先级划分 |
+| `design.md` | 怎么做、架构方案、关键决策 |
+| `tasks.md` | 可检查的任务清单（每个任务 = 一个独立 commit） |
+
+## 工作模式
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 面向非专业编程人员（Vibe Coder）
+
+用户可能没有技术背景。你的任务是：
+- **引导式提问**：用自然语言追问，帮用户理清需求
+- **翻译成技术语言**：把用户的"我想要一个登录页面"翻译为功能规格
+- **不做假设**：不清楚的地方用 AskUserQuestion 确认
+- **给出选项**：设计方案时给 2-3 个选项，说明各自优劣
+` : `
+### 面向专业开发者
+
+- 可以直接讨论技术方案、架构选型
+- 关注实现效率和技术合理性
+- 可以复用项目已有的模式和约定
+` %>
+
+## 步骤
+
+### 步骤 1：理解需求
+
+- 接收用户自然语言描述的需求
+- 如果描述模糊，用 **AskUserQuestion** 追问澄清：
+  - "这个功能解决谁的什么问题？"
+  - "你觉得什么样的输出算做完了？"
+  - "有没有类似的参考？"
+- 提炼出核心目标和验收标准（1-3 条）
+
+### 步骤 2：确定变更名称
+
+- 从需求描述中提取关键词，推导 kebab-case 的变更名称
+- 示例："添加用户登录功能" → `add-user-login`
+- 示例："修复订单列表分页问题" → `fix-order-pagination`
+- 如不确定，向用户确认名称
+
+### 步骤 3：创建目录结构
+
+创建 `openspec/changes/<change-name>/` 目录，包含三个文件：
+- `proposal.md`
+- `design.md`
+- `tasks.md`
+
+> 如果 `openspec/` 目录不存在，先创建它并添加 `.gitkeep`。
+
+### 步骤 4：编写 proposal.md
+
+**做什么 & 为什么做**
+```
+# 提案：<变更名称>
+
+## 概述
+用 1-3 句话说明要做什么，为什么做。
+
+## 用户故事
+作为 <角色>，
+我想要 <功能/能力>，
+以便 <业务价值>。
+
+## 验收标准
+- [ ] P0: ...
+- [ ] P0: ...
+- [ ] P1: ...
+
+## 范围界定
+
+### 在范围内
+- 功能 A
+- 功能 B
+
+### 不在范围内（明确排除）
+- 功能 X（后续迭代）
+- 功能 Y（不相关）
+
+## 优先级
+
+### P0（本次必须完成）
+- ...
+
+### P1（设计时考虑，本次不实现）
+- ...
+```
+
+- P0 是必须完成的核心功能，P1 是后续迭代
+- 验收标准要可检查（能用 yes/no 回答）
+
+### 步骤 5：编写 design.md
+
+**怎么做**
+```
+# 设计：<变更名称>
+
+## 架构方案
+<描述整体方案，含组件/模块交互>
+
+## 关键决策
+
+### 决策 1：<标题>
+- **选项**: A / B / C
+- **选择**: A
+- **理由**: ...
+- **影响**: ...
+
+## 数据流
+<数据如何流转，核心流程>
+
+## 接口/API（如适用）
+<接口定义、参数、返回值>
+
+## 影响分析
+<会影响哪些已有模块，是否需要迁移>
+```
+
+- 保持简洁，重点在关键决策和数据流
+- 不需要过度设计，够下一个步骤的任务拆解用即可
+
+### 步骤 6：编写 tasks.md
+
+**任务清单**
+```
+# 任务：<变更名称>
+
+## P0 任务（本次实现）
+
+- [ ] `<commit-message>` — <描述>（~<估算行数> 行）
+  涉及文件：<file1>, <file2>
+
+## P1 任务（后续迭代）
+
+- [ ] `<commit-message>` — <描述>
+```
+
+- 每个任务对应一个独立 commit
+- 每个任务 50-300 行变更
+- 按照实现顺序排列（依赖前置）
+- 对每个任务标注涉及的文件（方便 AI 定位上下文）
+
+### 步骤 7：展示摘要
+
+生成完成后，用简洁格式向用户展示摘要：
+
+```
+## 摘要
+
+变更：<change-name>
+
+### 做什么
+<一句话说明>
+
+### P0 任务
+1. ...
+2. ...
+
+### P1（后续）
+- ...
+- ...
+
+已生成：openspec/changes/<change-name>/
+```
+
+## 提示
+
+- 如果项目已有其他 `openspec/changes/` 中的提案，先阅读它们以保持一致风格
+- 如果项目有既定的架构约定（如 NestJS 模块结构），在 design.md 中遵循
+- Proposal.md 保持业务语言，design.md 可以进入技术细节
+- 不确定的技术方案，**先研究再决定**，而不是猜测

package/dist/templates/commands/superpowers/brainstorm.md.ejs

@@ -0,0 +1,240 @@
+---
+name: "Brainstorm"
+description: "将模糊想法转化为具体设计文档，在写任何代码前执行。源自 Superpowers brainstorming"
+category: "Planning"
+tags: ["设计", "规划", "头脑风暴", "Superpowers"]
+---
+
+# Brainstorm
+
+## 职责
+
+将用户的一个模糊想法或需求，通过结构化思考转化为具体设计文档。**禁止编写任何实现代码**——本命令的唯一产出是一份设计文档。
+
+## HARD GATE（硬性约束）
+
+> **禁止：**
+> - 编写任何实现代码
+> - 创建任何项目脚手架
+> - 修改任何源代码文件
+> - 生成代码片段（除设计文档中的伪代码示例外）
+>
+> **唯一允许的产出：**
+> - `docs/designs/YYYY-MM-DD-<topic>.md` 设计文档
+> - 相关 git commit（仅包含设计文档）
+
+## 工作模式
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+### 面向非专业编程人员（Vibe Coder）
+
+用户可能没有技术背景。你的职责是翻译器和引导者：
+- **用自然语言交流**：避免技术术语，或用通俗比喻解释
+- **帮用户理清想法**：用户可能只有一个模糊的需求，通过提问帮他们聚焦
+- **翻译技术概念**：把用户的"我想要一个类似淘宝的页面"翻译为功能模块
+- **给出简单选项**：设计方案时给 2-3 个选项，用日常语言说明优劣
+- **逐步确认**：每完成一个设计部分就询问"这个部分你觉得对吗？"
+- **控制范围**：提醒用户不要一次做太多，聚焦最小可行方案
+` : `
+### 面向专业开发者
+
+- 可以直接讨论技术方案、架构模式、设计模式
+- 关注实现效率、可维护性、技术合理性
+- 可以复用项目已有的模式和约定
+- 使用适当的抽象层级讨论（领域层、应用层、基础设施层）
+- 关注可测试性、可扩展性、性能边界
+` %>
+
+## 步骤
+
+### 步骤 1：探索项目上下文
+
+在开始设计前，了解当前项目：
+
+1. 读取 `docs/` 目录下已有的设计文档和 PRD
+2. 检查项目结构（`src/`、`packages/` 等）了解已有约定
+3. 查看最近的 git commit 了解开发节奏
+4. 如果项目有 `CLAUDE.md`，阅读项目说明
+5. 如果项目有 `openspec/` 目录，阅读最近的提案
+
+**目的**：确保新设计不重复已有功能，符合项目既有模式。
+
+### 步骤 2：逐一问 clarifying questions
+
+一次只问 **一个问题**，等待用户回答后再问下一个。
+
+**必须先澄清的问题：**
+
+| 问题 | 目的 |
+|------|------|
+| "这个功能解决谁的什么问题？" | 确定用户和目标 |
+| "你觉得什么样的输出算做完了？" | 确定验收标准 |
+| "有没有类似的参考（网站、应用、截图）？" | 对齐视觉/功能预期 |
+| "这个功能影响现有功能吗？" | 确定影响范围 |
+| "你希望什么时候能用上？" | 确定时间约束 |
+
+**约束确认：**
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+- "你希望用户登录后才能用，还是所有人能用？"
+- "数据存哪里方便？电脑本地还是服务器？"
+- "多少人会用这个功能？"
+` : `
+- "认证方案用什么？JWT / Session / OAuth？"
+- "数据存储用现有 DB 还是引入新的存储？"
+- "预期并发量级？这可能影响架构选择。"
+` %>
+
+### 步骤 3：提出 2-3 个方案
+
+针对需求，提出 2-3 个可行方案，每个方案包括：
+
+```
+## 方案 A：<名称>
+- **做法**：简短的实现描述
+- **优点**：2-3 个优点
+- **缺点**：1-2 个缺点
+- **复杂度**：低/中/高
+- **预估工时**：<时间估算>
+
+## 方案 B：<名称>
+...
+
+## 方案 C（可选）：<名称>
+...
+```
+
+**提出推荐方案**并说明理由：
+
+```
+## 推荐：方案 <X>
+理由：<1-2 句话说明为什么推荐该方案>
+```
+
+用户确认方案后再进入下一步。
+
+### 步骤 4：分部分设计，逐部分确认
+
+将设计拆分为以下部分，**每完成一部分就向用户确认**：
+
+#### 第一部分：功能范围
+
+```
+## 功能范围
+
+### 在范围内（本次做）
+- 功能 A
+- 功能 B
+
+### 不在范围内（明确排除）
+- 功能 C（后续迭代）
+- 功能 D（不相关）
+```
+
+#### 第二部分：数据模型（如有）
+
+```
+## 数据模型
+
+### 实体
+- **User**：id, name, email, role, createdAt
+- **Order**：id, userId, status, total, createdAt
+
+### 关系
+- User 1:N Order
+```
+
+#### 第三部分：用户界面 / API
+
+```
+## 界面 / API
+
+### 页面/端点
+1. `/login` — 登录页面（邮箱 + 密码）
+2. `/register` — 注册页面
+...
+```
+
+#### 第四部分：数据流
+
+```
+## 数据流
+
+### 核心流程
+1. 用户访问页面 →
+2. 系统检查认证状态 →
+3. 未认证用户重定向到登录页 →
+4. ...
+```
+
+<%= USER_LEVEL === 'vibe-coder' ? `
+每次确认时用通俗语言："这个部分你看对不对？有需要调整的地方吗？"
+` : `
+每次确认："这个设计部分是否符合预期？有没有需要补充的技术细节？"
+` %>
+
+### 步骤 5：编写设计文档
+
+写入 `docs/designs/YYYY-MM-DD-<topic>.md`，格式：
+
+```markdown
+# 设计：<项目名称>
+
+## 概述
+<1-3 句话说明这个设计要做什么>
+
+## 背景
+<为什么需要这个功能，解决什么问题>
+
+## 方案选择
+<选中的方案和理由>
+
+## 功能范围
+### 范围内
+### 范围外
+
+## 数据模型
+...
+
+## 界面 / API
+...
+
+## 数据流
+...
+
+## 影响分析
+<会影响哪些已有模块，是否需要迁移>
+
+## 验收标准
+- [ ] P0: ...
+- [ ] P1: ...
+
+## 设计日期
+<%= GENERATED_AT.split('T')[0] %>
+
+## 设计者
+create-vibe-workflow / Brainstorm command
+```
+
+> 如果 `docs/designs/` 目录不存在，先创建。
+
+### 步骤 6：提交设计文档
+
+```bash
+git add docs/designs/YYYY-MM-DD-<topic>.md
+git commit -m "docs: 添加 <topic> 设计文档"
+```
+
+## 设计原则
+
+- **先理解再设计**：没有理解需求之前不要急于给方案
+- **保持聚焦**：控制范围，避免功能蔓延
+- **逐部分确认**：不要在全部完成后才让用户反馈
+- **记录决策**：设计文档要记录"为什么选 A 不选 B"
+- **足够就好**：设计文档不是详细规格，够下一步规划用即可
+
+## 下一步
+
+设计文档提交后，建议用户运行：
+- `/plan` — 将设计拆解为 commit 级任务
+- 然后进入开发阶段