8.4 KiB

Raw Blame History

创建棕地项目故事任务

目的

为棕地项目创建详细的、可随时实施的故事，因为这些项目可能没有传统的、分片的 PRD/架构文档。此任务弥合了各种文档格式（项目文档输出、棕地 PRD、史诗或用户文档）与可供开发代理执行的故事之间的差距。

何时使用此任务

在以下情况下使用此任务：

处理具有非标准文档的棕地项目
需要从项目文档输出创建故事
根据棕地史诗工作，但没有完整的 PRD/架构
现有项目文档不遵循 BMad v4+ 结构
需要在故事创建期间从用户那里收集更多上下文

在以下情况下使用 create-next-story：

使用正确分片的 PRD 和 v4 架构文档
遵循标准的绿地或文档齐全的棕地工作流程
所有技术上下文都以结构化格式提供

任务执行说明

0. 文档上下文

按以下顺序检查可用文档：

分片的 PRD/架构 (docs/prd/, docs/architecture/)
- 如果找到，建议改用 create-next-story 任务
棕地架构文档 (docs/brownfield-architecture.md 或类似文件)
- 由 document-project 任务创建
- 包含实际系统状态、技术债务、变通方法
棕地 PRD (docs/prd.md)
- 可能包含嵌入的技术细节
史诗文件 (docs/epics/ 或类似文件)
- 由 brownfield-create-epic 任务创建
用户提供的文档
- 要求用户指定位置和格式

1. 故事识别和上下文收集

1.1 识别故事来源

根据可用文档：

从棕地 PRD：从史诗部分提取故事
从史诗文件：阅读史诗定义和故事列表
根据用户指示：询问用户要实施哪个具体的增强功能
没有明确来源：与用户合作定义故事范围

1.2 收集基本上下文

关键：对于棕地故事，您必须收集足够的上下文以确保安全实施。准备好向用户询问缺失的信息。

所需信息清单：

哪些现有功能可能会受到影响？
与当前代码的集成点是什么？
应遵循哪些模式（附带示例）？
存在哪些技术限制？
是否有任何需要注意的“陷阱”或变通方法？

如果缺少任何所需信息，请列出缺失的信息并要求用户提供。

2. 从可用来源中提取技术上下文

2.1 从项目文档输出

如果使用来自 document-project 的 brownfield-architecture.md：

技术债务部分：注意影响此故事的任何变通方法
关键文件部分：识别需要修改的文件
集成点：查找现有的集成模式
已知问题：检查故事是否涉及有问题的地方
实际技术栈：验证版本和限制

2.2 从棕地 PRD

如果使用棕地 PRD：

技术限制部分：提取所有相关的限制
集成要求：注意兼容性要求
代码组织：遵循指定的模式
风险评估：了解潜在影响

2.3 从用户文档

要求用户帮助识别：

相关的技术规范
可供遵循的现有代码示例
集成要求
项目中使用的测试方法

3. 通过逐步收集细节来创建故事

3.1 创建初始故事结构

从故事模板开始，填写已知信息：

# 故事 {{增强功能标题}}

## 状态：草稿

## 故事

作为一名 {{user_type}}，
我想要 {{enhancement_capability}}，
以便 {{value_delivered}}。

## 上下文来源

-   源文档：{{文档名称/类型}}
-   增强类型：{{单个功能/错误修复/集成/等}}
-   对现有系统的影响：{{简要评估}}

3.2 制定验收标准

关键：对于棕地项目，始终包括关于维护现有功能的标准

标准结构：

新功能按规定工作
现有的 {{受影响的功能}} 继续正常工作
与 {{现有系统}} 的集成保持当前行为
{{相关领域}} 没有回归
性能保持在可接受的范围内

3.3 收集技术指导

关键：如果信息缺失，这是您需要与用户互动的地方

使用可用信息创建开发技术指导部分：

## 开发技术指导

### 现有系统上下文

[从可用文档中提取]

### 集成方法

[根据找到的模式或询问用户]

### 技术限制

[来自文档或用户输入]

### 缺失信息

关键：列出您找不到的、开发人员需要的任何信息，并要求提供缺失的信息

### 4. 带安全检查的任务生成

#### 4.1 生成实施任务

根据收集的上下文，创建以下任务：

-   如果对系统的理解不完整，则包括探索任务
-   为现有功能添加验证任务
-   包括回滚考虑
-   在已知时引用特定的文件/模式

棕地项目的示例任务结构：

```markdown
## 任务 / 子任务

- [ ] 任务 1：分析现有的 {{组件/功能}} 实现
  - [ ] 查看 {{特定文件}} 以了解当前模式
  - [ ] 记录集成点
  - [ ] 识别潜在影响

- [ ] 任务 2：实施 {{新功能}}
  - [ ] 遵循 {{示例文件}} 中的模式
  - [ ] 与 {{现有组件}} 集成
  - [ ] 保持与 {{约束}} 的兼容性

- [ ] 任务 3：验证现有功能
  - [ ] 测试 {{现有功能 1}} 仍然有效
  - [ ] 验证 {{集成点}} 行为未改变
  - [ ] 检查性能影响

- [ ] 任务 4：添加测试
  - [ ] 遵循 {{项目测试模式}} 的单元测试
  - [ ] {{集成点}} 的集成测试
  - [ ] 如果需要，更新现有测试
```

5. 风险评估和缓解

关键：对于棕地项目 - 始终包括风险评估

为棕地特定风险添加部分：

## 风险评估

### 实施风险

-   **主要风险**：{{对现有系统的主要风险}}
-   **缓解措施**：{{如何解决}}
-   **验证**：{{如何确认安全}}

### 回滚计划

-   {{如果需要，撤消更改的简单步骤}}

### 安全检查

-   [ ] 在更改前测试现有的 {{功能}}
-   [ ] 更改可以通过功能标志或隔离
-   [ ] 回滚过程已记录

6. 最终故事验证

在最终确定之前：

完整性检查：
- 故事有明确的范围和验收标准
- 技术上下文足以实施
- 集成方法已定义
- 风险已识别并有缓解措施
安全检查：
- 包括对现有功能的保护
- 回滚计划是可行的
- 测试涵盖了新功能和现有功能
信息差距：
- 从用户那里收集了所有关键的缺失信息
- 为开发代理记录了剩余的未知数
- 在需要时添加了探索任务

7. 故事输出格式

使用适当的命名保存故事：

如果来自史诗：docs/stories/epic-{n}-story-{m}.md
如果独立：docs/stories/brownfield-{feature-name}.md
如果顺序：遵循现有的故事编号

包括说明文档上下文的标题：

# 故事：{{标题}}

<!-- 来源：{{使用的文档类型}} -->
<!-- 上下文：对 {{现有系统}} 的棕地增强 -->

## 状态：草稿

[故事内容的其余部分...]

8. 交接沟通

向用户提供清晰的交接：

已创建棕地故事：{{故事标题}}

源文档：{{使用了什么}}
故事位置：{{文件路径}}

已识别的关键集成点：
- {{集成点 1}}
- {{集成点 2}}

注意到的风险：
- {{主要风险}}

{{如果信息缺失}}：
注意：一些技术细节尚不清楚。故事中包括了探索任务，以在实施过程中收集所需信息。

后续步骤：
1.  审查故事的准确性
2.  验证集成方法是否与您的系统一致
3.  批准故事或请求调整
4.  然后开发代理可以带安全检查地实施

成功标准

当满足以下条件时，棕地故事创建成功：

故事可以实施，而无需开发人员搜索多个文档
集成方法清晰且对现有系统安全
所有可用的技术上下文都已提取和组织
缺失的信息已识别并得到解决
风险已记录并有缓解策略
故事包括对现有功能的验证
回滚方法已定义

重要说明

此任务专门用于具有非标准文档的棕地项目
始终将现有系统的稳定性置于新功能之上
如有疑问，请添加探索和验证任务
最好向用户澄清，而不是做出假设
每个故事都应该是为开发代理准备的自包含的
在可用时包括对现有代码模式的引用

8.4 KiB Raw Blame History Unescape Escape