write-user-story

用途：在创建或精炼用户故事、技术使能项、探索或政策工单，定义验收标准，或为范围化工作做准备时使用。\n\n结构与能力：每个故事按顺序包含 Purpose/Overview、Requirements/Scope、Acceptance Criteria 三个核心部分；支持性章节按实际交付物选择，而非照搬模板。工作类型依据请求与上下文判断，仅当未澄清的区别会实质改变故事时才提一个聚焦问题。技术使能项与探索/政策工作不要求虚构最终用户画像。\n\n验收标准：使用 Given-When-Then 描述可观察行为，或对技术契约/决策交付物用简洁可验证清单；每条覆盖一个明确完成条件，涵盖重要错误与边界行为，不把每个配置项都展开成场景；无固定条数要求，也不写完整测试计划。\n\n验证方式：面向用户或运行时改动可加 Testing Guidance，真实 UI 流程可用 Manual Testing；后端/API/库改动可加 Controlled Verification；纯探索/政策/决策工作不写运行时 Testing Guidance。测试代码、mock 配置、fixture 脚本与实现级测试用例应留在故事之外。\n\n条件章节：仅在条件成立时添加 Out of Scope、Non-Functional Requirements、Additional Notes、Technical Approach、Related Links；有约束作用的承诺应放在 Requirements 与可验证的验收标准中。\n\n写作准则：真实用户角色可用 As a…I want…So that… 格式；技术使能或决策工单直接陈述结果与价值。遵循 INVEST 原则，故事应可在单个迭代内完成。参考文件：references/section-details.md、references/pitfalls.md、references/example.md、references/jira.md。限制：资料未提供安装命令、收费、价格、平台或效果信息。