6.7 KiB

Raw Blame History

创建下一个故事任务

目的

根据项目进度和史诗定义，确定下一个合乎逻辑的故事，然后使用 故事模板 准备一个全面的、自包含的、可操作的故事文件。此任务确保故事富含所有必要的技术背景、需求和验收标准，使其准备好由开发代理高效实施，而无需额外的研究或寻找自身背景。

顺序任务执行（在当前任务完成前不要继续）

0. 加载核心配置并检查工作流

从项目根目录加载 {root}/core-config.yaml
如果文件不存在，则停止并通知用户：“未找到 core-config.yaml。此文件是创建故事所必需的。您可以：1) 从 GITHUB bmad-core/core-config.yaml 复制并为您的项目配置它或 2) 对您的项目运行 BMad 安装程序以自动升级并添加该文件。请在继续之前添加并配置 core-config.yaml。”
提取关键配置：devStoryLocation、prd.*、architecture.*、workflow.*

1. 确定要准备的下一个故事

1.1 定位史诗文件并审查现有故事

根据配置中的 prdSharded，定位史诗文件（分片位置/模式或单片PRD部分）
如果 devStoryLocation 有故事文件，则加载最高的 {epicNum}.{storyNum}.story.md 文件
如果存在最高的故事：
- 验证状态是否为“完成”。如果不是，则提醒用户：“警报：发现未完成的故事！文件：{lastEpicNum}.{lastStoryNum}.story.md 状态：[当前状态] 您应首先修复此故事，但您想接受风险并覆盖以草稿形式创建下一个故事吗？”
- 如果继续，则选择当前史诗中的下一个顺序故事
- 如果史诗已完成，则提示用户：“史诗 {epicNum} 已完成：史诗 {epicNum} 中的所有故事均已完成。您想：1) 从故事1开始史诗 {epicNum + 1} 2) 选择要处理的特定故事 3) 取消故事创建”
- 关键：切勿自动跳到另一个史诗。用户必须明确指示要创建哪个故事。
如果没有故事文件： 下一个故事始终是 1.1（第一个史诗的第一个故事）
向用户宣布已识别的故事：“已确定要准备的下一个故事：{epicNum}.{storyNum} - {故事标题}”

2. 收集故事需求和上一个故事的背景

从已识别的史诗文件中提取故事需求
如果存在上一个故事，则审查开发代理记录部分以获取：
- 完成说明和调试日志参考
- 实施偏差和技术决策
- 遇到的挑战和经验教训
提取为当前故事准备提供信息的相关见解

3. 收集架构背景

3.1 确定架构阅读策略

如果 architectureVersion: >= v4 且 architectureSharded: true：阅读 {architectureShardedLocation}/index.md，然后按照下面的结构化阅读顺序进行
否则：对类似部分使用单片 architectureFile

3.2 根据故事类型阅读架构文档

对于所有故事： tech-stack.md、unified-project-structure.md、coding-standards.md、testing-strategy.md

对于后端/API故事，另外： data-models.md、database-schema.md、backend-architecture.md、rest-api-spec.md、external-apis.md

对于前端/UI故事，另外： frontend-architecture.md、components.md、core-workflows.md、data-models.md

对于全栈故事： 阅读上面的后端和前端部分

3.3 提取特定于故事的技术细节

仅提取与实施当前故事直接相关的信息。不要发明源文档中没有的新库、模式或标准。

提取：

故事将使用的特定数据模型、模式或结构
故事必须实施或使用的API端点
故事中UI元素的组件规范
新代码的文件路径和命名约定
特定于故事功能的测试要求
影响故事的安全或性能考虑

始终引用源文档：[来源：architecture/{filename}.md#{section}]

4. 验证项目结构对齐

将故事需求与 docs/architecture/unified-project-structure.md 中的项目结构指南进行交叉引用
确保文件路径、组件位置或模块名称与定义的结构保持一致
在故事草稿的“项目结构说明”部分记录任何结构冲突

5. 用完整上下文填充故事模板

创建新故事文件：使用故事模板在 {devStoryLocation}/{epicNum}.{storyNum}.story.md 创建
填写基本故事信息：标题、状态（草稿）、故事陈述、来自史诗的验收标准
开发说明部分（关键）：
- 关键：此部分必须仅包含从架构文档中提取的信息。切勿发明或假设技术细节。
- 包括步骤2-3中的所有相关技术细节，按类别组织：
  - 上一个故事的见解：上一个故事的关键经验教训
  - 数据模型：特定的模式、验证规则、关系[附带来源参考]
  - API规范：端点细节、请求/响应格式、身份验证要求[附带来源参考]
  - 组件规范：UI组件细节、属性、状态管理[附带来源参考]
  - 文件位置：根据项目结构应创建新代码的确切路径
  - 测试要求：来自testing-strategy.md的特定测试用例或策略
  - 技术约束：版本要求、性能考虑、安全规则
- 每个技术细节都必须包含其来源参考：[来源：architecture/{filename}.md#{section}]
- 如果在架构文档中未找到某个类别的信息，则明确说明：“在架构文档中未找到具体指导”
任务/子任务部分：
- 仅根据：史诗需求、故事AC、审查过的架构信息，生成详细的、顺序的技术任务列表
- 每个任务都必须引用相关的架构文档
- 根据测试策略，将单元测试作为明确的子任务包括在内
- 在适用的情况下将任务链接到AC（例如，任务1 (AC: 1, 3)）
在步骤4中添加有关项目结构对齐或发现的差异的说明

6. 故事草稿完成和审查

审查所有部分的完整性和准确性
验证技术细节的所有来源参考都已包括在内
确保任务与史诗需求和架构约束保持一致
将状态更新为“草稿”并保存故事文件
执行 {root}/tasks/execute-checklist {root}/checklists/story-draft-checklist
向用户提供摘要，包括：
- 创建的故事：{devStoryLocation}/{epicNum}.{storyNum}.story.md
- 状态：草稿
- 从架构文档中包含的关键技术组件
- 注意到的史诗和架构之间的任何偏差或冲突
- 清单结果
- 下一步：对于复杂的故事，建议用户仔细审查故事草稿，并可选择让PO运行任务 {root}/tasks/validate-next-story

6.7 KiB Raw Blame History Unescape Escape