关于 write-user-story
将源材料整理为包含验收标准的原子化、可测试用户故事，适用于编写需求的人员。遇到信息缺失时强调先澄清，而非自行补充规则。
主要功能
- 01将源材料转为一个或多个故事
- 02要求提供可测试的验收标准
- 03检查清晰度与原子性
- 04标出假设和待确认问题
- 05提供后续评审与测试用例技能
适用场景
- 01根据产品需求撰写故事
- 02澄清不完整或含糊的规则
- 03准备故事以供需求评审
- 04从故事整理测试用例
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/write-user-story确认已加载。
详细介绍
编写用户故事
将源材料转化为一个或多个用户故事。每个故事的验收标准都是其必须满足的要求，即可测试、原子化的规则。
如果数据源是 PR，请使用 qa-pr-requirements-analyzer 技能。
如果数据源是问题跟踪系统中的工单，请请求 MCP 连接。
规则
用户故事必须满足以下要求（但不限于此）：
- 原子化 — 一个参与者、一项能力。
- 清晰 — 不使用模糊词语（
快速、相关、用户友好、应该有效、按需）。 - 完整 — 包含参与者、触发条件、结果和业务规则；在验收标准中覆盖空值、错误和权限相关情形。
- 一致 — 始终使用相同术语；不得自相矛盾。
- 可测试 — 每个故事都有可衡量通过或失败的验收标准。
请遵循以下规则：
- 遵循编写用户故事的其他最佳实践。
- 描述是什么，而不是如何实现。除非用户提出要求，否则不要涉及 UI 控件、API 实现细节或框架。
- 标明假设和待解决的问题。绝不擅自编造缺失的规则。不要猜测、想象或假设。如果有任何内容不明确，请始终向用户澄清。
输出
默认格式：需求（描述）+ 验收标准。若用户指定了格式，则遵循用户指定的格式。（根据用户提供的上下文，也可包含其他部分。）
每项需求至少包含一条验收标准。为验收标准标注简短且唯一的 ID（例如 AC-1）。（最好将 ID 放在行末，使输出更易读。）
后续操作
- 检查缺口和可测试性 →
qa-requirement-reviewer - 风险场景 →
qa-thinking - 根据这些用户故事编写测试用例 →
qa-write-test-cases
评论
支持 Markdown