@zeyue0329/xiaoma-cli 1.0.49 → 6.0.0-alpha.14

package/xiaoma-core/templates/prd-from-rag-tmpl.yaml

@@ -1,410 +0,0 @@
-template:
-  id: prd-from-rag-template-v1
-  name: 基于需求分析的PRD文档
-  version: 1.0
-  description: 基于Analyst智能体的需求分析产出物生成PRD
-  output:
-    format: markdown
-    filename: docs/prd.md
-    title: "{{project_name}} 产品需求文档 (PRD)"
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-  upstream:
-    agent: analyst
-    required_files:
-      - docs/rag/_analysis-report.md
-      - docs/rag/_requirement-parsing.yaml
-    optional_files:
-      - docs/rag/_questions.md
-      - docs/rag/_index.md
-      - docs/rag/business/*
-      - docs/rag/technical/*
-      - docs/rag/constraints/*
-
-sections:
-  - id: input-validation
-    title: 输入验证
-    internal: true
-    instruction: |
-      在开始生成PRD之前，执行以下验证：
-
-      1. **检查必需文件**：
-         - docs/rag/_analysis-report.md 是否存在
-         - docs/rag/_requirement-parsing.yaml 是否存在
-         - req.txt 原始需求文档是否存在
-
-      2. **加载分析报告**：
-         - 读取并解析 _analysis-report.md 的所有章节
-         - 提取关键信息：功能清单、用户角色、数据实体、风险、待澄清事项
-
-      3. **加载知识上下文**：
-         - 扫描 docs/rag/technical/ 获取技术约束
-         - 扫描 docs/rag/business/ 获取业务规则
-         - 扫描 docs/rag/constraints/ 获取约束条件
-
-      如果缺少必需文件，提示：
-      "⚠️ 未找到需求分析报告。请先执行 Analyst 智能体完成需求分析：*analyze-requirement req.txt"
-
-  - id: complexity-assessment
-    title: 复杂度评估
-    instruction: |
-      基于分析报告内容，评估项目复杂度并推荐文档类型。
-
-      **评估维度**：
-      1. 功能复杂度：基于功能清单数量和依赖关系
-      2. 技术复杂度：基于技术可行性评估
-      3. 集成复杂度：基于数据关系和外部依赖
-      4. 风险等级：基于风险清单
-
-      **推荐文档类型**：
-      - 完整PRD：复杂度 >= 中等，或涉及多个Epic
-      - 单Epic：复杂度低，可在1-3个Story内完成
-
-      展示评估结果并请用户确认文档类型。
-    elicit: true
-    sections:
-      - id: assessment-result
-        title: 评估结果
-        type: table
-        columns: [评估维度, 等级, 依据]
-      - id: recommendation
-        title: 推荐方案
-        instruction: 基于评估结果给出文档类型推荐和理由
-
-  - id: goals-context
-    title: 目标与背景
-    instruction: |
-      从分析报告的"需求概述"章节提取内容，映射到PRD结构。
-
-      **映射规则**：
-      - 分析报告.需求背景 → 背景上下文
-      - 分析报告.核心目标 → 目标
-      - 分析报告.范围边界 → 范围定义
-
-      如果分析报告中信息不足，参考 req.txt 原始需求补充。
-    sections:
-      - id: goals
-        title: 目标
-        type: bullet-list
-        instruction: |
-          从分析报告提取核心目标，转换为PRD目标格式。
-          每个目标应该是：
-          - 可衡量的成果
-          - 用户或业务价值
-          - 与原始需求对应
-      - id: background
-        title: 背景上下文
-        type: paragraphs
-        instruction: |
-          综合以下来源生成背景描述：
-          - 分析报告.需求背景
-          - 分析报告.业务分析
-          - 原始需求文档中的背景信息
-      - id: scope
-        title: 范围定义
-        instruction: 从分析报告.范围边界提取，明确包含和不包含的内容
-        sections:
-          - id: in-scope
-            title: 范围内
-            type: bullet-list
-          - id: out-of-scope
-            title: 范围外
-            type: bullet-list
-      - id: changelog
-        title: 变更日志
-        type: table
-        columns: [日期, 版本, 描述, 作者]
-
-  - id: requirements
-    title: 需求
-    instruction: |
-      从分析报告的"功能分析"和"业务规则汇总"章节提取需求。
-
-      **功能性需求来源**：
-      - 分析报告.功能清单 → FR列表
-      - 分析报告.业务规则 → FR补充说明
-      - docs/rag/business/rules-*.md → 详细规则
-
-      **非功能性需求来源**：
-      - 分析报告.技术分析.性能要求
-      - docs/rag/constraints/security.md
-      - docs/rag/constraints/performance.md
-
-      确保每个需求都可追溯到分析报告或知识库文档。
-    elicit: true
-    sections:
-      - id: functional
-        title: 功能性需求
-        type: numbered-list
-        prefix: FR
-        instruction: |
-          按优先级排列功能性需求：
-          - P0功能优先列出
-          - 每个FR包含：需求描述 + 来源标注
-          - 复杂业务规则单独标注参考文档
-
-          格式示例：
-          FR1: [P0] 用户可以创建订单 (来源: 分析报告.功能清单.F001)
-        examples:
-          - "FR1: [P0] 系统支持用户通过手机号注册账户 (来源: _analysis-report.md#功能清单)"
-          - "FR2: [P0] 订单状态流转遵循：待支付→已支付→已发货→已完成 (来源: business/rules-order.md)"
-      - id: non-functional
-        title: 非功能性需求
-        type: numbered-list
-        prefix: NFR
-        instruction: |
-          从约束条件和技术分析中提取非功能性需求。
-          包括：性能、安全、可用性、兼容性等。
-        examples:
-          - "NFR1: 接口响应时间P99 < 500ms (来源: constraints/performance.md)"
-          - "NFR2: 敏感数据传输必须使用HTTPS加密 (来源: constraints/security.md)"
-
-  - id: data-model
-    title: 数据模型
-    instruction: |
-      从分析报告的"数据分析"章节和技术知识中提取数据模型。
-
-      **来源**：
-      - 分析报告.数据实体清单
-      - 分析报告.数据关系图
-      - docs/rag/technical/data-model.md
-    sections:
-      - id: entities
-        title: 数据实体
-        type: table
-        columns: [实体名称, 描述, 核心属性, 来源]
-        instruction: 列出所有数据实体及其核心属性
-      - id: relationships
-        title: 数据关系
-        instruction: |
-          描述实体间的关系，使用Mermaid ER图表示。
-          从分析报告.数据关系图提取，补充详细说明。
-        examples:
-          - |
-            ```mermaid
-            erDiagram
-                User ||--o{ Order : creates
-                Order ||--|{ OrderItem : contains
-            ```
-
-  - id: technical-constraints
-    title: 技术约束
-    instruction: |
-      整合技术知识库中的约束条件，指导后续架构设计。
-
-      **来源**：
-      - docs/rag/technical/architecture.md
-      - docs/rag/technical/tech-stack.md
-      - docs/rag/technical/coding-standards/
-      - docs/rag/technical/middleware/
-      - 分析报告.技术分析.与现有系统兼容性
-    elicit: true
-    sections:
-      - id: tech-stack
-        title: 技术栈约束
-        instruction: |
-          从技术知识库提取技术栈要求：
-          - 后端框架和版本
-          - 数据库类型和版本
-          - 中间件要求
-        template: |
-          **后端**: {{backend_framework}}
-          **数据库**: {{database}}
-          **缓存**: {{cache}}
-          **消息队列**: {{mq}}
-      - id: architecture-constraints
-        title: 架构约束
-        instruction: 从 architecture.md 提取架构模式和约束
-      - id: coding-standards
-        title: 编码规范约束
-        instruction: |
-          从 coding-standards/ 目录提取关键规范：
-          - 命名规范
-          - 分层规范
-          - 异常处理规范
-      - id: integration-constraints
-        title: 集成约束
-        instruction: 从分析报告.技术分析提取集成相关约束
-
-  - id: epic-list
-    title: 模块列表
-    instruction: |
-      基于分析报告的功能分析，规划Epic结构。
-
-      **规划原则**：
-      - 按功能优先级分组：P0功能 → Epic 1
-      - 遵循功能依赖关系
-      - 每个Epic交付独立可测试的功能增量
-
-      **Epic分组策略**：
-      1. 从分析报告.功能清单提取所有功能
-      2. 按优先级排序：P0 > P1 > P2
-      3. 分析依赖关系，确定Epic边界
-      4. 每个Epic包含相关联的功能集
-
-      展示Epic列表，请用户确认分组是否合理。
-    elicit: true
-    sections:
-      - id: epic-overview
-        title: Epic概览
-        type: table
-        columns: [Epic, 标题, 包含功能, 优先级, Story数量(预估)]
-        instruction: 展示所有Epic的概览表格
-
-  - id: epic-details
-    title: "Epic {{epic_number}}: {{epic_title}}"
-    repeatable: true
-    instruction: |
-      为每个Epic生成详细内容，包含所有Story和验收标准。
-
-      **Epic内容来源**：
-      - 分析报告.功能清单 (对应功能)
-      - 分析报告.业务规则 (相关规则)
-      - docs/rag/business/ (详细业务知识)
-      - docs/rag/technical/ (技术实现参考)
-
-      **Story生成规则**：
-      - 每个Story是垂直切片
-      - 单个AI Agent会话可完成（2-4小时）
-      - 验收标准来源于分析报告中的业务规则
-      - 包含技术实现提示（来自技术知识）
-
-      **Story排序**：
-      - 遵循分析报告.功能依赖关系
-      - 基础设施和数据模型优先
-      - 核心流程优先于边缘场景
-    elicit: true
-    template: |
-      **Epic目标**: {{epic_goal}}
-
-      **包含功能**:
-      {{功能列表，来源于分析报告}}
-
-      **技术要点**:
-      {{技术实现要点，来源于技术知识库}}
-    sections:
-      - id: story
-        title: "Story {{epic_number}}.{{story_number}}: {{story_title}}"
-        repeatable: true
-        template: |
-          作为一名 {{user_type}}，
-          我想要 {{action}}，
-          以便 {{benefit}}。
-        sections:
-          - id: acceptance-criteria
-            title: 验收标准
-            type: numbered-list
-            instruction: |
-              从以下来源生成验收标准：
-              - 分析报告.业务规则 (对应规则)
-              - docs/rag/business/rules-*.md (详细规则)
-              - 分析报告.数据分析 (数据约束)
-
-              每个标准必须：
-              - 可测试、可验证
-              - 明确无歧义
-              - 包含边界条件
-            item_template: "AC{{criterion_number}}: {{criteria}} (来源: {{source}})"
-          - id: technical-hints
-            title: 技术实现提示
-            instruction: |
-              从技术知识库提取实现提示：
-              - 相关编码规范
-              - 中间件使用示例
-              - 数据模型参考
-            type: bullet-list
-          - id: knowledge-refs
-            title: 知识引用
-            instruction: 列出Story实现时需要参考的知识文档
-            type: bullet-list
-
-  - id: risks-and-open-items
-    title: 风险与待澄清事项
-    instruction: |
-      从分析报告直接提取风险和待澄清事项。
-
-      **来源**：
-      - 分析报告.风险分析
-      - 分析报告.待澄清事项
-    sections:
-      - id: risks
-        title: 风险清单
-        type: table
-        columns: [风险ID, 风险描述, 等级, 缓解措施]
-        instruction: 从分析报告.风险清单直接映射
-      - id: open-questions
-        title: 待澄清事项
-        type: table
-        columns: [序号, 问题, 上下文, 建议选项, 状态]
-        instruction: |
-          从分析报告.待澄清事项提取。
-          标注状态：待确认/已确认/已关闭
-          在PRD评审时需要逐一确认这些问题。
-
-  - id: knowledge-index
-    title: 知识引用索引
-    instruction: |
-      列出本PRD引用的所有知识文档，便于追溯和维护。
-    sections:
-      - id: analysis-refs
-        title: 分析报告引用
-        type: table
-        columns: [章节, 引用位置, 用途]
-      - id: knowledge-refs
-        title: 知识库引用
-        type: table
-        columns: [文件路径, 引用位置, 用途]
-
-  - id: next-steps
-    title: 后续步骤
-    sections:
-      - id: ux-expert-prompt
-        title: UX专家交接
-        instruction: |
-          生成给UX专家的交接提示，包含：
-          - 需要关注的用户角色
-          - 核心屏幕和交互
-          - 品牌和无障碍要求
-          - 相关知识文档路径
-        template: |
-          **交接给UX专家**
-
-          请基于本PRD的用户分析部分设计UI/UX方案：
-
-          **关键输入**：
-          - PRD文档: docs/prd.md
-          - 用户分析: docs/rag/_analysis-report.md#用户分析
-          - 用户角色: {{user_roles}}
-          - 核心屏幕: {{core_screens}}
-
-          **设计重点**：
-          {{design_focus}}
-
-          **执行命令**: *create-ux-design docs/prd.md
-      - id: architect-prompt
-        title: 架构师交接
-        instruction: |
-          生成给架构师的交接提示，包含：
-          - 技术栈约束
-          - 数据模型要点
-          - 集成需求
-          - 相关知识文档路径
-        template: |
-          **交接给架构师**
-
-          请基于本PRD和技术知识库设计系统架构：
-
-          **关键输入**：
-          - PRD文档: docs/prd.md
-          - 技术分析: docs/rag/_analysis-report.md#技术分析
-          - 技术知识: docs/rag/technical/
-          - 数据模型: docs/rag/technical/data-model.md
-
-          **架构重点**：
-          - 技术栈: {{tech_stack}}
-          - 关键集成点: {{integration_points}}
-          - 性能要求: {{performance_requirements}}
-
-          **执行命令**: *create-architecture docs/prd.md

package/xiaoma-core/templates/prd-tmpl.yaml

@@ -1,202 +0,0 @@
-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. 检查 {root}/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: 此部分将包含给架构师的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。