@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9-alpha.2

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

@@ -0,0 +1,314 @@
+<!-- Powered by BMAD™ Core -->
+
+# Create Brownfield Story Task
+
+## Purpose
+
+Create detailed, implementation-ready stories for brownfield projects where traditional sharded PRD/architecture documents may not exist. This task bridges the gap between various documentation formats (document-project output, brownfield PRDs, epics, or user documentation) and executable stories for the Dev agent.
+
+## When to Use This Task
+
+**Use this task when:**
+
+- Working on brownfield projects with non-standard documentation
+- Stories need to be created from document-project output
+- Working from brownfield epics without full PRD/architecture
+- Existing project documentation doesn't follow BMad v4+ structure
+- Need to gather additional context from user during story creation
+
+**Use create-next-story when:**
+
+- Working with properly sharded PRD and v4 architecture documents
+- Following standard greenfield or well-documented brownfield workflow
+- All technical context is available in structured format
+
+## Task Execution Instructions
+
+### 0. Documentation Context
+
+Check for available documentation in this order:
+
+1. **Sharded PRD/Architecture** (docs/prd/, docs/architecture/)
+   - If found, recommend using create-next-story task instead
+
+2. **Brownfield Architecture Document** (docs/brownfield-architecture.md or similar)
+   - Created by document-project task
+   - Contains actual system state, technical debt, workarounds
+
+3. **Brownfield PRD** (docs/prd.md)
+   - May contain embedded technical details
+
+4. **Epic Files** (docs/epics/ or similar)
+   - Created by brownfield-create-epic task
+
+5. **User-Provided Documentation**
+   - Ask user to specify location and format
+
+### 1. Story Identification and Context Gathering
+
+#### 1.1 Identify Story Source
+
+Based on available documentation:
+
+- **From Brownfield PRD**: Extract stories from epic sections
+- **From Epic Files**: Read epic definition and story list
+- **From User Direction**: Ask user which specific enhancement to implement
+- **No Clear Source**: Work with user to define the story scope
+
+#### 1.2 Gather Essential Context
+
+CRITICAL: For brownfield stories, you MUST gather enough context for safe implementation. Be prepared to ask the user for missing information.
+
+**Required Information Checklist:**
+
+- [ ] What existing functionality might be affected?
+- [ ] What are the integration points with current code?
+- [ ] What patterns should be followed (with examples)?
+- [ ] What technical constraints exist?
+- [ ] Are there any "gotchas" or workarounds to know about?
+
+If any required information is missing, list the missing information and ask the user to provide it.
+
+### 2. Extract Technical Context from Available Sources
+
+#### 2.1 From Document-Project Output
+
+If using brownfield-architecture.md from document-project:
+
+- **Technical Debt Section**: Note any workarounds affecting this story
+- **Key Files Section**: Identify files that will need modification
+- **Integration Points**: Find existing integration patterns
+- **Known Issues**: Check if story touches problematic areas
+- **Actual Tech Stack**: Verify versions and constraints
+
+#### 2.2 From Brownfield PRD
+
+If using brownfield PRD:
+
+- **Technical Constraints Section**: Extract all relevant constraints
+- **Integration Requirements**: Note compatibility requirements
+- **Code Organization**: Follow specified patterns
+- **Risk Assessment**: Understand potential impacts
+
+#### 2.3 From User Documentation
+
+Ask the user to help identify:
+
+- Relevant technical specifications
+- Existing code examples to follow
+- Integration requirements
+- Testing approaches used in the project
+
+### 3. Story Creation with Progressive Detail Gathering
+
+#### 3.1 Create Initial Story Structure
+
+Start with the story template, filling in what's known:
+
+```markdown
+# Story {{Enhancement Title}}
+
+## Status: Draft
+
+## Story
+
+As a {{user_type}},
+I want {{enhancement_capability}},
+so that {{value_delivered}}.
+
+## Context Source
+
+- Source Document: {{document name/type}}
+- Enhancement Type: {{single feature/bug fix/integration/etc}}
+- Existing System Impact: {{brief assessment}}
+```
+
+#### 3.2 Develop Acceptance Criteria
+
+Critical: For brownfield, ALWAYS include criteria about maintaining existing functionality
+
+Standard structure:
+
+1. New functionality works as specified
+2. Existing {{affected feature}} continues to work unchanged
+3. Integration with {{existing system}} maintains current behavior
+4. No regression in {{related area}}
+5. Performance remains within acceptable bounds
+
+#### 3.3 Gather Technical Guidance
+
+Critical: This is where you'll need to be interactive with the user if information is missing
+
+Create Dev Technical Guidance section with available information:
+
+````markdown
+## Dev Technical Guidance
+
+### Existing System Context
+
+[Extract from available documentation]
+
+### Integration Approach
+
+[Based on patterns found or ask user]
+
+### Technical Constraints
+
+[From documentation or user input]
+
+### Missing Information
+
+Critical: List anything you couldn't find that dev will need and ask for the missing information
+
+### 4. Task Generation with Safety Checks
+
+#### 4.1 Generate Implementation Tasks
+
+Based on gathered context, create tasks that:
+
+- Include exploration tasks if system understanding is incomplete
+- Add verification tasks for existing functionality
+- Include rollback considerations
+- Reference specific files/patterns when known
+
+Example task structure for brownfield:
+
+```markdown
+## Tasks / Subtasks
+
+- [ ] Task 1: Analyze existing {{component/feature}} implementation
+  - [ ] Review {{specific files}} for current patterns
+  - [ ] Document integration points
+  - [ ] Identify potential impacts
+
+- [ ] Task 2: Implement {{new functionality}}
+  - [ ] Follow pattern from {{example file}}
+  - [ ] Integrate with {{existing component}}
+  - [ ] Maintain compatibility with {{constraint}}
+
+- [ ] Task 3: Verify existing functionality
+  - [ ] Test {{existing feature 1}} still works
+  - [ ] Verify {{integration point}} behavior unchanged
+  - [ ] Check performance impact
+
+- [ ] Task 4: Add tests
+  - [ ] Unit tests following {{project test pattern}}
+  - [ ] Integration test for {{integration point}}
+  - [ ] Update existing tests if needed
+```
+````
+
+### 5. Risk Assessment and Mitigation
+
+CRITICAL: for brownfield - always include risk assessment
+
+Add section for brownfield-specific risks:
+
+```markdown
+## Risk Assessment
+
+### Implementation Risks
+
+- **Primary Risk**: {{main risk to existing system}}
+- **Mitigation**: {{how to address}}
+- **Verification**: {{how to confirm safety}}
+
+### Rollback Plan
+
+- {{Simple steps to undo changes if needed}}
+
+### Safety Checks
+
+- [ ] Existing {{feature}} tested before changes
+- [ ] Changes can be feature-flagged or isolated
+- [ ] Rollback procedure documented
+```
+
+### 6. Final Story Validation
+
+Before finalizing:
+
+1. **Completeness Check**:
+   - [ ] Story has clear scope and acceptance criteria
+   - [ ] Technical context is sufficient for implementation
+   - [ ] Integration approach is defined
+   - [ ] Risks are identified with mitigation
+
+2. **Safety Check**:
+   - [ ] Existing functionality protection included
+   - [ ] Rollback plan is feasible
+   - [ ] Testing covers both new and existing features
+
+3. **Information Gaps**:
+   - [ ] All critical missing information gathered from user
+   - [ ] Remaining unknowns documented for dev agent
+   - [ ] Exploration tasks added where needed
+
+### 7. Story Output Format
+
+Save the story with appropriate naming:
+
+- If from epic: `docs/stories/epic-{n}-story-{m}.md`
+- If standalone: `docs/stories/brownfield-{feature-name}.md`
+- If sequential: Follow existing story numbering
+
+Include header noting documentation context:
+
+```markdown
+# Story: {{Title}}
+
+<!-- Source: {{documentation type used}} -->
+<!-- Context: Brownfield enhancement to {{existing system}} -->
+
+## Status: Draft
+
+[Rest of story content...]
+```
+
+### 8. Handoff Communication
+
+Provide clear handoff to the user:
+
+```text
+Brownfield story created: {{story title}}
+
+Source Documentation: {{what was used}}
+Story Location: {{file path}}
+
+Key Integration Points Identified:
+- {{integration point 1}}
+- {{integration point 2}}
+
+Risks Noted:
+- {{primary risk}}
+
+{{If missing info}}:
+Note: Some technical details were unclear. The story includes exploration tasks to gather needed information during implementation.
+
+Next Steps:
+1. Review story for accuracy
+2. Verify integration approach aligns with your system
+3. Approve story or request adjustments
+4. Dev agent can then implement with safety checks
+```
+
+## Success Criteria
+
+The brownfield story creation is successful when:
+
+1. Story can be implemented without requiring dev to search multiple documents
+2. Integration approach is clear and safe for existing system
+3. All available technical context has been extracted and organized
+4. Missing information has been identified and addressed
+5. Risks are documented with mitigation strategies
+6. Story includes verification of existing functionality
+7. Rollback approach is defined
+
+## Important Notes
+
+- This task is specifically for brownfield projects with non-standard documentation
+- Always prioritize existing system stability over new features
+- When in doubt, add exploration and verification tasks
+- It's better to ask the user for clarification than make assumptions
+- Each story should be self-contained for the dev agent
+- Include references to existing code patterns when available

package/.knowledge/.ext/.bmad-core/tasks/create-deep-research-prompt.md

@@ -0,0 +1,280 @@
+<!-- Powered by BMAD™ Core -->
+
+# 深度研究提示任务
+
+这个任务帮你创建各种深度分析的研究提示。可以处理头脑风暴、项目brief、市场调研或具体研究问题的输入，生成有针对性的深度调研提示。
+
+## 目标
+
+生成结构清晰的研究提示，能够：
+
+- 明确研究目标和范围
+- 指定合适的研究方法
+- 明确预期交付物和格式
+- 指导复杂问题的系统性调研
+- 确保获得可落地的洞察
+
+## 研究类型选择
+
+关键：先帮用户根据需求和提供的输入文档选择最合适的研究重点。
+
+### 1. 研究重点选项
+
+给用户展示以下选项：
+
+1. **产品验证研究**
+   - 验证产品假设和市场匹配度
+   - 测试用户需求和解决方案的假设
+   - 评估技术和商业可行性
+   - 识别风险和应对策略
+
+2. **市场机会研究**
+   - 分析市场规模和增长潜力
+   - 识别市场细分和动态
+   - 评估市场进入策略
+   - 判断时机和市场准备度
+
+3. **用户和客户研究**
+   - 深入分析用户画像和行为
+   - 理解用户需求和痛点
+   - 绘制用户旅程和触点
+   - 分析付费意愿和价值感知
+
+4. **竞品情报研究**
+   - 详细的竞品分析和定位
+   - 功能和能力对比
+   - 商业模式和策略分析
+   - 识别竞争优势和差距
+
+5. **技术和创新研究**
+   - 评估技术趋势和可能性
+   - 评估技术方案和架构
+   - 识别新兴技术和颠覆性变化
+   - 分析自建vs采购vs合作选项
+
+6. **行业和生态研究**
+   - 梳理行业价值链和动态
+   - 识别关键参与者和关系
+   - 分析监管和合规因素
+   - 挖掘合作机会
+
+7. **战略选项研究**
+   - 评估不同战略方向
+   - 评估商业模式替代方案
+   - 分析市场进入策略
+   - 考虑扩张和规模化路径
+
+8. **风险和可行性研究**
+   - 识别和评估各种风险因素
+   - 评估实施挑战
+   - 分析资源需求
+   - 考虑监管和法律影响
+
+9. **自定义研究重点**
+   - 用户自定义的研究目标
+   - 专业领域调研
+   - 跨职能研究需求
+
+### 2. 输入处理
+
+**如果提供了项目brief：**
+
+- 提取关键产品概念和目标
+- 识别目标用户和使用场景
+- 记录技术约束和偏好
+- 突出不确定性和假设
+
+**如果提供了头脑风暴结果：**
+
+- 梳理主要想法和主题
+- 识别需要验证的领域
+- 提取待测试的假设
+- 记录要探索的创意方向
+
+**如果提供了市场研究：**
+
+- 基于已识别的机会
+- 深化特定市场洞察
+- 验证初步发现
+- 探索相邻可能性
+
+**如果从零开始：**
+
+- 通过问题收集必要背景
+- 定义问题空间
+- 明确研究目标
+- 建立成功标准
+
+## 流程
+
+### 3. 研究提示结构
+
+关键：和用户一起开发包含以下组件的综合研究提示。
+
+#### A. 研究目标
+
+关键：和用户一起明确研究的具体目标。
+
+- 主要研究目标和目的
+- 研究要支持的关键决策
+- 研究的成功标准
+- 约束和边界
+
+#### B. 研究问题
+
+关键：和用户一起开发按主题组织的具体、可执行的研究问题。
+
+**核心问题：**
+
+- 必须回答的核心问题
+- 问题优先级排序
+- 问题间的依赖关系
+
+**支持性问题：**
+
+- 额外的背景构建问题
+- 锦上添花的洞察
+- 面向未来的考虑
+
+#### C. 研究方法
+
+**数据收集方法：**
+
+- 二手研究来源
+- 一手研究方法（如适用）
+- 数据质量要求
+- 来源可信度标准
+
+**分析框架：**
+
+- 要应用的具体框架
+- 对比标准
+- 评估方法
+- 综合方法
+
+#### D. 输出要求
+
+**格式规范：**
+
+- 执行摘要要求
+- 详细发现结构
+- 可视化/表格展示
+- 支持文档
+
+**关键交付物：**
+
+- 必备章节和洞察
+- 决策支持要素
+- 可落地的建议
+- 风险和不确定性文档
+
+### 4. 提示生成
+
+**研究提示模板：**
+
+```markdown
+## 研究目标
+
+[明确说明这项研究旨在实现什么]
+
+## 背景信息
+
+[来自项目brief、头脑风暴或其他输入的相关信息]
+
+## 研究问题
+
+### 主要问题（必须回答）
+
+1. [具体、可执行的问题]
+2. [具体、可执行的问题]
+   ...
+
+### 次要问题（锦上添花）
+
+1. [支持性问题]
+2. [支持性问题]
+   ...
+
+## 研究方法
+
+### 信息来源
+
+- [具体来源类型和优先级]
+
+### 分析框架
+
+- [要应用的具体框架]
+
+### 数据要求
+
+- [质量、时效性、可信度需求]
+
+## 预期交付物
+
+### 执行摘要
+
+- 关键发现和洞察
+- 关键影响
+- 推荐行动
+
+### 详细分析
+
+[基于研究类型需要的具体章节]
+
+### 支持材料
+
+- 数据表格
+- 对比矩阵
+- 来源文档
+
+## 成功标准
+
+[如何评估研究是否实现了目标]
+
+## 时间线和优先级
+
+[如适用，任何时间约束或分阶段安排]
+```
+
+### 5. 审查和优化
+
+1. **展示完整提示**
+   - 显示完整的研究提示
+   - 解释关键要素和理由
+   - 突出任何假设
+
+2. **收集反馈**
+   - 目标是否清晰正确？
+   - 问题是否解决了所有关切？
+   - 范围是否合适？
+   - 输出要求是否充分？
+
+3. **根据需要优化**
+   - 融入用户反馈
+   - 调整范围或重点
+   - 添加缺失要素
+   - 澄清模糊之处
+
+### 6. 下一步指导
+
+**执行选项：**
+
+1. **与AI研究助手配合使用**：把这个提示给有研究能力的AI模型
+2. **指导人工研究**：作为手动研究工作的框架
+3. **混合方法**：用这个结构结合AI和人工研究
+
+**整合要点：**
+
+- 发现如何输入到下一阶段
+- 哪些团队成员应该review结果
+- 如何验证发现
+- 何时重新审视或扩展研究
+
+## 重要说明
+
+- 研究提示的质量直接影响收集洞察的质量
+- 研究问题要具体，别太泛泛而谈
+- 考虑当前状态和未来影响
+- 平衡全面性和重点
+- 清楚记录假设和限制
+- 基于初步发现规划迭代优化

package/.knowledge/.ext/.bmad-core/tasks/create-doc.md

@@ -0,0 +1,103 @@
+<!-- Powered by BMAD™ Core -->
+
+# 用模板创建文档（YAML 驱动）
+
+## ⚠️ 重要提醒 ⚠️
+
+**这是个可执行的工作流程，不是参考文档**
+
+用这个任务时：
+
+1. **别想着偷懒** - 这个流程必须和用户互动
+2. **必须一步步来** - 每个部分都要按顺序处理，需要用户反馈
+3. **需要引导用户** - 当 `elicit: true` 时，必须用 1-9 格式等用户回应
+4. **不能走捷径** - 不按这个流程来就创建不了完整文档
+
+**违规警告：** 如果没和用户互动就创建完整文档，那就是违规了。
+
+## 重要：找模板
+
+如果没给 YAML 模板，就把 `.bmad-core/templates` 里的所有模板列出来，或者让用户再提供一个。
+
+## 重要：必须用引导格式
+
+**当 `elicit: true` 时，必须停下来等用户：**
+
+**你必须这样做：**
+
+1. 把内容展示出来
+2. 说明理由（解释为什么这么选、做了哪些假设、怎么决定的）
+3. **停下来，给出 1-9 选项：**
+   - **选项 1：** 总是"继续下一部分"
+   - **选项 2-9：** 从 data/elicitation-methods 里选 8 种方法
+   - 最后写"选择 1-9 或直接输入你的问题/反馈："
+4. **等用户回应** - 用户没选选项或给反馈就别继续
+
+**违规警告：** 如果 elicit=true 的部分没和用户互动就创建内容，那就是违规。
+
+**千万别问是/否问题，也别用其他格式。**
+
+## 处理步骤
+
+1. **解析 YAML 模板** - 把模板的元数据和各个部分加载进来
+2. **设置偏好** - 显示当前模式（交互式），确认输出文件
+3. **处理每个部分：**
+   - 条件不满足就跳过
+   - 检查代理权限（谁拥有/谁可以编辑）- 注意这个部分是不是只给特定代理用
+   - 按部分指令来写内容
+   - 展示内容 + 详细理由
+   - **如果 elicit: true** → 必须用 1-9 选项格式
+   - 能保存到文件就保存
+4. **一直做到完成为止**
+
+## 理由说明要求
+
+展示部分内容时，一定要说明：
+
+- 为什么这么选（选了哪个，没选哪个，为什么）
+- 写的时候做了哪些假设
+- 有什么需要用户注意的决策
+- 哪些地方可能需要验证
+
+## 引导结果处理
+
+用户选了引导方法（2-9）后：
+
+1. 从 data/elicitation-methods 执行方法
+2. 把结果和洞察展示出来
+3. 给用户选项：
+   - **1. 应用更改并更新部分**
+   - **2. 返回引导菜单**
+   - **3. 提问题或继续参与引导**
+
+## 代理权限
+
+处理有代理权限字段的部分时：
+
+- **owner**：注意哪个代理角色最初创建/填充这个部分
+- **editors**：列出可以修改这个部分的代理角色
+- **readonly**：标记创建后不能修改的部分
+
+**对于有访问限制的部分：**
+
+- 在生成的文档里加上说明负责代理的注释
+- 比如："_（这个部分由 dev-agent 拥有，只能由 dev-agent 修改）_"
+
+## YOLO 模式
+
+用户输入 `#yolo` 就能切换到 YOLO 模式（一次性处理所有部分）。
+
+## 重要提醒
+
+**❌ 千万别：**
+
+- 引导时问是/否问题
+- 用除了 1-9 编号选项之外的任何格式
+- 创建新的引导方法
+
+**✅ 一定要：**
+
+- elicit: true 时用精确的 1-9 格式
+- 只从 data/elicitation-methods 里选选项 2-9
+- 提供解释决策的详细理由
+- 最后写"选择 1-9 或直接输入你的问题/反馈："