escribir-hus

编写用户故事

目标

将 PRD 转化为可执行的用户故事，无论项目属于哪个领域（医疗、金融科技、零售或其他领域）：每个用户故事都必须能够直接实施，无需任何人猜测 PRD 未说明的内容。

输入

• PRD，包含 5 个部分（格式固定；领域各不相同，绝不预设）：
  1. 问题
  2. 目标
  3. 范围（包含 / 不包含）
  4. 假设与待确认事项
  5. 成功标准
• 如果系统已存在且已完成上下文整理： docs/contexto/GLOSARIO.md 和 docs/contexto/CAPACIDADES.md。用户故事使用术语表中的术语，并且不重复系统已有的能力。

如果 PRD 缺少某个部分，应灵活调整，但不改变流程（例如，从问题中提取目标），并明确说明。

工作流

1. 写作前先完整阅读 5 个部分。 范围界定边界；待确认事项标明尚未决定的内容。
2. 识别范围中明确的功能。 每项功能都转换为一个用户故事：不要把多个功能合并成一个庞大的用户故事，也不要过度拆分，为同一操作的子步骤创建虚假的用户故事。
3. 在解决冲突之前，先识别各部分之间的冲突。 如果范围、目标和成功标准的表述不一致，不要默默做出决定：记录冲突，只构建满足标准所需的最少内容，并明确说明仍需业务方确认。
4. 使用 assets/hu-template.md 编写每个用户故事： 故事（作为/我想要/以便）+ 至少 2 个 Gherkin 场景（正常流程 + 1 个边界情况）。
5. 跨功能业务规则（例如，适用于多个功能的成功标准）应作为边界场景，在每个受影响的用户故事中验证，而不是单独创建一个用户故事。
6. 不得为了方便而假设 PRD 未确认的任何数据。 应将其列为待确认事项，并写出实际会向业务方提出的问题。
7. 不得添加任何标记为“不包含”的内容，即使它看起来是显而易见的改进。
8. 仅将待确认事项分配给其字面适用的用户故事，不要默认把所有事项复制到每个用户故事中。
9. 每个用户故事单独使用一个 Markdown 文件，并保存在项目文件夹中。

质量检查

• 已阅读 PRD 的 5 个部分（而非仅阅读范围）
• 每个用户故事都对应范围中的一项明确功能：既未合并，也未过度拆分
• 每个用户故事至少包含 2 个 Gherkin 场景（正常流程 + 边界情况）
• 没有将任何假设的数据写成已确定的内容
• “不包含”列表中的内容均未混入功能
• 每项待确认事项都包含向业务方提出的确切问题，而非伪装成假设的内容
• 已记录 PRD 各部分之间的冲突，没有默默解决
• 如果系统已完成上下文整理：使用了术语表中的术语，且未重复已有能力
• 每个用户故事单独使用一个 Markdown 文件，并保存在项目文件夹中

参考资料

• assets/hu-template.md — 用户故事模板。
• references/ejemplos-aplicados.md — 先前项目中已解决的案例（范围冲突、待确认事项、其他 Agent 提出的范围外内容）。