@zeyue0329/xiaoma-cli 1.0.43 → 1.0.45

package/dist/teams/team-no-ui.txt

@@ -230,6 +230,10 @@ commands:
   - elicit: 运行任务 advanced-elicitation
   - perform-market-research: 使用任务 create-doc 和 market-research-tmpl.yaml
   - research-prompt {topic}: 执行任务 create-deep-research-prompt.md
+  - analyze-requirement {req_file}: 基于需求文档进行RAG增强的需求分析 (运行任务 requirement-analysis-with-rag.md)
+  - generate-rag-questions {req_file}: 根据需求文档生成知识库查询问题清单 (使用模板 rag-questions-tmpl.yaml)
+  - land-knowledge: 将知识库返回的内容结构化存储到docs/rag目录 (使用模板 rag-knowledge-tmpl.yaml)
+  - create-prd-from-rag: 基于docs/rag知识和需求文档生成PRD (使用任务 create-doc 和 prd-tmpl.yaml)
   - yolo: 切换 Yolo 模式
   - exit: 作为业务分析师道别，然后放弃扮演此角色
 dependencies:
@@ -242,11 +246,15 @@ dependencies:
     - create-doc.md
     - document-project.md
     - facilitate-brainstorming-session.md
+    - requirement-analysis-with-rag.md
   templates:
     - brainstorming-output-tmpl.yaml
     - competitor-analysis-tmpl.yaml
     - market-research-tmpl.yaml
     - project-brief-tmpl.yaml
+    - rag-questions-tmpl.yaml
+    - rag-knowledge-tmpl.yaml
+    - prd-tmpl.yaml
 ```
 ==================== END: .xiaoma-core/agents/analyst.md ====================
 
@@ -2565,6 +2573,361 @@ Generate structured document with these sections:
 - Respect their process and timing
 ==================== END: .xiaoma-core/tasks/facilitate-brainstorming-session.md ====================
 
+==================== START: .xiaoma-core/tasks/requirement-analysis-with-rag.md ====================
+<!-- Powered by XiaoMa™ Core -->
+
+# 基于知识库的需求分析任务
+
+## Purpose
+
+通过结合外部需求文档(req.txt)和知识库(RAG/MCP)进行深度需求分析，生成高质量的PRD文档。
+
+## Workflow Overview
+
+```
+req.txt → 问题生成 → 知识库查询 → 知识落地(docs/rag/) → 需求分析 → PRD生成
+```
+
+## Phase 1: 需求文档解析与问题生成
+
+### 1.1 需求文档初步解析
+
+首先读取并分析 req.txt 文档，识别以下关键信息：
+
+```yaml
+解析维度:
+  业务领域: 识别需求所属的业务领域和子领域
+  核心功能: 提取需求描述的主要功能点
+  用户角色: 识别涉及的用户类型和角色
+  业务流程: 提取隐含或显式的业务流程
+  数据实体: 识别涉及的数据对象和关系
+  集成点: 识别与外部系统的交互需求
+  约束条件: 提取技术、业务、时间等约束
+  模糊点: 标记需要澄清的不明确内容
+```
+
+### 1.2 知识库问题生成框架
+
+基于解析结果，生成以下类别的问题向知识库查询：
+
+---
+
+## Phase 2: 知识库提问清单模板
+
+### 类别 A: 业务知识查询
+
+#### A1. 业务领域背景
+```
+问题模板:
+- "关于[业务领域]，现有系统中有哪些相关的业务规则和约束？"
+- "[业务流程名称]的完整流程是什么？包括哪些步骤和参与者？"
+- "在[业务场景]中，有哪些已知的边界情况和异常处理逻辑？"
+- "[业务概念A]和[业务概念B]之间的关系是什么？"
+```
+
+#### A2. 现有功能调研
+```
+问题模板:
+- "系统中是否已存在类似[功能描述]的功能？如果有，实现方式是什么？"
+- "[模块名称]目前支持哪些操作？有什么限制？"
+- "用户当前如何完成[业务目标]？现有流程有什么痛点？"
+```
+
+#### A3. 业务规则确认
+```
+问题模板:
+- "[数据实体]的业务规则有哪些？例如：必填字段、取值范围、状态流转规则"
+- "[操作A]在什么条件下可以执行？有哪些前置条件？"
+- "不同[用户角色]在[功能]上的权限差异是什么？"
+```
+
+---
+
+### 类别 B: 技术知识查询
+
+#### B1. 系统架构
+```
+问题模板:
+- "现有系统的技术架构是什么？使用了哪些核心框架和技术栈？"
+- "[模块名称]的代码结构和目录组织是怎样的？"
+- "系统的数据库设计采用什么模式？主要的数据表有哪些？"
+- "系统中有哪些公共组件和工具类可以复用？"
+```
+
+#### B2. 接口与集成
+```
+问题模板:
+- "与[外部系统]的集成接口是什么？数据格式和协议是什么？"
+- "系统提供了哪些API接口？[功能相关]的接口规范是什么？"
+- "现有的消息队列/事件机制是如何设计的？"
+```
+
+#### B3. 数据模型
+```
+问题模板:
+- "[数据实体]在数据库中的表结构是什么？包含哪些字段？"
+- "[实体A]和[实体B]之间的数据库关系是怎样的？"
+- "系统中有哪些枚举值或字典表与[业务领域]相关？"
+```
+
+#### B4. 代码实现参考
+```
+问题模板:
+- "类似[功能]的实现在代码中是如何组织的？请提供示例代码位置"
+- "[技术方案]在现有代码中有没有参考实现？"
+- "系统中处理[技术问题]的通用模式是什么？"
+```
+
+---
+
+### 类别 C: 历史需求与变更
+
+#### C1. 相关需求追溯
+```
+问题模板:
+- "之前有没有类似[需求描述]的需求？实现情况如何？"
+- "[功能模块]的历史变更记录有哪些？最近的改动是什么？"
+- "有没有与[需求]相关的已知问题或技术债务？"
+```
+
+#### C2. 决策记录
+```
+问题模板:
+- "[技术方案]为什么选择了当前的实现方式？有什么历史背景？"
+- "[设计决策]有没有相关的ADR(架构决策记录)？"
+```
+
+---
+
+### 类别 D: 上下文与约束
+
+#### D1. 项目约束
+```
+问题模板:
+- "项目的技术栈限制有哪些？必须遵循的技术规范是什么？"
+- "项目的安全合规要求有哪些？"
+- "项目的性能要求和SLA标准是什么？"
+```
+
+#### D2. 团队规范
+```
+问题模板:
+- "团队的代码规范和开发流程是什么？"
+- "团队的测试要求和代码审查标准是什么？"
+- "项目的部署流程和环境配置是怎样的？"
+```
+
+---
+
+## Phase 3: 问题生成执行流程
+
+### 3.1 智能问题生成
+
+```yaml
+执行步骤:
+  步骤1_解析需求:
+    输入: req.txt
+    动作: 提取关键实体、流程、约束
+    输出: 需求要素清单
+
+  步骤2_映射问题类别:
+    输入: 需求要素清单
+    动作: 将每个要素映射到问题类别(A/B/C/D)
+    输出: 问题类别映射表
+
+  步骤3_生成具体问题:
+    输入: 问题类别映射表 + 问题模板
+    动作: 用具体内容填充模板生成问题
+    输出: 知识库查询问题清单
+
+  步骤4_问题优先级排序:
+    优先级规则:
+      P0_阻塞级: 缺失会导致无法理解需求的核心问题
+      P1_重要级: 影响需求完整性的问题
+      P2_补充级: 有助于优化实现的问题
+```
+
+### 3.2 问题清单输出格式
+
+```markdown
+# 知识库查询问题清单
+
+## 基本信息
+- 需求文档: req.txt
+- 生成时间: {{timestamp}}
+- 问题总数: {{total_count}}
+
+## P0 阻塞级问题 (必须回答)
+
+### 业务知识
+1. [A1-001] {{具体问题}}
+   - 关联需求点: {{需求中的相关描述}}
+   - 预期答案类型: {{期望获得的信息类型}}
+
+### 技术知识
+2. [B1-001] {{具体问题}}
+   - 关联需求点: {{需求中的相关描述}}
+   - 预期答案类型: {{期望获得的信息类型}}
+
+## P1 重要级问题 (建议回答)
+...
+
+## P2 补充级问题 (可选回答)
+...
+```
+
+---
+
+## Phase 4: 知识落地与组织
+
+### 4.1 知识存储结构
+
+```
+docs/rag/
+├── _index.md                    # 知识索引文件
+├── business/                    # 业务知识
+│   ├── domain-rules.md         # 业务规则
+│   ├── processes.md            # 业务流程
+│   └── entities.md             # 业务实体
+├── technical/                   # 技术知识
+│   ├── architecture.md         # 系统架构
+│   ├── data-model.md          # 数据模型
+│   ├── apis.md                 # 接口规范
+│   └── code-patterns.md        # 代码模式
+├── history/                     # 历史信息
+│   ├── related-requirements.md # 相关需求
+│   └── decisions.md            # 决策记录
+└── constraints/                 # 约束条件
+    ├── technical.md            # 技术约束
+    └── compliance.md           # 合规要求
+```
+
+### 4.2 知识文档格式
+
+```markdown
+# {{知识标题}}
+
+## 元信息
+- 来源: 知识库MCP查询
+- 查询问题: {{原始问题}}
+- 查询时间: {{timestamp}}
+- 置信度: {{high/medium/low}}
+
+## 内容摘要
+{{一句话总结}}
+
+## 详细内容
+{{知识库返回的完整内容}}
+
+## 与需求的关联
+- 关联需求点: {{req.txt中的相关内容}}
+- 影响分析: {{这个知识如何影响需求实现}}
+
+## 后续问题
+{{基于此知识产生的新问题(如有)}}
+```
+
+---
+
+## Phase 5: 需求分析与PRD生成
+
+### 5.1 分析输入整合
+
+```yaml
+分析输入:
+  主要输入:
+    - req.txt: 原始需求文档
+    - docs/rag/*: 知识库查询结果
+  辅助输入:
+    - 项目简报(如存在): docs/brief.md
+    - 技术偏好(如存在): data/technical-preferences.yaml
+```
+
+### 5.2 需求分析维度
+
+```yaml
+分析维度:
+  功能分析:
+    - 核心功能拆解
+    - 功能优先级排序
+    - 功能依赖关系
+
+  用户分析:
+    - 用户角色定义
+    - 用户旅程映射
+    - 用户价值主张
+
+  技术分析:
+    - 技术可行性评估
+    - 与现有系统的兼容性
+    - 技术风险识别
+
+  业务分析:
+    - 业务规则验证
+    - 业务流程优化机会
+    - 业务价值量化
+
+  差距分析:
+    - 现有能力 vs 需求能力
+    - 需要新增/修改的功能
+    - 需要新增/修改的数据
+```
+
+### 5.3 PRD生成流程
+
+```yaml
+PRD生成:
+  步骤1:
+    动作: 整合所有知识输入
+    输出: 知识上下文汇总
+
+  步骤2:
+    动作: 执行需求分析(5.2维度)
+    输出: 需求分析报告
+
+  步骤3:
+    动作: 套用PRD模板(prd-tmpl.yaml)
+    输出: PRD草稿
+
+  步骤4:
+    动作: 启发式验证(advanced-elicitation)
+    输出: 优化后的PRD
+
+  步骤5:
+    动作: 输出最终PRD到指定位置
+    输出: docs/prd.md
+```
+
+---
+
+## 使用说明
+
+### 智能体激活命令
+
+```
+*analyze-requirement {req_file}
+```
+
+### 执行参数
+
+```yaml
+参数:
+  req_file: 需求文档路径 (默认: req.txt)
+  rag_output: 知识输出路径 (默认: docs/rag/)
+  prd_output: PRD输出路径 (默认: docs/prd.md)
+  skip_rag: 跳过知识库查询 (默认: false)
+  interactive: 交互模式 (默认: true)
+```
+
+### 交互模式流程
+
+1. **解析阶段**: 展示需求解析结果，请用户确认
+2. **提问阶段**: 展示问题清单，请用户确认或调整
+3. **查询阶段**: 依次查询知识库，展示返回结果
+4. **分析阶段**: 展示分析结论，请用户确认
+5. **生成阶段**: 生成PRD草稿，启用启发式优化
+==================== END: .xiaoma-core/tasks/requirement-analysis-with-rag.md ====================
+
 ==================== START: .xiaoma-core/templates/brainstorming-output-tmpl.yaml ====================
 template:
   id: brainstorming-output-template-v2
@@ -3542,158 +3905,1887 @@ sections:
           这份项目简报为 {{project_name}} 提供了完整的背景信息。请启动‘PRD 生成模式’，彻底审阅此简报，并与用户合作，按照模板指示逐节创建 PRD，同时请求任何必要的澄清或提出改进建议。
 ==================== END: .xiaoma-core/templates/project-brief-tmpl.yaml ====================
 
-==================== START: .xiaoma-core/data/brainstorming-techniques.md ====================
-<!-- Powered by XiaoMa™ Core -->
+==================== START: .xiaoma-core/templates/rag-questions-tmpl.yaml ====================
+template:
+  id: rag-questions-template-v2
+  name: 知识库问题生成模板
+  version: 2.0
+  description: 基于需求文档(req.txt)生成知识库MCP查询问题，包含详细的技术架构、编码规范、中间件、业务流程等维度
+  output:
+    format: markdown
+    filename: docs/rag-questions.md
+    title: "知识库查询问题清单"
 
-# Brainstorming Techniques Data
+workflow:
+  mode: interactive
+  phases:
+    - 需求解析
+    - 问题生成
+    - 问题确认
+    - 知识库查询
+    - 知识落地
 
-## Creative Expansion
+sections:
+  - id: requirement-parsing
+    title: 第一阶段：需求文档深度解析
+    instruction: |
+      读取并深度分析 req.txt 文档，提取以下要素：
+
+      1. **业务领域识别**
+         - 这个需求属于什么业务领域？(如：订单管理、用户管理、支付系统等)
+         - 涉及哪些子领域或模块？
+
+      2. **功能点提取**
+         - 需求描述了哪些具体功能？
+         - 每个功能的输入、处理、输出是什么？
+
+      3. **用户角色识别**
+         - 涉及哪些用户角色？(如：管理员、普通用户、访客)
+         - 每个角色在此需求中的操作是什么？
+
+      4. **数据实体识别**
+         - 涉及哪些数据对象？(如：订单、商品、用户)
+         - 数据之间的关系是什么？(一对一、一对多、多对多)
+
+      5. **业务流程识别**
+         - 描述了什么业务流程？
+         - 流程的起点、终点、关键步骤是什么？
+         - 每个步骤之间的触发条件和数据传递是什么？
+
+      6. **技术关键词识别**
+         - 需求中提及了哪些技术组件？(如：消息队列、缓存、定时任务)
+         - 涉及哪些外部系统集成？
+
+      7. **模糊点标记**
+         - 哪些描述不够清晰？
+         - 哪些内容有多种理解方式？
+    output:
+      format: yaml
+      template: |
+        需求解析结果:
+          业务领域: {{domain}}
+          子领域: [{{sub_domains}}]
+
+          功能点:
+            {{#each features}}
+            - 名称: {{name}}
+              描述: {{description}}
+              输入: {{input}}
+              输出: {{output}}
+              涉及实体: [{{entities}}]
+            {{/each}}
+
+          用户角色:
+            {{#each roles}}
+            - 角色: {{name}}
+              操作: [{{actions}}]
+              权限级别: {{permission_level}}
+            {{/each}}
+
+          数据实体:
+            {{#each entities}}
+            - 实体: {{name}}
+              属性: [{{attributes}}]
+              关系:
+                {{#each relationships}}
+                - 目标实体: {{target}}
+                  关系类型: {{type}}  # 一对一/一对多/多对一/多对多
+                  关联字段: {{field}}
+                {{/each}}
+            {{/each}}
+
+          业务流程:
+            {{#each processes}}
+            - 流程名称: {{name}}
+              触发条件: {{trigger}}
+              步骤:
+                {{#each steps}}
+                - 序号: {{index}}
+                  名称: {{name}}
+                  执行者: {{actor}}
+                  前置步骤: {{previous_step}}
+                  触发条件: {{trigger_from_previous}}
+                  输入数据: {{input_data}}
+                  输出数据: {{output_data}}
+                  数据变更: {{data_changes}}
+                {{/each}}
+              异常分支: [{{exception_branches}}]
+            {{/each}}
+
+          技术组件:
+            {{#each tech_components}}
+            - 组件: {{name}}
+              用途: {{purpose}}
+            {{/each}}
+
+          模糊点:
+            {{#each ambiguities}}
+            - 位置: {{location}}
+              内容: {{content}}
+              可能理解: [{{interpretations}}]
+            {{/each}}
+
+  - id: question-generation
+    title: 第二阶段：问题生成
+    instruction: |
+      基于解析结果，为每个要素生成具体的知识库查询问题。
+
+      **问题生成原则**：
+      1. 每个问题必须具体、可回答
+      2. 优先生成阻塞性问题（缺失会导致无法继续）
+      3. 问题应覆盖：业务、技术、历史、约束 四个维度
+      4. 避免开放性过强的问题
+      5. 技术问题需要求提供代码示例
+      6. 业务流程问题需要追问每个节点的详细信息
+    sections:
 
-1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
-2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
-3. **Reversal/Inversion**: Pose the reverse question, let them work through it
-4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
+      # ==================== A. 业务知识问题（增强版）====================
+      - id: business-questions
+        title: A. 业务知识问题
+        instruction: |
+          针对业务领域和流程生成问题，重点关注：
+          - 业务规则和约束的完整定义
+          - 业务流程的每个步骤详情
+          - 步骤间的关联关系和数据流转
+          - 数据实体间的关联关系
+          - 边界情况和异常处理
+          - 用户权限和角色
+        question_templates:
+
+          - category: A1-业务规则详解
+            priority: P0
+            description: 深入了解业务规则的完整定义
+            templates:
+              - question: "[{entity}]实体有哪些业务规则？请详细说明："
+                sub_questions:
+                  - "状态有哪些？状态流转规则是什么？哪些状态可以互相转换？"
+                  - "必填字段有哪些？每个必填字段的校验规则是什么？"
+                  - "字段的取值范围和格式要求是什么？"
+                  - "是否有唯一性约束？唯一性的范围是什么（全局/租户/用户）？"
+                  - "是否有软删除？软删除的业务规则是什么？"
+                  - "创建/修改/删除操作的前置条件是什么？"
+
+              - question: "[{entity}]和[{related_entity}]之间的业务关联规则是什么？"
+                sub_questions:
+                  - "关联关系的业务含义是什么？"
+                  - "关联是否必须存在？可以为空吗？"
+                  - "删除主实体时，关联实体如何处理？（级联删除/置空/禁止删除）"
+                  - "关联实体的生命周期如何与主实体绑定？"
+
+              - question: "[{role}]角色在[{operation}]操作上的权限规则是什么？"
+                sub_questions:
+                  - "该角色可以操作哪些数据范围？（全部/本部门/本人）"
+                  - "操作需要哪些前置审批或确认？"
+                  - "操作是否有时间窗口限制？"
+                  - "操作失败时的提示信息应该是什么？"
+
+          - category: A2-业务流程详解
+            priority: P0
+            description: 深入了解业务流程的每个步骤和节点间关系
+            templates:
+              - question: "[{process}]业务流程的完整定义是什么？"
+                sub_questions:
+                  - "流程的触发条件是什么？由谁/什么事件触发？"
+                  - "流程的正常结束条件是什么？"
+                  - "流程的异常结束条件有哪些？"
+                  - "流程是否支持取消/撤销？取消后如何回滚？"
+                  - "流程的超时处理机制是什么？"
+
+              - question: "[{process}]流程中，步骤[{step_a}]到步骤[{step_b}]的详细信息？"
+                sub_questions:
+                  - "从[{step_a}]到[{step_b}]的触发条件是什么？"
+                  - "[{step_a}]完成后，需要传递哪些数据给[{step_b}]？"
+                  - "数据传递的格式和校验规则是什么？"
+                  - "[{step_a}]失败时，是否阻塞[{step_b}]？还是走其他分支？"
+                  - "这两个步骤之间是否有时间约束？（如必须在N分钟内完成）"
+
+              - question: "[{process}]流程的第[{n}]个步骤[{step_name}]的详细执行逻辑是什么？"
+                sub_questions:
+                  - "该步骤的执行者是谁？（系统自动/人工操作/外部系统）"
+                  - "该步骤的输入数据有哪些？数据来源是什么？"
+                  - "该步骤的处理逻辑是什么？涉及哪些业务规则？"
+                  - "该步骤会产生/修改哪些数据？"
+                  - "该步骤完成的标志是什么？如何判定成功/失败？"
+                  - "该步骤失败后的重试机制是什么？"
+                  - "该步骤是否需要记录日志/审计？记录哪些信息？"
+
+              - question: "[{process}]流程中有哪些并行/分支节点？"
+                sub_questions:
+                  - "哪些步骤可以并行执行？并行执行的条件是什么？"
+                  - "并行步骤的汇合点在哪里？汇合的条件是什么（全部完成/任一完成）？"
+                  - "有哪些条件分支？每个分支的触发条件是什么？"
+                  - "分支是否会重新汇合？汇合点在哪里？"
+
+              - question: "[{process}]流程的异常处理机制是什么？"
+                sub_questions:
+                  - "每个步骤可能出现的异常有哪些？"
+                  - "异常发生后的处理策略是什么？（重试/跳过/终止/人工处理）"
+                  - "异常是否需要通知？通知谁？通知方式是什么？"
+                  - "流程中断后如何恢复？是否支持断点续传？"
+
+          - category: A3-数据关联关系详解
+            priority: P0
+            description: 深入了解数据实体间的关联关系
+            templates:
+              - question: "[{entity_a}]和[{entity_b}]的数据关联关系详情？"
+                sub_questions:
+                  - "关联类型是什么？（一对一/一对多/多对一/多对多）"
+                  - "关联是通过什么字段建立的？外键在哪一方？"
+                  - "关联是否必须？能否存在孤立记录？"
+                  - "关联的建立时机是什么？创建时/后续关联？"
+                  - "关联可以修改吗？修改的业务场景是什么？"
+                  - "解除关联的条件是什么？解除后数据如何处理？"
+
+              - question: "[{entity}]的一对多关联详情？"
+                sub_questions:
+                  - "一个[{entity}]最多可以关联多少个[{related_entity}]？"
+                  - "是否有最小关联数量要求？"
+                  - "关联顺序是否重要？如何维护顺序？"
+                  - "批量添加/删除关联的业务规则是什么？"
+
+              - question: "[{entity}]涉及的多对多关联详情？"
+                sub_questions:
+                  - "多对多关联是否有中间表？中间表存储哪些额外信息？"
+                  - "关联的创建和删除权限由谁控制？"
+                  - "关联是否有时效性？过期如何处理？"
+
+          - category: A4-边界情况与异常处理
+            priority: P1
+            description: 深入了解边界情况的处理逻辑
+            templates:
+              - question: "[{operation}]操作的边界情况有哪些？"
+                sub_questions:
+                  - "并发执行时如何处理？是否需要加锁？锁的粒度是什么？"
+                  - "数据不存在时如何处理？"
+                  - "数据已被其他操作锁定时如何处理？"
+                  - "操作超时时如何处理？"
+                  - "部分成功时如何处理？是否支持事务回滚？"
+
+              - question: "[{entity}]数据量很大时的处理规则？"
+                sub_questions:
+                  - "列表查询的分页规则是什么？默认每页多少条？最大每页多少条？"
+                  - "是否支持批量操作？批量操作的最大数量是多少？"
+                  - "大数据量导出的限制是什么？是否需要异步处理？"
+                  - "历史数据的归档策略是什么？"
+
+      # ==================== B. 技术知识问题（增强版）====================
+      - id: technical-questions
+        title: B. 技术知识问题
+        instruction: |
+          针对技术实现生成问题，重点关注：
+          - 整体项目技术架构
+          - 中间件使用规范和代码示例
+          - Java编码规范
+          - SQL规范
+          - 数据模型设计
+          - 接口规范
+          - 代码实现模式
+        question_templates:
+
+          - category: B1-整体项目技术架构
+            priority: P0
+            description: 了解项目的整体技术架构和技术栈
+            templates:
+              - question: "项目的整体技术架构是什么？"
+                sub_questions:
+                  - "项目采用什么架构模式？（单体/微服务/SOA/DDD）"
+                  - "系统分为哪些层次？每层的职责是什么？"
+                  - "各层之间如何交互？调用方式是什么？"
+                  - "请提供架构图或架构说明文档"
+
+              - question: "项目的技术栈详情是什么？"
+                sub_questions:
+                  - "后端框架：使用什么框架？版本是多少？（如Spring Boot版本）"
+                  - "数据库：使用什么数据库？版本是多少？是否有读写分离？"
+                  - "缓存：使用什么缓存？（Redis/Memcached等）版本是多少？"
+                  - "消息队列：使用什么MQ？（RabbitMQ/Kafka/RocketMQ等）版本是多少？"
+                  - "搜索引擎：是否使用？使用什么？（Elasticsearch等）"
+                  - "文件存储：使用什么存储？（本地/OSS/MinIO等）"
+                  - "日志系统：使用什么日志框架和日志收集系统？"
+                  - "监控系统：使用什么监控？（Prometheus/Grafana等）"
+
+              - question: "项目的模块划分是什么？"
+                sub_questions:
+                  - "项目包含哪些Maven/Gradle模块？各模块的职责是什么？"
+                  - "模块之间的依赖关系是什么？"
+                  - "公共模块有哪些？提供什么能力？"
+                  - "请提供模块结构图或模块说明"
+
+              - question: "项目的包结构规范是什么？"
+                sub_questions:
+                  - "Controller层的包路径和命名规范？"
+                  - "Service层的包路径和命名规范？"
+                  - "DAO/Repository层的包路径和命名规范？"
+                  - "Entity/Model层的包路径和命名规范？"
+                  - "DTO/VO层的包路径和命名规范？"
+                  - "工具类的包路径和命名规范？"
+                  - "配置类的包路径和命名规范？"
+                  - "请提供包结构示例"
+
+          - category: B2-中间件使用规范
+            priority: P0
+            description: 了解各中间件的使用规范和代码示例
+            templates:
+              - question: "项目中Redis的使用规范是什么？"
+                sub_questions:
+                  - "Redis的连接配置在哪里？如何获取RedisTemplate？"
+                  - "Key的命名规范是什么？前缀规则是什么？"
+                  - "不同业务场景使用哪种数据结构？（String/Hash/List/Set/ZSet）"
+                  - "缓存的过期时间策略是什么？"
+                  - "如何处理缓存穿透、缓存击穿、缓存雪崩？"
+                  - "分布式锁如何实现？使用什么工具？（Redisson等）"
+                  - "请提供Redis操作的代码示例，包括："
+                  - "  - 字符串缓存的存取示例"
+                  - "  - Hash结构的存取示例"
+                  - "  - 分布式锁的使用示例"
+                  - "  - 缓存注解(@Cacheable等)的使用示例"
+
+              - question: "项目中消息队列的使用规范是什么？"
+                sub_questions:
+                  - "使用什么消息队列？配置在哪里？"
+                  - "Exchange/Topic的命名规范是什么？"
+                  - "Queue的命名规范是什么？"
+                  - "消息体的格式规范是什么？（JSON结构定义）"
+                  - "消息的可靠性如何保证？（确认机制、持久化、重试）"
+                  - "消费者的幂等性如何保证？"
+                  - "死信队列如何处理？"
+                  - "请提供消息队列的代码示例，包括："
+                  - "  - 生产者发送消息的示例"
+                  - "  - 消费者接收消息的示例"
+                  - "  - 延迟消息的发送示例"
+                  - "  - 消息确认和重试的示例"
+
+              - question: "项目中定时任务的使用规范是什么？"
+                sub_questions:
+                  - "使用什么定时任务框架？（Spring @Scheduled/XXL-Job/Quartz等）"
+                  - "定时任务的配置在哪里？"
+                  - "分布式环境下如何保证任务只执行一次？"
+                  - "任务执行失败如何处理？是否有重试机制？"
+                  - "任务执行日志如何记录？"
+                  - "请提供定时任务的代码示例，包括："
+                  - "  - 简单定时任务的定义示例"
+                  - "  - 带参数定时任务的示例"
+                  - "  - 分布式锁定时任务的示例"
+
+              - question: "项目中Elasticsearch的使用规范是什么？（如果使用）"
+                sub_questions:
+                  - "ES的连接配置在哪里？"
+                  - "索引的命名规范是什么？"
+                  - "Mapping的定义规范是什么？"
+                  - "数据同步策略是什么？（同步/异步/Canal等）"
+                  - "请提供ES操作的代码示例，包括："
+                  - "  - 索引创建的示例"
+                  - "  - 文档的CRUD示例"
+                  - "  - 复杂查询的示例"
+
+              - question: "项目中文件存储的使用规范是什么？"
+                sub_questions:
+                  - "使用什么文件存储？配置在哪里？"
+                  - "文件路径/Key的命名规范是什么？"
+                  - "文件大小限制是什么？"
+                  - "支持哪些文件类型？"
+                  - "文件访问权限如何控制？"
+                  - "请提供文件上传/下载的代码示例"
+
+              - question: "项目中是否使用其他中间件？使用规范是什么？"
+                sub_questions:
+                  - "是否使用分布式配置中心？（Nacos/Apollo等）如何使用？"
+                  - "是否使用服务注册发现？如何使用？"
+                  - "是否使用链路追踪？如何使用？"
+                  - "是否使用限流熔断？（Sentinel等）如何使用？"
+                  - "请提供相关代码示例"
+
+          - category: B3-Java编码规范
+            priority: P0
+            description: 了解项目的Java编码规范和最佳实践
+            templates:
+              - question: "项目的Java编码规范是什么？"
+                sub_questions:
+                  - "遵循什么编码规范？（阿里巴巴规范/Google规范/自定义）"
+                  - "是否有规范文档？请提供链接或内容"
+
+              - question: "类和接口的命名规范是什么？"
+                sub_questions:
+                  - "Controller类的命名规范？后缀是什么？"
+                  - "Service接口和实现类的命名规范？"
+                  - "DAO/Mapper/Repository的命名规范？"
+                  - "Entity/PO的命名规范？"
+                  - "DTO的命名规范？请求和响应如何区分？"
+                  - "VO的命名规范？"
+                  - "枚举类的命名规范？"
+                  - "常量类的命名规范？"
+                  - "工具类的命名规范？"
+                  - "异常类的命名规范？"
+                  - "请提供各类型的命名示例"
+
+              - question: "方法的命名规范是什么？"
+                sub_questions:
+                  - "查询单个对象的方法命名？（get/find/query/select）"
+                  - "查询列表的方法命名？"
+                  - "查询分页的方法命名？"
+                  - "新增的方法命名？（add/insert/create/save）"
+                  - "修改的方法命名？（update/modify/edit）"
+                  - "删除的方法命名？（delete/remove）"
+                  - "批量操作的方法命名？"
+                  - "布尔判断的方法命名？（is/has/can/should）"
+                  - "请提供方法命名示例"
+
+              - question: "注释规范是什么？"
+                sub_questions:
+                  - "类注释的格式要求？必须包含哪些内容？"
+                  - "方法注释的格式要求？参数和返回值如何描述？"
+                  - "字段注释的格式要求？"
+                  - "是否使用Swagger注解？格式要求是什么？"
+                  - "TODO/FIXME注释的格式要求？"
+                  - "请提供注释示例"
+
+              - question: "异常处理规范是什么？"
+                sub_questions:
+                  - "项目有哪些自定义异常类？何时使用？"
+                  - "异常应该在哪一层捕获和处理？"
+                  - "业务异常和系统异常如何区分？"
+                  - "异常信息如何记录日志？"
+                  - "全局异常处理器是如何实现的？"
+                  - "请提供异常处理的代码示例"
+
+              - question: "日志打印规范是什么？"
+                sub_questions:
+                  - "使用什么日志框架？（SLF4J+Logback等）"
+                  - "不同级别日志（DEBUG/INFO/WARN/ERROR）的使用场景？"
+                  - "日志内容应该包含哪些信息？"
+                  - "敏感信息如何脱敏？"
+                  - "请求入参出参如何记录？"
+                  - "请提供日志打印的代码示例"
+
+              - question: "Controller层的编码规范是什么？"
+                sub_questions:
+                  - "URL路径的命名规范？RESTful还是其他风格？"
+                  - "请求方法的使用规范？（GET/POST/PUT/DELETE）"
+                  - "参数接收方式的规范？（@RequestParam/@RequestBody/@PathVariable）"
+                  - "响应格式的统一规范？"
+                  - "参数校验如何实现？使用什么注解？"
+                  - "请提供Controller的代码模板"
+
+              - question: "Service层的编码规范是什么？"
+                sub_questions:
+                  - "是否必须定义接口？接口和实现类的关系？"
+                  - "事务注解如何使用？事务传播行为如何选择？"
+                  - "Service之间如何调用？是否允许循环依赖？"
+                  - "复杂业务逻辑如何拆分？"
+                  - "请提供Service的代码模板"
+
+              - question: "DAO层的编码规范是什么？"
+                sub_questions:
+                  - "使用什么ORM框架？（MyBatis/MyBatis-Plus/JPA等）"
+                  - "Mapper接口的编写规范？"
+                  - "XML文件还是注解方式？"
+                  - "动态SQL的编写规范？"
+                  - "请提供DAO的代码模板"
+
+          - category: B4-SQL规范
+            priority: P0
+            description: 了解项目的SQL编写规范
+            templates:
+              - question: "项目的SQL编写规范是什么？"
+                sub_questions:
+                  - "是否有SQL规范文档？请提供链接或内容"
+
+              - question: "表设计规范是什么？"
+                sub_questions:
+                  - "表名的命名规范？前缀规则？"
+                  - "字段名的命名规范？（驼峰/下划线）"
+                  - "主键的设计规范？（自增/UUID/雪花ID）"
+                  - "是否必须有创建时间/更新时间/创建人/更新人字段？"
+                  - "是否必须有逻辑删除字段？"
+                  - "是否必须有版本号字段（乐观锁）？"
+                  - "字段类型的选择规范？"
+                  - "字段长度的设计规范？"
+                  - "索引的命名和设计规范？"
+                  - "请提供建表语句的模板"
+
+              - question: "SQL查询规范是什么？"
+                sub_questions:
+                  - "SELECT是否禁止使用*？"
+                  - "WHERE条件的编写规范？"
+                  - "JOIN的使用规范？最多允许关联几张表？"
+                  - "子查询的使用规范？"
+                  - "ORDER BY的使用规范？"
+                  - "LIMIT的使用规范？深分页如何处理？"
+                  - "请提供查询SQL的示例"
+
+              - question: "SQL更新规范是什么？"
+                sub_questions:
+                  - "UPDATE是否必须带WHERE条件？"
+                  - "批量更新的写法规范？"
+                  - "是否使用乐观锁？如何使用？"
+                  - "请提供更新SQL的示例"
+
+              - question: "SQL性能规范是什么？"
+                sub_questions:
+                  - "索引的使用规范？如何避免索引失效？"
+                  - "大表查询的规范？"
+                  - "慢SQL的定义标准？如何优化？"
+                  - "EXPLAIN的使用规范？"
+                  - "请提供SQL优化的示例"
+
+          - category: B5-数据模型
+            priority: P0
+            description: 了解数据库表结构和数据模型
+            templates:
+              - question: "[{entity}]对应的数据库表结构是什么？"
+                sub_questions:
+                  - "表名是什么？"
+                  - "包含哪些字段？每个字段的类型、长度、约束？"
+                  - "主键是什么？主键生成策略是什么？"
+                  - "有哪些索引？索引类型是什么？"
+                  - "有哪些外键约束？（如果有）"
+                  - "请提供完整的DDL语句"
+
+              - question: "[{entity_a}]和[{entity_b}]的数据库关联设计是什么？"
+                sub_questions:
+                  - "关联类型是什么？（一对一/一对多/多对多）"
+                  - "外键在哪张表？外键字段名是什么？"
+                  - "是否有中间表？中间表结构是什么？"
+                  - "关联查询的SQL怎么写？"
+                  - "请提供关联查询的示例SQL"
+
+              - question: "[{domain}]领域的ER图是什么？"
+                sub_questions:
+                  - "涉及哪些表？"
+                  - "表之间的关系是什么？"
+                  - "请提供ER图或表关系说明"
+
+          - category: B6-接口规范
+            priority: P1
+            description: 了解API接口设计规范
+            templates:
+              - question: "项目的API接口规范是什么？"
+                sub_questions:
+                  - "API风格是什么？（RESTful/RPC/GraphQL）"
+                  - "URL设计规范是什么？"
+                  - "版本控制如何实现？"
+                  - "认证授权如何实现？"
+                  - "请提供API设计规范文档"
+
+              - question: "接口请求规范是什么？"
+                sub_questions:
+                  - "请求头的规范？必须包含哪些Header？"
+                  - "请求体的格式？（JSON/Form）"
+                  - "分页参数的规范？参数名是什么？"
+                  - "排序参数的规范？"
+                  - "请提供请求示例"
+
+              - question: "接口响应规范是什么？"
+                sub_questions:
+                  - "统一响应格式是什么？包含哪些字段？"
+                  - "成功响应的格式？"
+                  - "错误响应的格式？"
+                  - "分页响应的格式？"
+                  - "错误码的设计规范？"
+                  - "请提供响应示例"
+
+              - question: "现有的[{module}]模块提供了哪些API接口？"
+                sub_questions:
+                  - "接口列表是什么？"
+                  - "每个接口的URL、方法、参数、响应是什么？"
+                  - "请提供Swagger文档或接口文档链接"
+
+          - category: B7-代码实现模式
+            priority: P1
+            description: 了解项目中的通用代码实现模式
+            templates:
+              - question: "项目中通用的CRUD实现模式是什么？"
+                sub_questions:
+                  - "是否有通用的BaseController/BaseService？"
+                  - "是否使用代码生成器？如何使用？"
+                  - "请提供标准CRUD的代码示例"
+
+              - question: "项目中分页查询的实现模式是什么？"
+                sub_questions:
+                  - "使用什么分页插件？（PageHelper/MyBatis-Plus等）"
+                  - "分页参数如何接收？"
+                  - "分页结果如何封装？"
+                  - "请提供分页查询的代码示例"
+
+              - question: "项目中复杂查询的实现模式是什么？"
+                sub_questions:
+                  - "多条件动态查询如何实现？"
+                  - "多表关联查询如何实现？"
+                  - "请提供复杂查询的代码示例"
+
+              - question: "项目中事务处理的实现模式是什么？"
+                sub_questions:
+                  - "本地事务如何使用？"
+                  - "分布式事务如何处理？使用什么方案？"
+                  - "请提供事务处理的代码示例"
+
+              - question: "项目中有哪些通用工具类？"
+                sub_questions:
+                  - "日期时间处理工具类？"
+                  - "字符串处理工具类？"
+                  - "JSON处理工具类？"
+                  - "加密解密工具类？"
+                  - "文件处理工具类？"
+                  - "HTTP请求工具类？"
+                  - "请提供工具类的使用示例"
+
+      # ==================== C. 历史追溯问题 ====================
+      - id: history-questions
+        title: C. 历史追溯问题
+        instruction: |
+          针对历史需求和决策生成问题，重点关注：
+          - 相关历史需求
+          - 技术决策记录
+          - 已知问题和债务
+        question_templates:
+          - category: C1-历史需求
+            priority: P1
+            templates:
+              - question: "之前有没有类似[{feature}]的需求？"
+                sub_questions:
+                  - "实现情况如何？是否上线？"
+                  - "实现过程中遇到了什么问题？"
+                  - "有什么经验教训可以借鉴？"
+                  - "相关代码在哪里？"
+
+              - question: "[{module}]模块最近有什么变更？"
+                sub_questions:
+                  - "变更的内容是什么？"
+                  - "变更的原因是什么？"
+                  - "变更后是否有问题？"
+
+          - category: C2-决策记录
+            priority: P2
+            templates:
+              - question: "[{technical_choice}]为什么选择当前的实现方式？"
+                sub_questions:
+                  - "决策的背景是什么？"
+                  - "考虑过哪些备选方案？"
+                  - "选择当前方案的理由是什么？"
+                  - "这个决策有什么限制或trade-off？"
+
+          - category: C3-已知问题
+            priority: P1
+            templates:
+              - question: "[{module}]模块有哪些已知的问题或技术债务？"
+                sub_questions:
+                  - "问题的具体描述是什么？"
+                  - "问题的影响范围是什么？"
+                  - "是否有计划修复？"
+                  - "新功能开发需要注意什么？"
+
+      # ==================== D. 约束条件问题 ====================
+      - id: constraint-questions
+        title: D. 约束条件问题
+        instruction: |
+          针对项目和技术约束生成问题，重点关注：
+          - 技术栈限制
+          - 安全合规要求
+          - 性能要求
+          - 团队规范
+        question_templates:
+          - category: D1-技术约束
+            priority: P1
+            templates:
+              - question: "项目的技术栈限制有哪些？"
+                sub_questions:
+                  - "必须使用什么框架/库？不能使用什么？"
+                  - "JDK版本要求是什么？"
+                  - "是否有第三方库的版本要求？"
+                  - "是否有禁止使用的技术或方案？"
+
+              - question: "[{technical_approach}]方案在当前技术栈下是否可行？"
+                sub_questions:
+                  - "是否与现有技术兼容？"
+                  - "是否需要引入新的依赖？"
+                  - "团队是否有相关经验？"
+
+          - category: D2-安全合规
+            priority: P0
+            templates:
+              - question: "[{data_type}]数据的安全要求是什么？"
+                sub_questions:
+                  - "数据的敏感级别是什么？"
+                  - "存储时是否需要加密？用什么算法？"
+                  - "传输时是否需要加密？"
+                  - "是否需要脱敏？脱敏规则是什么？"
+                  - "数据的访问权限如何控制？"
+                  - "数据的保留期限是多久？"
+
+              - question: "项目的安全规范是什么？"
+                sub_questions:
+                  - "SQL注入如何防范？"
+                  - "XSS如何防范？"
+                  - "CSRF如何防范？"
+                  - "接口防刷如何实现？"
+                  - "敏感操作是否需要二次确认？"
+
+              - question: "项目需要满足哪些合规要求？"
+                sub_questions:
+                  - "是否需要满足等保要求？什么级别？"
+                  - "是否涉及个人隐私数据？需要满足什么要求？"
+                  - "是否有审计日志要求？记录哪些内容？"
+
+          - category: D3-性能要求
+            priority: P1
+            templates:
+              - question: "项目的性能要求是什么？"
+                sub_questions:
+                  - "接口响应时间要求？P99要求？"
+                  - "并发量要求？峰值并发是多少？"
+                  - "吞吐量要求？"
+                  - "可用性要求？99.9%还是99.99%？"
+
+              - question: "[{interface}]接口的性能要求是什么？"
+                sub_questions:
+                  - "响应时间要求是多少？"
+                  - "预期的调用频率是多少？"
+                  - "是否需要限流？限流规则是什么？"
+
+          - category: D4-团队规范
+            priority: P2
+            templates:
+              - question: "团队的开发流程是什么？"
+                sub_questions:
+                  - "分支管理策略是什么？（GitFlow等）"
+                  - "代码审查流程是什么？"
+                  - "上线流程是什么？"
+                  - "环境有哪些？（dev/test/staging/prod）"
+
+              - question: "团队的测试要求是什么？"
+                sub_questions:
+                  - "单元测试覆盖率要求？"
+                  - "是否需要集成测试？"
+                  - "是否需要性能测试？"
+                  - "测试用例的编写规范？"
+
+  - id: question-prioritization
+    title: 第三阶段：问题优先级排序
+    instruction: |
+      对生成的问题进行优先级排序：
+
+      **P0 - 阻塞级**（必须回答）
+      - 缺失会导致完全无法理解需求
+      - 涉及核心业务规则
+      - 影响架构决策
+      - 涉及安全合规
+
+      **P1 - 重要级**（强烈建议回答）
+      - 影响需求完整性
+      - 涉及边界情况处理
+      - 影响实现方案选择
+      - 涉及性能要求
+
+      **P2 - 补充级**（可选回答）
+      - 有助于优化实现
+      - 提供额外上下文
+      - 历史参考信息
+    output:
+      format: markdown
+      template: |
+        # 知识库查询问题清单
+
+        ## 元信息
+        - 源文档: req.txt
+        - 生成时间: {{timestamp}}
+        - 总问题数: {{total_count}}
+        - P0问题: {{p0_count}} | P1问题: {{p1_count}} | P2问题: {{p2_count}}
+
+        ---
+
+        ## P0 阻塞级问题（必须回答）
+
+        ### A. 业务知识
+        {{#each p0_business}}
+        #### {{index}}. [{{id}}] {{question}}
+        - 关联需求: "{{related_requirement}}"
+        - 预期答案类型: {{expected_answer_type}}
+        - 子问题:
+        {{#each sub_questions}}
+          - {{this}}
+        {{/each}}
+        {{/each}}
+
+        ### B. 技术知识
+        {{#each p0_technical}}
+        #### {{index}}. [{{id}}] {{question}}
+        - 关联需求: "{{related_requirement}}"
+        - 预期答案类型: {{expected_answer_type}}
+        - 子问题:
+        {{#each sub_questions}}
+          - {{this}}
+        {{/each}}
+        - **注意**: 请提供相关代码示例
+        {{/each}}
+
+        ---
+
+        ## P1 重要级问题（强烈建议回答）
+
+        ### A. 业务知识
+        {{#each p1_business}}
+        #### {{index}}. [{{id}}] {{question}}
+        - 关联需求: "{{related_requirement}}"
+        - 子问题:
+        {{#each sub_questions}}
+          - {{this}}
+        {{/each}}
+        {{/each}}
+
+        ### B. 技术知识
+        {{#each p1_technical}}
+        #### {{index}}. [{{id}}] {{question}}
+        - 关联需求: "{{related_requirement}}"
+        - 子问题:
+        {{#each sub_questions}}
+          - {{this}}
+        {{/each}}
+        {{/each}}
+
+        ### C. 历史追溯
+        {{#each p1_history}}
+        #### {{index}}. [{{id}}] {{question}}
+        - 关联需求: "{{related_requirement}}"
+        {{/each}}
+
+        ---
+
+        ## P2 补充级问题（可选回答）
+
+        {{#each p2_questions}}
+        #### {{index}}. [{{id}}] {{question}}
+        {{/each}}
+
+  - id: knowledge-landing
+    title: 第四阶段：知识落地规范
+    instruction: |
+      知识库返回的内容应按以下结构存储到 docs/rag/ 目录：
+    output:
+      structure: |
+        docs/rag/
+        ├── _index.md                    # 知识索引（自动生成）
+        ├── _questions.md                # 问题清单（本模板输出）
+        │
+        ├── business/                    # 业务知识
+        │   ├── domain-{{domain}}.md    # 领域知识
+        │   ├── rules-{{topic}}.md      # 业务规则
+        │   ├── process-{{name}}.md     # 业务流程（含详细步骤和关联关系）
+        │   ├── data-relations.md       # 数据关联关系
+        │   └── roles.md                # 角色权限
+        │
+        ├── technical/                   # 技术知识
+        │   ├── architecture.md         # 整体技术架构
+        │   ├── tech-stack.md           # 技术栈详情
+        │   ├── module-structure.md     # 模块结构
+        │   ├── middleware/             # 中间件规范
+        │   │   ├── redis.md            # Redis使用规范和代码示例
+        │   │   ├── mq.md               # 消息队列规范和代码示例
+        │   │   ├── scheduler.md        # 定时任务规范和代码示例
+        │   │   ├── elasticsearch.md    # ES规范和代码示例
+        │   │   └── file-storage.md     # 文件存储规范
+        │   ├── coding-standards/       # 编码规范
+        │   │   ├── java-naming.md      # Java命名规范
+        │   │   ├── java-coding.md      # Java编码规范
+        │   │   ├── exception.md        # 异常处理规范
+        │   │   ├── logging.md          # 日志规范
+        │   │   └── layer-standards.md  # 分层规范（Controller/Service/DAO）
+        │   ├── sql-standards/          # SQL规范
+        │   │   ├── table-design.md     # 表设计规范
+        │   │   ├── query-standards.md  # 查询规范
+        │   │   └── performance.md      # SQL性能规范
+        │   ├── data-model.md           # 数据模型（表结构）
+        │   ├── api-{{module}}.md       # 接口规范
+        │   └── patterns.md             # 代码模式和示例
+        │
+        ├── history/                     # 历史信息
+        │   ├── related-features.md     # 相关功能
+        │   └── decisions.md            # 决策记录
+        │
+        └── constraints/                 # 约束条件
+            ├── technical.md            # 技术约束
+            ├── security.md             # 安全要求
+            └── performance.md          # 性能要求
+
+      file_template: |
+        # {{title}}
+
+        ## 元信息
+        - 查询问题: {{question}}
+        - 问题ID: {{question_id}}
+        - 查询时间: {{timestamp}}
+        - 数据来源: 知识库MCP
+
+        ## 内容摘要
+        {{summary}}
+
+        ## 详细内容
+        {{content}}
+
+        ## 代码示例（如适用）
+        {{#if code_examples}}
+        {{#each code_examples}}
+        ### {{title}}
+        ```{{language}}
+        {{code}}
+        ```
+        **说明**: {{description}}
+        {{/each}}
+        {{/if}}
+
+        ## 需求关联
+        - 关联需求点: {{related_requirement}}
+        - 影响分析: {{impact_analysis}}
+
+        ## 衍生问题
+        {{#if follow_up_questions}}
+        {{#each follow_up_questions}}
+        - {{this}}
+        {{/each}}
+        {{else}}
+        无
+        {{/if}}
+
+elicitation:
+  after_each_phase: true
+  options:
+    - "调整问题优先级"
+    - "添加更多问题"
+    - "删除不相关问题"
+    - "修改问题措辞"
+    - "添加子问题"
+    - "要求提供代码示例"
+    - "进入下一阶段"
+==================== END: .xiaoma-core/templates/rag-questions-tmpl.yaml ====================
+
+==================== START: .xiaoma-core/templates/rag-knowledge-tmpl.yaml ====================
+template:
+  id: rag-knowledge-template-v1
+  name: RAG知识落地模板
+  version: 1.0
+  description: 将知识库MCP返回的知识内容结构化存储到docs/rag目录
+  output:
+    format: markdown
+    base_path: docs/rag/
 
-## Structured Frameworks
+sections:
+  - id: index-template
+    title: 知识索引模板
+    filename: _index.md
+    template: |
+      # RAG知识库索引
+
+      ## 概览
+      - 需求文档: {{requirement_file}}
+      - 创建时间: {{created_at}}
+      - 最后更新: {{updated_at}}
+      - 知识条目数: {{total_entries}}
+
+      ## 知识分类统计
+
+      | 分类 | 条目数 | 覆盖率 |
+      |------|--------|--------|
+      | 业务知识 | {{business_count}} | {{business_coverage}}% |
+      | 技术知识 | {{technical_count}} | {{technical_coverage}}% |
+      | 历史信息 | {{history_count}} | {{history_coverage}}% |
+      | 约束条件 | {{constraints_count}} | {{constraints_coverage}}% |
+
+      ## 知识目录
+
+      ### 业务知识 (business/)
+      {{#each business_files}}
+      - [{{title}}](business/{{filename}}) - {{summary}}
+      {{/each}}
+
+      ### 技术知识 (technical/)
+      {{#each technical_files}}
+      - [{{title}}](technical/{{filename}}) - {{summary}}
+      {{/each}}
+
+      ### 历史信息 (history/)
+      {{#each history_files}}
+      - [{{title}}](history/{{filename}}) - {{summary}}
+      {{/each}}
+
+      ### 约束条件 (constraints/)
+      {{#each constraints_files}}
+      - [{{title}}](constraints/{{filename}}) - {{summary}}
+      {{/each}}
+
+      ## 未回答问题
+      {{#if unanswered_questions}}
+      以下问题未能从知识库获得答案：
+      {{#each unanswered_questions}}
+      - [{{id}}] {{question}}
+      {{/each}}
+      {{else}}
+      所有问题均已获得回答。
+      {{/if}}
+
+      ## 后续行动
+      {{#each follow_up_actions}}
+      - [ ] {{action}}
+      {{/each}}
+
+  - id: business-knowledge
+    title: 业务知识模板
+    path: business/
+    variants:
+      - id: domain-knowledge
+        filename_pattern: "domain-{{domain_name}}.md"
+        template: |
+          # {{domain_name}} 领域知识
 
-5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
-6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
-7. **Mind Mapping**: Start with central concept, ask them to suggest branches
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
 
-## Collaborative Techniques
+          ## 领域概述
+          {{domain_overview}}
 
-8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
-9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
-10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
+          ## 核心概念
 
-## Deep Exploration
+          {{#each concepts}}
+          ### {{name}}
+          - **定义**: {{definition}}
+          - **业务含义**: {{business_meaning}}
+          - **相关实体**: {{related_entities}}
+          {{/each}}
 
-11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
-12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
-13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
+          ## 业务规则
 
-## Advanced Techniques
+          {{#each rules}}
+          ### 规则{{index}}: {{name}}
+          - **描述**: {{description}}
+          - **触发条件**: {{trigger}}
+          - **执行逻辑**: {{logic}}
+          - **异常处理**: {{exception}}
+          {{/each}}
 
-14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
-15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
-16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
-17. **Time Shifting**: "How would you solve this in 1995? 2030?"
-18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
-19. **Metaphor Mapping**: Use extended metaphors to explore solutions
-20. **Question Storming**: Generate questions instead of answers first
-==================== END: .xiaoma-core/data/brainstorming-techniques.md ====================
+          ## 与需求的关联
+          {{requirement_mapping}}
 
-==================== START: .xiaoma-core/tasks/brownfield-create-epic.md ====================
-<!-- Powered by XiaoMa™ Core -->
+      - id: process-knowledge
+        filename_pattern: "process-{{process_name}}.md"
+        template: |
+          # {{process_name}} 业务流程
 
-# Create Brownfield Epic Task
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
 
-## Purpose
+          ## 流程概述
+          {{process_overview}}
 
-Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
+          ## 流程步骤
 
-## When to Use This Task
+          ```mermaid
+          {{mermaid_diagram}}
+          ```
 
-**Use this task when:**
+          ### 详细步骤
 
-- The enhancement can be completed in 1-3 stories
-- No significant architectural changes are required
-- The enhancement follows existing project patterns
-- Integration complexity is minimal
-- Risk to existing system is low
+          {{#each steps}}
+          #### 步骤{{index}}: {{name}}
+          - **执行者**: {{actor}}
+          - **输入**: {{input}}
+          - **处理**: {{processing}}
+          - **输出**: {{output}}
+          - **后置条件**: {{postcondition}}
+          {{/each}}
 
-**Use the full brownfield PRD/Architecture process when:**
+          ## 异常流程
 
-- The enhancement requires multiple coordinated stories
-- Architectural planning is needed
-- Significant integration work is required
-- Risk assessment and mitigation planning is necessary
+          {{#each exceptions}}
+          ### {{name}}
+          - **触发条件**: {{trigger}}
+          - **处理方式**: {{handling}}
+          - **恢复机制**: {{recovery}}
+          {{/each}}
 
-## Instructions
+          ## 与需求的关联
+          {{requirement_mapping}}
 
-### 1. Project Analysis (Required)
+      - id: roles-knowledge
+        filename_pattern: "roles.md"
+        template: |
+          # 用户角色与权限
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 角色定义
+
+          {{#each roles}}
+          ### {{name}}
+          - **描述**: {{description}}
+          - **职责**: {{responsibilities}}
+          - **权限范围**: {{permissions}}
+
+          #### 可执行操作
+          {{#each operations}}
+          - {{name}}: {{description}} ({{permission_level}})
+          {{/each}}
+          {{/each}}
+
+          ## 权限矩阵
+
+          | 操作 | {{#each roles}}{{name}} | {{/each}}
+          |------|{{#each roles}}--------|{{/each}}
+          {{#each operations}}
+          | {{name}} | {{#each role_permissions}}{{this}} | {{/each}}
+          {{/each}}
+
+          ## 与需求的关联
+          {{requirement_mapping}}
+
+  - id: technical-knowledge
+    title: 技术知识模板
+    path: technical/
+    variants:
+      - id: architecture
+        filename_pattern: "architecture.md"
+        template: |
+          # 系统架构
 
-Before creating the epic, gather essential information about the existing project:
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
 
-**Existing Project Context:**
+          ## 架构概览
+          {{architecture_overview}}
 
-- [ ] Project purpose and current functionality understood
-- [ ] Existing technology stack identified
-- [ ] Current architecture patterns noted
-- [ ] Integration points with existing system identified
+          ## 技术栈
+          | 层级 | 技术 | 版本 | 说明 |
+          |------|------|------|------|
+          {{#each tech_stack}}
+          | {{layer}} | {{technology}} | {{version}} | {{description}} |
+          {{/each}}
 
-**Enhancement Scope:**
+          ## 模块结构
 
-- [ ] Enhancement clearly defined and scoped
-- [ ] Impact on existing functionality assessed
-- [ ] Required integration points identified
-- [ ] Success criteria established
+          ```
+          {{module_structure}}
+          ```
 
-### 2. Epic Creation
+          ## 模块说明
 
-Create a focused epic following this structure:
+          {{#each modules}}
+          ### {{name}}
+          - **职责**: {{responsibility}}
+          - **依赖**: {{dependencies}}
+          - **对外接口**: {{interfaces}}
+          {{/each}}
 
-#### Epic Title
+          ## 与需求的关联
+          - **建议实现位置**: {{suggested_location}}
+          - **需要修改的模块**: {{affected_modules}}
+          - **需要新增的模块**: {{new_modules}}
 
-{{Enhancement Name}} - Brownfield Enhancement
+      - id: data-model
+        filename_pattern: "data-model.md"
+        template: |
+          # 数据模型
 
-#### Epic Goal
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
 
-{{1-2 sentences describing what the epic will accomplish and why it adds value}}
+          ## 数据库概览
+          - **数据库类型**: {{database_type}}
+          - **数据库版本**: {{database_version}}
+          - **ORM框架**: {{orm_framework}}
 
-#### Epic Description
+          ## 相关数据表
 
-**Existing System Context:**
+          {{#each tables}}
+          ### {{table_name}}
 
-- Current relevant functionality: {{brief description}}
-- Technology stack: {{relevant existing technologies}}
-- Integration points: {{where new work connects to existing system}}
+          **说明**: {{description}}
 
-**Enhancement Details:**
+          | 字段名 | 类型 | 约束 | 说明 |
+          |--------|------|------|------|
+          {{#each columns}}
+          | {{name}} | {{type}} | {{constraints}} | {{description}} |
+          {{/each}}
 
-- What's being added/changed: {{clear description}}
-- How it integrates: {{integration approach}}
-- Success criteria: {{measurable outcomes}}
+          **索引**:
+          {{#each indexes}}
+          - {{name}}: {{columns}} ({{type}})
+          {{/each}}
 
-#### Stories
+          {{/each}}
 
-List 1-3 focused stories that complete the epic:
+          ## 表关系
 
-1. **Story 1:** {{Story title and brief description}}
-2. **Story 2:** {{Story title and brief description}}
-3. **Story 3:** {{Story title and brief description}}
+          ```mermaid
+          erDiagram
+          {{er_diagram}}
+          ```
 
-#### Compatibility Requirements
+          ## 与需求的关联
+          - **需要新增的表**: {{new_tables}}
+          - **需要修改的表**: {{modified_tables}}
+          - **数据迁移需求**: {{migration_needs}}
 
-- [ ] Existing APIs remain unchanged
-- [ ] Database schema changes are backward compatible
-- [ ] UI changes follow existing patterns
-- [ ] Performance impact is minimal
+      - id: api-spec
+        filename_pattern: "api-{{module}}.md"
+        template: |
+          # {{module}} 接口规范
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 接口概览
+          - **基础路径**: {{base_path}}
+          - **认证方式**: {{auth_method}}
+          - **响应格式**: {{response_format}}
+
+          ## 接口列表
+
+          {{#each apis}}
+          ### {{method}} {{path}}
+
+          **说明**: {{description}}
+
+          **请求参数**:
+          | 参数名 | 位置 | 类型 | 必填 | 说明 |
+          |--------|------|------|------|------|
+          {{#each parameters}}
+          | {{name}} | {{in}} | {{type}} | {{required}} | {{description}} |
+          {{/each}}
+
+          **请求体**:
+          ```json
+          {{request_body}}
+          ```
+
+          **响应**:
+          ```json
+          {{response_body}}
+          ```
+
+          **错误码**:
+          | 错误码 | 说明 |
+          |--------|------|
+          {{#each error_codes}}
+          | {{code}} | {{message}} |
+          {{/each}}
+
+          ---
+          {{/each}}
+
+          ## 与需求的关联
+          - **可复用的接口**: {{reusable_apis}}
+          - **需要新增的接口**: {{new_apis}}
+          - **需要修改的接口**: {{modified_apis}}
+
+      - id: code-patterns
+        filename_pattern: "patterns.md"
+        template: |
+          # 代码模式与最佳实践
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 项目结构规范
+          ```
+          {{project_structure}}
+          ```
+
+          ## 代码规范
+          {{#each coding_standards}}
+          ### {{category}}
+          {{description}}
+
+          **示例**:
+          ```{{language}}
+          {{example}}
+          ```
+          {{/each}}
+
+          ## 常用模式
+
+          {{#each patterns}}
+          ### {{name}}
+          - **使用场景**: {{use_case}}
+          - **实现示例**: {{example_location}}
+          - **注意事项**: {{notes}}
+          {{/each}}
+
+          ## 可复用组件
+
+          {{#each reusable_components}}
+          ### {{name}}
+          - **位置**: {{location}}
+          - **功能**: {{functionality}}
+          - **使用方法**: {{usage}}
+          {{/each}}
+
+          ## 与需求的关联
+          {{requirement_mapping}}
+
+  - id: history-knowledge
+    title: 历史信息模板
+    path: history/
+    variants:
+      - id: related-features
+        filename_pattern: "related-features.md"
+        template: |
+          # 相关历史功能
 
-#### Risk Mitigation
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
 
-- **Primary Risk:** {{main risk to existing system}}
-- **Mitigation:** {{how risk will be addressed}}
-- **Rollback Plan:** {{how to undo changes if needed}}
+          ## 相关功能列表
 
-#### Definition of Done
+          {{#each features}}
+          ### {{name}}
+          - **实现时间**: {{implemented_at}}
+          - **当前状态**: {{status}}
+          - **功能描述**: {{description}}
+          - **实现位置**: {{location}}
 
-- [ ] All stories completed with acceptance criteria met
-- [ ] Existing functionality verified through testing
-- [ ] Integration points working correctly
-- [ ] Documentation updated appropriately
-- [ ] No regression in existing features
+          **与当前需求的关系**:
+          {{relation_to_current}}
 
-### 3. Validation Checklist
+          **可借鉴点**:
+          {{lessons_learned}}
 
-Before finalizing the epic, ensure:
+          ---
+          {{/each}}
 
-**Scope Validation:**
+          ## 建议
+          {{recommendations}}
 
-- [ ] Epic can be completed in 1-3 stories maximum
-- [ ] No architectural documentation is required
-- [ ] Enhancement follows existing patterns
-- [ ] Integration complexity is manageable
+      - id: decisions
+        filename_pattern: "decisions.md"
+        template: |
+          # 架构决策记录
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 相关决策
+
+          {{#each decisions}}
+          ### ADR-{{id}}: {{title}}
+
+          **状态**: {{status}}
+          **日期**: {{date}}
+
+          **背景**:
+          {{context}}
+
+          **决策**:
+          {{decision}}
+
+          **理由**:
+          {{rationale}}
+
+          **影响**:
+          {{consequences}}
+
+          **与当前需求的关联**:
+          {{relation_to_current}}
+
+          ---
+          {{/each}}
+
+  - id: constraints-knowledge
+    title: 约束条件模板
+    path: constraints/
+    variants:
+      - id: technical-constraints
+        filename_pattern: "technical.md"
+        template: |
+          # 技术约束
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 技术栈约束
+
+          {{#each tech_constraints}}
+          ### {{category}}
+          - **约束**: {{constraint}}
+          - **原因**: {{reason}}
+          - **影响**: {{impact}}
+          {{/each}}
+
+          ## 依赖约束
+
+          {{#each dependency_constraints}}
+          - **{{name}}**: {{constraint}}
+          {{/each}}
+
+          ## 与需求的关联
+          {{requirement_mapping}}
+
+      - id: security-constraints
+        filename_pattern: "security.md"
+        template: |
+          # 安全合规要求
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 安全要求
+
+          {{#each security_requirements}}
+          ### {{name}}
+          - **描述**: {{description}}
+          - **适用范围**: {{scope}}
+          - **实现方式**: {{implementation}}
+          {{/each}}
+
+          ## 合规要求
+
+          {{#each compliance_requirements}}
+          ### {{standard}}
+          - **要求**: {{requirement}}
+          - **检查点**: {{checkpoints}}
+          {{/each}}
+
+          ## 与需求的关联
+          {{requirement_mapping}}
+
+      - id: performance-constraints
+        filename_pattern: "performance.md"
+        template: |
+          # 性能要求
+
+          ## 元信息
+          - 查询问题ID: {{question_ids}}
+          - 来源: 知识库MCP
+          - 更新时间: {{timestamp}}
+
+          ## 性能指标
+
+          | 指标 | 目标值 | 当前值 | 说明 |
+          |------|--------|--------|------|
+          {{#each metrics}}
+          | {{name}} | {{target}} | {{current}} | {{description}} |
+          {{/each}}
+
+          ## SLA要求
+          {{#each sla_requirements}}
+          - **{{name}}**: {{value}}
+          {{/each}}
+
+          ## 与需求的关联
+          {{requirement_mapping}}
+
+workflow:
+  knowledge_landing_process:
+    step1:
+      name: "创建目录结构"
+      action: |
+        确保 docs/rag/ 目录结构存在:
+        - docs/rag/business/
+        - docs/rag/technical/
+        - docs/rag/history/
+        - docs/rag/constraints/
+
+    step2:
+      name: "分类知识内容"
+      action: |
+        根据问题类别(A/B/C/D)将知识库返回内容分类:
+        - A类 → business/
+        - B类 → technical/
+        - C类 → history/
+        - D类 → constraints/
+
+    step3:
+      name: "应用模板生成文件"
+      action: |
+        为每条知识选择合适的模板变体，填充内容并生成markdown文件
+
+    step4:
+      name: "生成索引文件"
+      action: |
+        更新 docs/rag/_index.md 索引文件，统计所有知识条目
+
+    step5:
+      name: "标记未答问题"
+      action: |
+        将无法从知识库获得答案的问题记录到索引文件的"未回答问题"部分
+==================== END: .xiaoma-core/templates/rag-knowledge-tmpl.yaml ====================
+
+==================== START: .xiaoma-core/templates/prd-tmpl.yaml ====================
+template:
+  id: prd-template-v2
+  name: 产品需求文档
+  version: 2.0
+  output:
+    format: markdown
+    filename: docs/prd.md
+    title: "{{project_name}} Product Requirements Document (PRD)"
+
+workflow:
+  mode: interactive
+  elicitation: advanced-elicitation
+
+sections:
+  - id: goals-context
+    title: 目标与背景上下文
+    instruction: |
+      询问“项目简报”文档是否可用。如果不存在“项目简报”，强烈建议首先使用 project-brief-tmpl 创建一个（它提供了必要的基础：问题陈述、目标用户、成功指标、MVP 范围、约束条件）。如果用户坚持在没有简报的情况下编写 PRD，请在“目标”部分收集这些信息。如果“项目简报”存在，请审阅并用它来填充“目标”（期望成果的项目符号列表）和“背景上下文”（1-2 段关于此项目解决什么问题及其原因的说明），以便我们能确定 PRD MVP 的范围内外事项。无论哪种方式，这对于确定需求都至关重要。请包含“变更日志”表格。
+    sections:
+      - id: goals
+        title: 目标
+        type: bullet-list
+        instruction: 以项目符号列表形式，每行一个，列出 PRD 成功后将交付的预期成果——用户和项目的期望。
+      - id: background
+        title: 背景上下文
+        type: paragraphs
+        instruction: 用 1-2 个简短段落总结背景上下文，例如我们在项目简报中学到了什么（避免与目标重复），这个项目解决什么问题以及为什么，当前的行业状况或需求是什么。
+      - id: changelog
+        title: 变更日志
+        type: table
+        columns: [日期, 版本, 描述, 作者]
+        instruction: 跟踪文档版本和变更
+
+  - id: requirements
+    title: 需求
+    instruction: 在两个子部分下起草功能性和非功能性需求列表。
+    elicit: true
+    sections:
+      - id: functional
+        title: 功能性需求
+        type: numbered-list
+        prefix: FR
+        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 FR 开头的标识符序列。
+        examples:
+          - "FR6: 待办事项列表使用 AI 检测并警告措辞不同但可能重复的待办事项。"
+      - id: non-functional
+        title: 非功能性需求
+        type: numbered-list
+        prefix: NFR
+        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 NFR 开头的标识符序列。
+        examples:
+          - "NFR1: 在可行的情况下，AWS 服务的使用必须力求保持在免费套餐限制内。"
+
+  - id: ui-goals
+    title: 用户界面设计目标
+    condition: PRD 包含 UX/UI 需求时
+    instruction: |
+      捕获高层次的 UI/UX 愿景，以指导设计架构师并为创建用户故事提供信息。步骤：
+
+      1. 基于项目上下文，用有根据的猜测预先填充所有子部分。
+      2. 将渲染后的完整部分呈现给用户。
+      3. 清晰地告知用户哪些地方做了假设。
+      4. 针对不清晰/缺失的元素或需要更具体说明的领域提出有针对性的问题。
+      5. 这不是详细的 UI 规范——重点关注产品愿景和用户目标。
+    elicit: true
+    choices:
+      accessibility: [无, WCAG AA, WCAG AAA]
+      platforms: [响应式网页, 仅移动端, 仅桌面端, 跨平台]
+    sections:
+      - id: ux-vision
+        title: 整体 UX 愿景
+      - id: interaction-paradigms
+        title: 关键交互范式
+      - id: core-screens
+        title: 核心屏幕与视图
+        instruction: 从产品角度看，为实现 PRD 的价值和目标，最关键的屏幕或视图是什么？这旨在提供概念性的高层概览，以驱动粗略的模块或用户故事。
+        examples:
+          - "登录屏幕"
+          - "主仪表盘"
+          - "项目详情页"
+          - "设置页面"
+      - id: accessibility
+        title: "无障碍性: {无|WCAG AA|WCAG AAA|自定义要求}"
+      - id: branding
+        title: 品牌
+        instruction: 是否有任何已知的品牌元素或风格指南必须被整合进来？
+        examples:
+          - "复制 20 世纪初黑白电影的观感，包括在页面或状态转换期间模拟胶片损坏或投影仪故障的动画效果。"
+          - "附件是我司品牌的全套调色板和设计元素。"
+      - id: target-platforms
+        title: "目标设备与平台: {响应式网页|仅移动端|仅桌面端|跨平台}"
+        examples:
+          - "响应式网页，以及所有移动平台"
+          - "仅限 iPhone"
+          - "ASCII 码 Windows 桌面"
+
+  - id: technical-assumptions
+    title: 技术假设
+    instruction: |
+      收集将指导架构师的技术决策。步骤：
+
+      1. 检查 .xiaoma-core/data/technical-preferences.yaml 或附加的技术偏好文件是否存在——用它来预填充选项。
+      2. 询问用户关于：语言、框架、启动模板、库、API、部署目标。
+      3. 对于未知项，根据项目目标和 MVP 范围提供指导。
+      4. 记录所有技术选择及其理由（为什么这个选择适合该项目）。
+      5. 这些将成为架构师的约束条件——务必具体和完整。
+    elicit: true
+    choices:
+      repository: [Monorepo, Polyrepo]
+      architecture: [Monolith, Microservices, Serverless]
+      testing: [仅单元测试, 单元+集成测试, 完整测试金字塔]
+    sections:
+      - id: repository-structure
+        title: "代码仓库结构: {Monorepo|Polyrepo|Multi-repo}"
+      - id: service-architecture
+        title: 服务架构
+        instruction: "关键决策 - 记录高层服务架构（例如，Monolith, Microservices, Monorepo 内的 Serverless 函数）。"
+      - id: testing-requirements
+        title: 测试要求
+        instruction: "关键决策 - 记录测试要求（仅单元测试、集成测试、e2e 测试、手动测试，以及是否需要方便手动测试的方法）。"
+      - id: additional-assumptions
+        title: 其他技术假设与请求
+        instruction: 在起草本文档的整个过程中，如果提出或发现任何其他适合架构师的技术假设，请在此处作为额外的项目符号添加。
+
+  - id: epic-list
+    title: 模块列表
+    instruction: |
+      向用户呈现一份高层次的模块列表以供批准。每个模块应有一个标题和一个简短的（1句话）目标陈述。这使用户能在深入细节之前审阅整体结构。
+
+      关键：模块必须遵循敏捷最佳实践，保持逻辑上的顺序：
+
+      - 每个模块都应交付一个重要的、端到端的、完全可部署且可测试的功能增量。
+      - 模块 1 必须建立基础项目设施（应用设置、Git、CI/CD、核心服务），除非我们是向现有应用添加新功能。同时，它还应交付一个初始功能，即使只是一个健康检查路由或一个简单的金丝雀页面显示——在为第一个模块编写用户故事时要记住这一点！
+      - 每个后续的模块都在之前模块功能的基础上构建，交付主要的功能模块，这些模块在部署时能为用户或业务提供切实的价值。
+      - 并非每个项目都需要多个模块，一个模块需要交付价值。例如，一个已完成的 API 即使 UI 尚未完成并计划在另一个模块中实现，也可以交付价值。
+      - 倾向于设置较少的模块，但要告知用户你的理由，并提供拆分选项，如果某些模块看起来太大或关注点分散的话。
+      - 横切关注点应该贯穿于模块和用户故事中，而不是作为最后的用户故事。例如，在一个模块的最后一个故事中添加日志框架，或者在项目结束时作为最后一个模块或故事来做，这将非常糟糕，因为我们从一开始就没有日志记录。
+    elicit: true
+    examples:
+      - "模块 1：基础与核心设施：建立项目设置、认证和基本用户管理"
+      - "模块 2：核心业务实体：创建和管理主要领域对象的 CRUD 操作"
+      - "模块 3：用户工作流与交互：实现关键用户旅程和业务流程"
+      - "模块 4：报告与分析：为用户提供洞察和数据可视化"
+
+  - id: epic-details
+    title: 模块 {{epic_number}} {{epic_title}}
+    repeatable: true
+    instruction: |
+      在模块列表被批准后，将每个模块及其所有的用户故事和验收标准作为一个完整的审查单元呈现。
+
+      为每个模块提供扩展的目标（2-3 句话描述所有故事将实现的目标和价值）。
+
+      关键的用户故事排序要求：
+
+      - 每个模块中的用户故事必须在逻辑上是顺序的。
+      - 每个故事都应该是一个“垂直切片”，交付完整的功能，除了项目基础的早期使能型故事。
+      - 任何故事都不应依赖于后续故事或模块的工作。
+      - 识别并注明任何直接的前置故事。
+      - 关注“做什么”和“为什么”，而不是“怎么做”（将技术实现留给架构师），但要足够精确以支持故事之间逻辑上顺序的操作。
+      - 确保每个故事都交付明确的用户或业务价值，尽量避免使能型故事，而是将它们构建到交付价值的故事中。
+      - 为 AI 代理执行调整故事的大小：每个故事必须能由单个 AI 代理在一次专注的会话中完成，而不会出现上下文溢出。
+      - 想象一个“初级开发人员工作 2-4 小时”的场景——故事必须是小型的、专注的、自包含的。
+      - 如果一个故事看起来很复杂，只要它能交付一个垂直切片，就应进一步拆分。
+    elicit: true
+    template: "{{epic_goal}}"
+    sections:
+      - id: story
+        title: 用户故事 {{epic_number}}.{{story_number}} {{story_title}}
+        repeatable: true
+        template: |
+          作为一名 {{user_type}}，
+          我想要 {{action}}，
+          以便 {{benefit}}。
+        sections:
+          - id: acceptance-criteria
+            title: 验收标准
+            type: numbered-list
+            item_template: "{{criterion_number}}: {{criteria}}"
+            repeatable: true
+            instruction: |
+              定义清晰、全面且可测试的验收标准，这些标准应：
+
+              - 从功能角度精确定义“完成”的含义。
+              - 明确无歧义，并作为验证的基础。
+              - 包括来自 PRD 的任何关键非功能性需求。
+              - 考虑后端/数据组件的本地可测试性。
+              - 在适用时，指定 UI/UX 需求和框架遵循情况。
+              - 避免应放在其他故事或 PRD 部分的横切关注点。
+
+  - id: checklist-results
+    title: 检查清单结果报告
+    instruction: 在运行检查清单和起草提示之前，提议输出更新后的完整 PRD。如果输出，请与用户确认你将继续运行检查清单并生成报告。一旦用户确认，执行 pm-checklist 并在此部分填充结果。
+
+  - id: next-steps
+    title: 后续步骤
+    sections:
+      - id: ux-expert-prompt
+        title: UX 专家提示
+        instruction: 此部分将包含给 UX 专家的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。
+      - id: architect-prompt
+        title: 架构师提示
+        instruction: 此部分将包含给架构师的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。
+==================== END: .xiaoma-core/templates/prd-tmpl.yaml ====================
+
+==================== START: .xiaoma-core/data/brainstorming-techniques.md ====================
+<!-- Powered by XiaoMa™ Core -->
+
+# Brainstorming Techniques Data
+
+## Creative Expansion
+
+1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
+2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
+3. **Reversal/Inversion**: Pose the reverse question, let them work through it
+4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
+
+## Structured Frameworks
+
+5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
+6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
+7. **Mind Mapping**: Start with central concept, ask them to suggest branches
+
+## Collaborative Techniques
+
+8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
+9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
+10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
+
+## Deep Exploration
+
+11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
+12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
+13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
+
+## Advanced Techniques
+
+14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
+15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
+16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
+17. **Time Shifting**: "How would you solve this in 1995? 2030?"
+18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
+19. **Metaphor Mapping**: Use extended metaphors to explore solutions
+20. **Question Storming**: Generate questions instead of answers first
+==================== END: .xiaoma-core/data/brainstorming-techniques.md ====================
+
+==================== START: .xiaoma-core/tasks/brownfield-create-epic.md ====================
+<!-- Powered by XiaoMa™ Core -->
+
+# Create Brownfield Epic Task
+
+## Purpose
+
+Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
+
+## When to Use This Task
+
+**Use this task when:**
+
+- The enhancement can be completed in 1-3 stories
+- No significant architectural changes are required
+- The enhancement follows existing project patterns
+- Integration complexity is minimal
+- Risk to existing system is low
+
+**Use the full brownfield PRD/Architecture process when:**
+
+- The enhancement requires multiple coordinated stories
+- Architectural planning is needed
+- Significant integration work is required
+- Risk assessment and mitigation planning is necessary
+
+## Instructions
+
+### 1. Project Analysis (Required)
+
+Before creating the epic, gather essential information about the existing project:
+
+**Existing Project Context:**
+
+- [ ] Project purpose and current functionality understood
+- [ ] Existing technology stack identified
+- [ ] Current architecture patterns noted
+- [ ] Integration points with existing system identified
+
+**Enhancement Scope:**
+
+- [ ] Enhancement clearly defined and scoped
+- [ ] Impact on existing functionality assessed
+- [ ] Required integration points identified
+- [ ] Success criteria established
+
+### 2. Epic Creation
+
+Create a focused epic following this structure:
+
+#### Epic Title
+
+{{Enhancement Name}} - Brownfield Enhancement
+
+#### Epic Goal
+
+{{1-2 sentences describing what the epic will accomplish and why it adds value}}
+
+#### Epic Description
+
+**Existing System Context:**
+
+- Current relevant functionality: {{brief description}}
+- Technology stack: {{relevant existing technologies}}
+- Integration points: {{where new work connects to existing system}}
+
+**Enhancement Details:**
+
+- What's being added/changed: {{clear description}}
+- How it integrates: {{integration approach}}
+- Success criteria: {{measurable outcomes}}
+
+#### Stories
+
+List 1-3 focused stories that complete the epic:
+
+1. **Story 1:** {{Story title and brief description}}
+2. **Story 2:** {{Story title and brief description}}
+3. **Story 3:** {{Story title and brief description}}
+
+#### Compatibility Requirements
+
+- [ ] Existing APIs remain unchanged
+- [ ] Database schema changes are backward compatible
+- [ ] UI changes follow existing patterns
+- [ ] Performance impact is minimal
+
+#### Risk Mitigation
+
+- **Primary Risk:** {{main risk to existing system}}
+- **Mitigation:** {{how risk will be addressed}}
+- **Rollback Plan:** {{how to undo changes if needed}}
+
+#### Definition of Done
+
+- [ ] All stories completed with acceptance criteria met
+- [ ] Existing functionality verified through testing
+- [ ] Integration points working correctly
+- [ ] Documentation updated appropriately
+- [ ] No regression in existing features
+
+### 3. Validation Checklist
+
+Before finalizing the epic, ensure:
+
+**Scope Validation:**
+
+- [ ] Epic can be completed in 1-3 stories maximum
+- [ ] No architectural documentation is required
+- [ ] Enhancement follows existing patterns
+- [ ] Integration complexity is manageable
 
 **Risk Assessment:**
 
@@ -4539,211 +6631,6 @@ sections:
               - template: "IV3: {{performance_impact_verification}}"
 ==================== END: .xiaoma-core/templates/brownfield-prd-tmpl.yaml ====================
 
-==================== START: .xiaoma-core/templates/prd-tmpl.yaml ====================
-template:
-  id: prd-template-v2
-  name: 产品需求文档
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/prd.md
-    title: "{{project_name}} Product Requirements Document (PRD)"
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-
-sections:
-  - id: goals-context
-    title: 目标与背景上下文
-    instruction: |
-      询问“项目简报”文档是否可用。如果不存在“项目简报”，强烈建议首先使用 project-brief-tmpl 创建一个（它提供了必要的基础：问题陈述、目标用户、成功指标、MVP 范围、约束条件）。如果用户坚持在没有简报的情况下编写 PRD，请在“目标”部分收集这些信息。如果“项目简报”存在，请审阅并用它来填充“目标”（期望成果的项目符号列表）和“背景上下文”（1-2 段关于此项目解决什么问题及其原因的说明），以便我们能确定 PRD MVP 的范围内外事项。无论哪种方式，这对于确定需求都至关重要。请包含“变更日志”表格。
-    sections:
-      - id: goals
-        title: 目标
-        type: bullet-list
-        instruction: 以项目符号列表形式，每行一个，列出 PRD 成功后将交付的预期成果——用户和项目的期望。
-      - id: background
-        title: 背景上下文
-        type: paragraphs
-        instruction: 用 1-2 个简短段落总结背景上下文，例如我们在项目简报中学到了什么（避免与目标重复），这个项目解决什么问题以及为什么，当前的行业状况或需求是什么。
-      - id: changelog
-        title: 变更日志
-        type: table
-        columns: [日期, 版本, 描述, 作者]
-        instruction: 跟踪文档版本和变更
-
-  - id: requirements
-    title: 需求
-    instruction: 在两个子部分下起草功能性和非功能性需求列表。
-    elicit: true
-    sections:
-      - id: functional
-        title: 功能性需求
-        type: numbered-list
-        prefix: FR
-        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 FR 开头的标识符序列。
-        examples:
-          - "FR6: 待办事项列表使用 AI 检测并警告措辞不同但可能重复的待办事项。"
-      - id: non-functional
-        title: 非功能性需求
-        type: numbered-list
-        prefix: NFR
-        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 NFR 开头的标识符序列。
-        examples:
-          - "NFR1: 在可行的情况下，AWS 服务的使用必须力求保持在免费套餐限制内。"
-
-  - id: ui-goals
-    title: 用户界面设计目标
-    condition: PRD 包含 UX/UI 需求时
-    instruction: |
-      捕获高层次的 UI/UX 愿景，以指导设计架构师并为创建用户故事提供信息。步骤：
-
-      1. 基于项目上下文，用有根据的猜测预先填充所有子部分。
-      2. 将渲染后的完整部分呈现给用户。
-      3. 清晰地告知用户哪些地方做了假设。
-      4. 针对不清晰/缺失的元素或需要更具体说明的领域提出有针对性的问题。
-      5. 这不是详细的 UI 规范——重点关注产品愿景和用户目标。
-    elicit: true
-    choices:
-      accessibility: [无, WCAG AA, WCAG AAA]
-      platforms: [响应式网页, 仅移动端, 仅桌面端, 跨平台]
-    sections:
-      - id: ux-vision
-        title: 整体 UX 愿景
-      - id: interaction-paradigms
-        title: 关键交互范式
-      - id: core-screens
-        title: 核心屏幕与视图
-        instruction: 从产品角度看，为实现 PRD 的价值和目标，最关键的屏幕或视图是什么？这旨在提供概念性的高层概览，以驱动粗略的模块或用户故事。
-        examples:
-          - "登录屏幕"
-          - "主仪表盘"
-          - "项目详情页"
-          - "设置页面"
-      - id: accessibility
-        title: "无障碍性: {无|WCAG AA|WCAG AAA|自定义要求}"
-      - id: branding
-        title: 品牌
-        instruction: 是否有任何已知的品牌元素或风格指南必须被整合进来？
-        examples:
-          - "复制 20 世纪初黑白电影的观感，包括在页面或状态转换期间模拟胶片损坏或投影仪故障的动画效果。"
-          - "附件是我司品牌的全套调色板和设计元素。"
-      - id: target-platforms
-        title: "目标设备与平台: {响应式网页|仅移动端|仅桌面端|跨平台}"
-        examples:
-          - "响应式网页，以及所有移动平台"
-          - "仅限 iPhone"
-          - "ASCII 码 Windows 桌面"
-
-  - id: technical-assumptions
-    title: 技术假设
-    instruction: |
-      收集将指导架构师的技术决策。步骤：
-
-      1. 检查 .xiaoma-core/data/technical-preferences.yaml 或附加的技术偏好文件是否存在——用它来预填充选项。
-      2. 询问用户关于：语言、框架、启动模板、库、API、部署目标。
-      3. 对于未知项，根据项目目标和 MVP 范围提供指导。
-      4. 记录所有技术选择及其理由（为什么这个选择适合该项目）。
-      5. 这些将成为架构师的约束条件——务必具体和完整。
-    elicit: true
-    choices:
-      repository: [Monorepo, Polyrepo]
-      architecture: [Monolith, Microservices, Serverless]
-      testing: [仅单元测试, 单元+集成测试, 完整测试金字塔]
-    sections:
-      - id: repository-structure
-        title: "代码仓库结构: {Monorepo|Polyrepo|Multi-repo}"
-      - id: service-architecture
-        title: 服务架构
-        instruction: "关键决策 - 记录高层服务架构（例如，Monolith, Microservices, Monorepo 内的 Serverless 函数）。"
-      - id: testing-requirements
-        title: 测试要求
-        instruction: "关键决策 - 记录测试要求（仅单元测试、集成测试、e2e 测试、手动测试，以及是否需要方便手动测试的方法）。"
-      - id: additional-assumptions
-        title: 其他技术假设与请求
-        instruction: 在起草本文档的整个过程中，如果提出或发现任何其他适合架构师的技术假设，请在此处作为额外的项目符号添加。
-
-  - id: epic-list
-    title: 模块列表
-    instruction: |
-      向用户呈现一份高层次的模块列表以供批准。每个模块应有一个标题和一个简短的（1句话）目标陈述。这使用户能在深入细节之前审阅整体结构。
-
-      关键：模块必须遵循敏捷最佳实践，保持逻辑上的顺序：
-
-      - 每个模块都应交付一个重要的、端到端的、完全可部署且可测试的功能增量。
-      - 模块 1 必须建立基础项目设施（应用设置、Git、CI/CD、核心服务），除非我们是向现有应用添加新功能。同时，它还应交付一个初始功能，即使只是一个健康检查路由或一个简单的金丝雀页面显示——在为第一个模块编写用户故事时要记住这一点！
-      - 每个后续的模块都在之前模块功能的基础上构建，交付主要的功能模块，这些模块在部署时能为用户或业务提供切实的价值。
-      - 并非每个项目都需要多个模块，一个模块需要交付价值。例如，一个已完成的 API 即使 UI 尚未完成并计划在另一个模块中实现，也可以交付价值。
-      - 倾向于设置较少的模块，但要告知用户你的理由，并提供拆分选项，如果某些模块看起来太大或关注点分散的话。
-      - 横切关注点应该贯穿于模块和用户故事中，而不是作为最后的用户故事。例如，在一个模块的最后一个故事中添加日志框架，或者在项目结束时作为最后一个模块或故事来做，这将非常糟糕，因为我们从一开始就没有日志记录。
-    elicit: true
-    examples:
-      - "模块 1：基础与核心设施：建立项目设置、认证和基本用户管理"
-      - "模块 2：核心业务实体：创建和管理主要领域对象的 CRUD 操作"
-      - "模块 3：用户工作流与交互：实现关键用户旅程和业务流程"
-      - "模块 4：报告与分析：为用户提供洞察和数据可视化"
-
-  - id: epic-details
-    title: 模块 {{epic_number}} {{epic_title}}
-    repeatable: true
-    instruction: |
-      在模块列表被批准后，将每个模块及其所有的用户故事和验收标准作为一个完整的审查单元呈现。
-
-      为每个模块提供扩展的目标（2-3 句话描述所有故事将实现的目标和价值）。
-
-      关键的用户故事排序要求：
-
-      - 每个模块中的用户故事必须在逻辑上是顺序的。
-      - 每个故事都应该是一个“垂直切片”，交付完整的功能，除了项目基础的早期使能型故事。
-      - 任何故事都不应依赖于后续故事或模块的工作。
-      - 识别并注明任何直接的前置故事。
-      - 关注“做什么”和“为什么”，而不是“怎么做”（将技术实现留给架构师），但要足够精确以支持故事之间逻辑上顺序的操作。
-      - 确保每个故事都交付明确的用户或业务价值，尽量避免使能型故事，而是将它们构建到交付价值的故事中。
-      - 为 AI 代理执行调整故事的大小：每个故事必须能由单个 AI 代理在一次专注的会话中完成，而不会出现上下文溢出。
-      - 想象一个“初级开发人员工作 2-4 小时”的场景——故事必须是小型的、专注的、自包含的。
-      - 如果一个故事看起来很复杂，只要它能交付一个垂直切片，就应进一步拆分。
-    elicit: true
-    template: "{{epic_goal}}"
-    sections:
-      - id: story
-        title: 用户故事 {{epic_number}}.{{story_number}} {{story_title}}
-        repeatable: true
-        template: |
-          作为一名 {{user_type}}，
-          我想要 {{action}}，
-          以便 {{benefit}}。
-        sections:
-          - id: acceptance-criteria
-            title: 验收标准
-            type: numbered-list
-            item_template: "{{criterion_number}}: {{criteria}}"
-            repeatable: true
-            instruction: |
-              定义清晰、全面且可测试的验收标准，这些标准应：
-
-              - 从功能角度精确定义“完成”的含义。
-              - 明确无歧义，并作为验证的基础。
-              - 包括来自 PRD 的任何关键非功能性需求。
-              - 考虑后端/数据组件的本地可测试性。
-              - 在适用时，指定 UI/UX 需求和框架遵循情况。
-              - 避免应放在其他故事或 PRD 部分的横切关注点。
-
-  - id: checklist-results
-    title: 检查清单结果报告
-    instruction: 在运行检查清单和起草提示之前，提议输出更新后的完整 PRD。如果输出，请与用户确认你将继续运行检查清单并生成报告。一旦用户确认，执行 pm-checklist 并在此部分填充结果。
-
-  - id: next-steps
-    title: 后续步骤
-    sections:
-      - id: ux-expert-prompt
-        title: UX 专家提示
-        instruction: 此部分将包含给 UX 专家的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。
-      - id: architect-prompt
-        title: 架构师提示
-        instruction: 此部分将包含给架构师的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。
-==================== END: .xiaoma-core/templates/prd-tmpl.yaml ====================
-
 ==================== START: .xiaoma-core/checklists/change-checklist.md ====================
 <!-- Powered by XiaoMa™ Core -->