@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/tasks/create-next-story.md

@@ -0,0 +1,114 @@
+<!-- Powered by BMAD™ Core -->
+
+# 创建下一个 Story 任务
+
+## 目的
+
+根据项目进度和 epic 定义，识别下一个逻辑 story，然后用 `Story Template` 准备一个全面、自包含且可执行的 story 文件。这个任务确保 story 包含所有必要的技术上下文、需求和 acceptance criteria，让 Developer Agent 能够高效实现，不用额外研究或自己找上下文。
+
+## 顺序任务执行（当前任务完成前别继续）
+
+### 0. 加载核心配置并检查工作流
+
+- 从项目根目录加载 `.bmad-core/core-config.yaml`
+- 如果文件不存在，停下来告诉用户："core-config.yaml 没找到。这个文件是创建 story 必需的。你可以：1) 从 GITHUB bmad-core/core-config.yaml 复制并配置给你的项目 或者 2) 对你的项目运行 BMad 安装器来自动升级并添加文件。请先添加并配置 core-config.yaml 再继续。"
+- 提取关键配置：`devStoryLocation`、`prd.*`、`architecture.*`、`workflow.*`
+
+### 1. 识别下一个要准备的 Story
+
+#### 1.1 定位 Epic 文件并检查现有 Stories
+
+- 根据配置中的 `prdSharded`，定位 epic 文件（分片位置/模式或单体 PRD 部分）
+- 如果 `devStoryLocation` 有 story 文件，加载最高的 `{epicNum}.{storyNum}.story.md` 文件
+- **如果最高 story 存在：**
+  - 验证状态是 'Done'。如果不是，提醒用户："警告：发现未完成的 story！文件：{lastEpicNum}.{lastStoryNum}.story.md 状态：[当前状态] 你应该先修复这个 story，但你想接受风险并覆盖创建下一个 draft story 吗？"
+  - 如果继续，选择当前 epic 中的下一个顺序 story
+  - 如果 epic 完成，提示用户："Epic {epicNum} 完成：Epic {epicNum} 中的所有 stories 都已完成。你想：1) 开始 Epic {epicNum + 1} 的 story 1 2) 选择特定 story 来搞 3) 取消 story 创建"
+  - **关键**：永远别自动跳到另一个 epic。用户必须明确指示要创建哪个 story。
+- **如果没有 story 文件存在：** 下一个 story 总是 1.1（第一个 epic 的第一个 story）
+- 向用户宣布识别的 story："识别到下一个要准备的 story：{epicNum}.{storyNum} - {Story Title}"
+
+### 2. 收集 Story 需求和前一个 Story 上下文
+
+- 从识别的 epic 文件中提取 story 需求
+- 如果前一个 story 存在，检查 Dev Agent Record 部分：
+  - Completion Notes 和 Debug Log References
+  - Implementation deviations 和技术决策
+  - 遇到的挑战和 lessons learned
+- 提取为当前 story 准备提供信息的相关见解
+
+### 3. 收集架构上下文
+
+#### 3.1 确定架构阅读策略
+
+- **如果 `architectureVersion: >= v4` 且 `architectureSharded: true`**：读取 `{architectureShardedLocation}/index.md` 然后按下面的 structured reading order
+- **否则**：用 monolithic `architectureFile` 获取类似部分
+
+#### 3.2 根据 Story 类型读取架构文档
+
+**For ALL Stories：** tech-stack.md、unified-project-structure.md、coding-standards.md、testing-strategy.md
+
+**For Backend/API Stories，额外：** data-models.md、database-schema.md、backend-architecture.md、rest-api-spec.md、external-apis.md
+
+**For Frontend/UI Stories，额外：** frontend-architecture.md、components.md、core-workflows.md、data-models.md
+
+**For Full-Stack Stories：** 读取上面 Backend 和 Frontend 两个部分
+
+#### 3.3 提取 Story 特定技术细节
+
+只提取与实现当前 story 直接相关的信息。别发明源文档中没有的新库、模式或标准。
+
+Extract：
+
+- Story 将使用的特定 data models、schemas 或 structures
+- Story 必须实现或消费的 API endpoints
+- Story 中 UI 元素的 component specifications
+- 新代码的 file paths 和 naming conventions
+- Story 功能特定的 testing requirements
+- 影响 Story 的 security 或 performance considerations
+
+ALWAYS cite source documents：`[Source: architecture/{filename}.md#{section}]`
+
+### 4. 验证项目结构对齐
+
+- 把 story 需求与 `docs/architecture/unified-project-structure.md` 中的 Project Structure Guide 交叉引用
+- 确保 file paths、component locations 或 module names 与定义的结构对齐
+- 在 story draft 的"Project Structure Notes"部分记录任何结构冲突
+
+### 5. 用完整上下文填充 Story 模板
+
+- 用 Story 模板创建新的 story 文件：`{devStoryLocation}/{epicNum}.{storyNum}.story.md`
+- 填写基本 story 信息：Title、Status (Draft)、Story statement、来自 Epic 的 Acceptance Criteria
+- **`Dev Notes` 部分（关键）：**
+  - 关键：这个部分必须只包含从架构文档中提取的信息。永远别发明或假设技术细节。
+  - 包含步骤 2-3 中所有相关技术细节，按类别组织：
+    - **Previous Story Insights**：从前一个 story 中学到的关键经验
+    - **Data Models**：特定 schemas、validation rules、relationships [带源引用]
+    - **API Specifications**：endpoint details、request/response formats、auth requirements [带源引用]
+    - **Component Specifications**：UI component details、props、state management [带源引用]
+    - **File Locations**：基于项目结构应该创建新代码的确切路径
+    - **Testing Requirements**：来自 testing-strategy.md 的特定测试用例或策略
+    - **Technical Constraints**：version requirements、performance considerations、security rules
+  - 每个技术细节都必须包含其源引用：`[Source: architecture/{filename}.md#{section}]`
+  - 如果在架构文档中找不到某个类别的信息，明确说明："在架构文档中没找到具体指导"
+- **`Tasks / Subtasks` 部分：**
+  - 仅基于以下内容生成详细、顺序的技术任务列表：Epic Requirements、Story AC、Reviewed Architecture Information
+  - 每个任务必须引用相关架构文档
+  - 根据 Testing Strategy 将 unit testing 作为明确的子任务包含
+  - 在适用时链接任务到 AC（例如，`Task 1 (AC: 1, 3)`）
+- 添加在步骤 4 中发现的项目结构对齐或差异的笔记
+
+### 6. Story Draft 完成和审查
+
+- 审查所有部分的完整性和准确性
+- 验证所有技术细节都包含源引用
+- 确保任务与 epic requirements 和 architecture constraints 都对齐
+- 更新状态为"Draft"并保存 story 文件
+- 执行 `.bmad-core/tasks/execute-checklist` `.bmad-core/checklists/story-draft-checklist`
+- 向用户提供摘要，包括：
+  - 创建的 Story：`{devStoryLocation}/{epicNum}.{storyNum}.story.md`
+  - 状态：Draft
+  - 从架构文档中包含的关键 technical components
+  - Epic 和架构之间注意到的任何 deviations 或 conflicts
+  - Checklist Results
+  - 下一步：对于复杂 stories，建议用户仔细审查 story draft，也可以选择让 PO 运行任务 `.bmad-core/tasks/validate-next-story`

package/.knowledge/.ext/.bmad-core/tasks/document-project.md

@@ -0,0 +1,345 @@
+<!-- Powered by BMAD™ Core -->
+
+# 为现有项目生成文档
+
+## 目的
+
+为现有项目生成全面的文档，专门为AI开发代理优化。这个任务创建结构化的参考资料，让AI代理能够理解项目context、约定和模式，从而有效地为任何代码库做出贡献。
+
+## 任务说明
+
+### 1. 初始项目分析
+
+**关键：** 首先检查context中是否存在PRD或需求文档。如果有，用它来专注于相关领域的文档工作。
+
+**如果有PRD**：
+
+- 看看PRD了解计划中的enhancement/功能
+- 识别哪些模块、服务或领域会受到影响
+- 只专注于这些相关领域的文档
+- 跳过代码库中不相关的部分，保持文档精简
+
+**如果没有PRD**：
+询问用户：
+
+"我注意到你没有提供PRD或需求文档。为了创建更有针对性和有用的文档，我建议以下选项之一：
+
+1. **先创建PRD** - 你想让我在文档化之前帮你创建一个brownfield PRD吗？这有助于专注于相关领域的文档。
+
+2. **提供现有需求** - 你有需求文档、epic或功能描述可以分享吗？
+
+3. **描述重点** - 你能简单描述一下你计划做什么enhancement或功能吗？比如：
+   - '给用户服务添加支付处理'
+   - '重构认证模块'
+   - '集成新的第三方API'
+
+4. **全部文档化** - 或者我应该对整个代码库进行全面的文档化？(注意：对于大型项目可能会产生过多的文档)
+
+请告诉我你的偏好，或者如果你愿意，我可以进行完整的文档化。"
+
+根据他们的回复：
+
+- 如果他们选择选项1-3：用那个context来专注于文档
+- 如果他们选择选项4或拒绝：继续下面的全面分析
+
+开始对现有项目进行分析。使用可用工具来：
+
+1. **项目结构发现**：检查根目录结构，识别主要文件夹，了解整体组织
+2. **技术栈识别**：找找package.json、requirements.txt、Cargo.toml、pom.xml等来识别语言、框架和依赖
+3. **构建系统分析**：找到构建脚本、CI/CD配置和开发命令
+4. **现有文档审查**：检查README文件、docs文件夹和任何现有文档
+5. **代码模式分析**：采样关键文件来理解编码模式、命名约定和架构方法
+
+问问用户这些引导问题来更好地理解他们的需求：
+
+- 这个项目的主要目的是什么？
+- 代码库中是否有特别复杂或对代理理解很重要的特定领域？
+- 你期望AI代理在这个项目上执行什么类型的任务？(比如，bug修复、功能添加、重构、测试)
+- 你有任何偏好的现有文档标准或格式吗？
+- 文档应该针对什么级别的技术细节？(初级开发者、高级开发者、混合团队)
+- 你计划有什么特定的功能或enhancement吗？(这有助于专注于文档)
+
+### 2. 深度代码库分析
+
+关键：在生成文档之前，对现有代码库进行广泛分析：
+
+1. **探索关键领域**：
+   - 入口点(主文件、index文件、应用初始化器)
+   - 配置文件和环境设置
+   - 包依赖和版本
+   - 构建和部署配置
+   - 测试套件和覆盖率
+
+2. **询问澄清问题**：
+   - "我看到你在用[技术X]。有什么自定义模式或约定我应该文档化吗？"
+   - "这个系统中最关键/复杂的部分是什么，开发者经常遇到困难？"
+   - "有什么未文档化的'部落知识'领域我应该捕获吗？"
+   - "我应该文档化什么技术债务或已知问题？"
+   - "代码库的哪些部分变化最频繁？"
+
+3. **映射现实**：
+   - 识别实际使用的模式(不是理论最佳实践)
+   - 找到关键业务逻辑在哪
+   - 定位集成点和外部依赖
+   - 文档化变通方案和技术债务
+   - 注意与标准模式不同的领域
+
+**如果提供了PRD**：还要分析enhancement需要什么改变
+
+### 3. 核心文档生成
+
+[[LLM: 生成一个全面的BROWNFIELD架构文档，反映代码库的实际状态。
+
+**关键**：这不是一个理想化的架构文档。文档化实际存在的内容，包括：
+
+- 技术债务和变通方案
+- 不同部分之间的不一致模式
+- 无法更改的遗留代码
+- 集成约束
+- 性能瓶颈
+
+**文档结构**：
+
+# [项目名称] Brownfield架构文档
+
+## 介绍
+
+这个文档捕获了[项目名称]代码库的当前状态，包括技术债务、变通方案和现实世界的模式。它作为AI代理进行enhancement工作的参考。
+
+### 文档范围
+
+[如果提供了PRD："专注于相关领域：{enhancement描述}"]
+[如果没有PRD："整个系统的全面文档"]
+
+### 变更日志
+
+| 日期   | 版本 | 描述               | 作者     |
+| ------ | ---- | ------------------ | -------- |
+| [日期] | 1.0  | 初始brownfield分析 | [分析师] |
+
+## 快速参考 - 关键文件和入口点
+
+### 理解系统的关键文件
+
+- **主入口**：`src/index.js`(或实际入口点)
+- **配置**：`config/app.config.js`、`.env.example`
+- **核心业务逻辑**：`src/services/`、`src/domain/`
+- **API定义**：`src/routes/`或链接到OpenAPI规范
+- **数据库模型**：`src/models/`或链接到模式文件
+- **关键算法**：[列出有复杂逻辑的特定文件]
+
+### 如果提供了PRD - enhancement影响领域
+
+[突出显示哪些文件/模块会受到计划enhancement的影响]
+
+## 高级架构
+
+### 技术总结
+
+### 实际技术栈(来自package.json/requirements.txt)
+
+| 类别   | 技术       | 版本   | 备注             |
+| ------ | ---------- | ------ | ---------------- |
+| 运行时 | Node.js    | 16.x   | [任何约束]       |
+| 框架   | Express    | 4.18.2 | [自定义中间件？] |
+| 数据库 | PostgreSQL | 13     | [连接池设置]     |
+
+等等...
+
+### 仓库结构现实检查
+
+- 类型：[Monorepo/Polyrepo/Hybrid]
+- 包管理器：[npm/yarn/pnpm]
+- 值得注意：[任何不寻常的结构决策]
+
+## 源码树和模块组织
+
+### 项目结构(实际)
+
+```text
+project-root/
+├── src/
+│   ├── controllers/     # HTTP请求处理器
+│   ├── services/        # 业务逻辑(注意：用户和支付服务之间的模式不一致)
+│   ├── models/          # 数据库模型(Sequelize)
+│   ├── utils/           # 混合包 - 需要重构
+│   └── legacy/          # 不要修改 - 旧支付系统仍在使用
+├── tests/               # Jest测试(60%覆盖率)
+├── scripts/             # 构建和部署脚本
+└── config/              # 环境配置
+```
+
+### 关键模块及其用途
+
+- **用户管理**：`src/services/userService.js` - 处理所有用户操作
+- **认证**：`src/middleware/auth.js` - 基于JWT，自定义实现
+- **支付处理**：`src/legacy/payment.js` - 关键：不要重构，紧密耦合
+- **[列出其他关键模块及其实际文件]**
+
+## 数据模型和API
+
+### 数据模型
+
+不要重复，引用实际模型文件：
+
+- **用户模型**：参见`src/models/User.js`
+- **订单模型**：参见`src/models/Order.js`
+- **相关类型**：TypeScript定义在`src/types/`
+
+### API规范
+
+- **OpenAPI规范**：`docs/api/openapi.yaml`(如果存在)
+- **Postman集合**：`docs/api/postman-collection.json`
+- **手动端点**：[列出发现的任何未文档化端点]
+
+## 技术债务和已知问题
+
+### 关键技术债务
+
+1. **支付服务**：`src/legacy/payment.js`中的遗留代码 - 紧密耦合，没有测试
+2. **用户服务**：与其他服务不同的模式，用回调而不是promises
+3. **数据库迁移**：手动跟踪，没有适当的迁移工具
+4. **[其他重大债务]**
+
+### 变通方案和陷阱
+
+- **环境变量**：即使对于staging也必须设置`NODE_ENV=production`(历史原因)
+- **数据库连接**：连接池硬编码为10，改了会破坏支付服务
+- **[开发者需要知道的其他变通方案]**
+
+## 集成点和外部依赖
+
+### 外部服务
+
+| 服务     | 用途 | 集成类型 | 关键文件                       |
+| -------- | ---- | -------- | ------------------------------ |
+| Stripe   | 支付 | REST API | `src/integrations/stripe/`     |
+| SendGrid | 邮件 | SDK      | `src/services/emailService.js` |
+
+等等...
+
+### 内部集成点
+
+- **前端通信**：端口3000上的REST API，期望特定头部
+- **后台作业**：Redis队列，参见`src/workers/`
+- **[其他集成]**
+
+## 开发和部署
+
+### 本地开发设置
+
+1. 实际有效的步骤(不是理想步骤)
+2. 设置的已知问题
+3. 必需的环境变量(参见`.env.example`)
+
+### 构建和部署过程
+
+- **构建命令**：`npm run build`(webpack配置在`webpack.config.js`)
+- **部署**：通过`scripts/deploy.sh`手动部署
+- **环境**：Dev、Staging、Prod(参见`config/environments/`)
+
+## 测试现实
+
+### 当前测试覆盖率
+
+- 单元测试：60%覆盖率(Jest)
+- 集成测试：最少，在`tests/integration/`
+- E2E测试：无
+- 手动测试：主要QA方法
+
+### 运行测试
+
+```bash
+npm test           # 运行单元测试
+npm run test:integration  # 运行集成测试(需要本地DB)
+```
+
+## 如果提供了enhancement PRD - 影响分析
+
+### 需要修改的文件
+
+基于enhancement需求，这些文件会受到影响：
+
+- `src/services/userService.js` - 添加新用户字段
+- `src/models/User.js` - 更新模式
+- `src/routes/userRoutes.js` - 新端点
+- [等等...]
+
+### 需要的新文件/模块
+
+- `src/services/newFeatureService.js` - 新业务逻辑
+- `src/models/NewFeature.js` - 新数据模型
+- [等等...]
+
+### 集成考虑
+
+- 需要与现有认证中间件集成
+- 必须遵循`src/utils/responseFormatter.js`中的现有响应格式
+- [其他集成点]
+
+## 附录 - 有用的命令和脚本
+
+### 常用命令
+
+```bash
+npm run dev         # 启动开发服务器
+npm run build       # 生产构建
+npm run migrate     # 运行数据库迁移
+npm run seed        # 种子测试数据
+```
+
+### 调试和故障排除
+
+- **日志**：检查`logs/app.log`获取应用日志
+- **调试模式**：设置`DEBUG=app:*`进行详细日志记录
+- **常见问题**：参见`docs/troubleshooting.md`]]
+
+### 4. 文档交付
+
+1. **在Web UI中(Gemini、ChatGPT、Claude)**：
+   - 在一个响应中呈现整个文档(如果太长可以分多个)
+   - 告诉用户复制并保存为`docs/brownfield-architecture.md`或`docs/project-architecture.md`
+   - 提到如果需要可以在IDE中稍后分片
+
+2. **在IDE环境中**：
+   - 创建文档为`docs/brownfield-architecture.md`
+   - 告知用户这个单一文档包含所有架构信息
+   - 如果需要可以使用PO代理稍后分片
+
+文档应该足够全面，让未来的代理能够理解：
+
+- 系统的实际状态(不是理想化的)
+- 在哪里找到关键文件和逻辑
+- 存在什么技术债务
+- 必须尊重什么约束
+- 如果提供了PRD：enhancement需要什么改变]]
+
+### 5. 质量保证
+
+关键：在最终确定文档之前：
+
+1. **准确性检查**：验证所有技术细节与实际代码库匹配
+2. **完整性审查**：确保所有主要系统组件都已文档化
+3. **重点验证**：如果用户提供了范围，验证相关领域得到强调
+4. **清晰度评估**：检查解释对AI代理是否清晰
+5. **导航**：确保文档有清晰的部分结构便于参考
+
+在主要部分之后应用高级引导任务，根据用户反馈进行完善。
+
+## 成功标准
+
+- 创建了单一全面的brownfield架构文档
+- 文档反映现实，包括技术债务和变通方案
+- 关键文件和模块引用实际路径
+- 模型/API引用源文件而不是重复内容
+- 如果提供了PRD：清晰的影响分析显示需要什么改变
+- 文档使AI代理能够导航和理解实际代码库
+- 技术约束和"陷阱"得到清晰文档化
+
+## 注意事项
+
+- 这个任务创建一个文档来捕获系统的真实状态
+- 尽可能引用实际文件而不是重复内容
+- 诚实地文档化技术债务、变通方案和约束
+- 对于有PRD的brownfield项目：提供清晰的enhancement影响分析
+- 目标是为做实际工作的AI代理提供实用的文档

package/.knowledge/.ext/.bmad-core/tasks/execute-checklist.md

@@ -0,0 +1,88 @@
+<!-- Powered by BMAD™ Core -->
+
+# Checklist 验证任务
+
+这个任务教你怎么用 checklist 来验证文档。代理必须按这个来，确保文档验证得全面又系统。
+
+## 可用的 Checklist
+
+如果用户问或者没指定具体 checklist，就把代理角色能用的 checklist 列出来。如果任务不是用特定代理跑的，告诉用户去 .bmad-core/checklists 文件夹里挑个合适的来用。
+
+## 操作步骤
+
+1. **先看看情况**
+   - 如果用户或任务给了 checklist 名称：
+     - 试试模糊匹配（比如 "architecture checklist" -> "architect-checklist"）
+     - 找到多个匹配就让用户说清楚
+     - 从 .bmad-core/checklists/ 加载合适的 checklist
+   - 如果没指定 checklist：
+     - 问用户想用哪个 checklist
+     - 把 checklists 文件夹里的文件选项展示出来
+   - 确认他们想怎么搞 checklist：
+     - 一节一节来（交互模式 - 很费时间）
+     - 一次性搞定（YOLO 模式 - 推荐用这个，最后会有各节的总结可以讨论）
+
+2. **收集文档和工件**
+   - 每个 checklist 都会在开头说需要什么文档/工件
+   - 按 checklist 的具体指导来收集，一般文件在 docs 文件夹里能找到，找不到或不确定就停下来问用户。
+
+3. **处理 Checklist**
+
+   如果是交互模式：
+   - 一个一个处理 checklist 的每个部分
+   - 对每个部分：
+     - 按 checklist 里嵌入的该部分指导来审查所有项目
+     - 根据相关文档或工件检查每个项目
+     - 展示该部分的发现总结，标出警告、错误和不适用项目（为什么不适用）
+     - 继续下一部分前要用户确认，或者有重大问题就停下来处理
+
+   如果是 YOLO 模式：
+   - 一次性处理所有部分
+   - 搞个所有发现的综合报告
+   - 给用户看完整分析
+
+4. **验证方法**
+
+   对每个 checklist 项目：
+   - 读一下理解要求
+   - 在文档里找满足要求的证据
+   - 考虑明确说的和隐含覆盖的
+   - 除此之外，按所有 checklist llm 指导来
+   - 标记项目为：
+     - ✅ 通过：要求明确满足了
+     - ❌ 失败：要求没满足或覆盖不够
+     - ⚠️ 部分：有些方面覆盖了但需要改进
+     - N/A：不适用于这个情况
+
+5. **部分分析**
+
+   对每个部分：
+   - 一步步想算通过率
+   - 找出失败项目里的共同问题
+   - 给具体的改进建议
+   - 交互模式下，和用户讨论发现
+   - 记录用户的决策或解释
+
+6. **最终报告**
+
+   准备包含这些内容的总结：
+   - 整体 checklist 完成情况
+   - 各部分的通过率
+   - 失败项目列表和上下文
+   - 具体的改进建议
+   - 任何标记为 N/A 的部分或项目和理由
+
+## Checklist 执行方法
+
+每个 checklist 现在都包含嵌入的 LLM 提示和指导，会：
+
+1. **指导深入思考** - 提示确保对每个部分深度分析
+2. **请求特定工件** - 关于需要什么文档/访问的明确指导
+3. **提供上下文指导** - 针对特定部分的提示，验证效果更好
+4. **生成综合报告** - 带详细发现的最终总结
+
+LLM 会：
+
+- 执行完整的 checklist 验证
+- 展示带通过/失败率和关键发现的最终报告
+- 提供任何部分的详细分析，特别是有警告或失败的部分

package/.knowledge/.ext/.bmad-core/tasks/facilitate-brainstorming-session.md

@@ -0,0 +1,138 @@
+## <!-- Powered by BMAD™ Core -->
+
+docOutputLocation: docs/brainstorming-session-results.md
+template: '.bmad-core/templates/brainstorming-output-tmpl.yaml'
+
+---
+
+# Facilitate Brainstorming Session Task
+
+Facilitate interactive brainstorming sessions with users. Be creative and adaptive in applying techniques.
+
+## Process
+
+### Step 1: Session Setup
+
+Ask 4 context questions (don't preview what happens next):
+
+1. What are we brainstorming about?
+2. Any constraints or parameters?
+3. Goal: broad exploration or focused ideation?
+4. Do you want a structured document output to reference later? (Default Yes)
+
+### Step 2: Present Approach Options
+
+After getting answers to Step 1, present 4 approach options (numbered):
+
+1. User selects specific techniques
+2. Analyst recommends techniques based on context
+3. Random technique selection for creative variety
+4. Progressive technique flow (start broad, narrow down)
+
+### Step 3: Execute Techniques Interactively
+
+**KEY PRINCIPLES:**
+
+- **FACILITATOR ROLE**: Guide user to generate their own ideas through questions, prompts, and examples
+- **CONTINUOUS ENGAGEMENT**: Keep user engaged with chosen technique until they want to switch or are satisfied
+- **CAPTURE OUTPUT**: If (default) document output requested, capture all ideas generated in each technique section to the document from the beginning.
+
+**Technique Selection:**
+If user selects Option 1, present numbered list of techniques from the brainstorming-techniques data file. User can select by number..
+
+**Technique Execution:**
+
+1. Apply selected technique according to data file description
+2. Keep engaging with technique until user indicates they want to:
+   - Choose a different technique
+   - Apply current ideas to a new technique
+   - Move to convergent phase
+   - End session
+
+**Output Capture (if requested):**
+For each technique used, capture:
+
+- Technique name and duration
+- Key ideas generated by user
+- Insights and patterns identified
+- User's reflections on the process
+
+### Step 4: Session Flow
+
+1. **Warm-up** (5-10 min) - Build creative confidence
+2. **Divergent** (20-30 min) - Generate quantity over quality
+3. **Convergent** (15-20 min) - Group and categorize ideas
+4. **Synthesis** (10-15 min) - Refine and develop concepts
+
+### Step 5: Document Output (if requested)
+
+Generate structured document with these sections:
+
+**Executive Summary**
+
+- Session topic and goals
+- Techniques used and duration
+- Total ideas generated
+- Key themes and patterns identified
+
+**Technique Sections** (for each technique used)
+
+- Technique name and description
+- Ideas generated (user's own words)
+- Insights discovered
+- Notable connections or patterns
+
+**Idea Categorization**
+
+- **Immediate Opportunities** - Ready to implement now
+- **Future Innovations** - Requires development/research
+- **Moonshots** - Ambitious, transformative concepts
+- **Insights & Learnings** - Key realizations from session
+
+**Action Planning**
+
+- Top 3 priority ideas with rationale
+- Next steps for each priority
+- Resources/research needed
+- Timeline considerations
+
+**Reflection & Follow-up**
+
+- What worked well in this session
+- Areas for further exploration
+- Recommended follow-up techniques
+- Questions that emerged for future sessions
+
+## Key Principles
+
+- **YOU ARE A FACILITATOR**: Guide the user to brainstorm, don't brainstorm for them (unless they request it persistently)
+- **INTERACTIVE DIALOGUE**: Ask questions, wait for responses, build on their ideas
+- **ONE TECHNIQUE AT A TIME**: Don't mix multiple techniques in one response
+- **CONTINUOUS ENGAGEMENT**: Stay with one technique until user wants to switch
+- **DRAW IDEAS OUT**: Use prompts and examples to help them generate their own ideas
+- **REAL-TIME ADAPTATION**: Monitor engagement and adjust approach as needed
+- Maintain energy and momentum
+- Defer judgment during generation
+- Quantity leads to quality (aim for 100 ideas in 60 minutes)
+- Build on ideas collaboratively
+- Document everything in output document
+
+## Advanced Engagement Strategies
+
+**Energy Management**
+
+- Check engagement levels: "How are you feeling about this direction?"
+- Offer breaks or technique switches if energy flags
+- Use encouraging language and celebrate idea generation
+
+**Depth vs. Breadth**
+
+- Ask follow-up questions to deepen ideas: "Tell me more about that..."
+- Use "Yes, and..." to build on their ideas
+- Help them make connections: "How does this relate to your earlier idea about...?"
+
+**Transition Management**
+
+- Always ask before switching techniques: "Ready to try a different approach?"
+- Offer options: "Should we explore this idea deeper or generate more alternatives?"
+- Respect their process and timing