115 lines
6.7 KiB
Markdown
115 lines
6.7 KiB
Markdown
<!-- 由 BMAD™ Core 驱动 -->
|
||
|
||
# 创建下一个故事任务
|
||
|
||
## 目的
|
||
|
||
根据项目进度和史诗定义，确定下一个合乎逻辑的故事，然后使用 `故事模板` 准备一个全面的、自包含的、可操作的故事文件。此任务确保故事富含所有必要的技术背景、需求和验收标准，使其准备好由开发代理高效实施，而无需额外的研究或寻找自身背景。
|
||
|
||
## 顺序任务执行（在当前任务完成前不要继续）
|
||
|
||
### 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`
|