story-refiner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Story Refiner

用户故事细化工具

Purpose

用途

Use this skill to refine raw user stories into clear, testable, sprint-ready backlog items. The agent evaluates each story against INVEST, detects common gaps, asks focused refinement questions, and produces a structured improved story with acceptance criteria and negative scenarios.

This skill is domain-generic. It must work for any product, service, workflow, or delivery team without embedding project-specific assumptions.

使用此技能将原始用户故事提炼为清晰、可测试、可用于迭代冲刺的待办事项。Agent会依据INVEST框架评估每个故事，检测常见差距，提出针对性的细化问题，并生成包含验收标准和异常场景的结构化优化后故事。

此技能为通用领域技能，适用于任何产品、服务、工作流或交付团队，无需嵌入特定项目的假设。

When to Use

使用场景

Use this skill when the user asks to:

Improve, rewrite, or refine a user story.
Turn a rough requirement into a sprint-ready backlog item.
Add acceptance criteria to a story.
Check whether a story is ready for sprint planning.
Split an oversized story into smaller stories.
Reframe technical tasks into user-value-oriented stories.
Identify missing edge cases, error scenarios, dependencies, or UX details.

Do not use this skill for enterprise architecture, PRD writing, full technical specifications, source code, implementation plans, or project documentation. Keep the output at backlog-item level.

当用户提出以下需求时，可使用此技能：

改进、重写或细化用户故事。
将粗略需求转化为可用于迭代冲刺的待办事项。
为故事添加验收标准。
检查故事是否可用于冲刺规划。
将过大的故事拆分为更小的故事。
将技术任务重构为以用户价值为导向的故事。
识别缺失的边缘案例、错误场景、依赖关系或UX细节。

请勿将此技能用于企业架构、PRD撰写、完整技术规格、源代码、实施计划或项目文档。输出内容需保持在待办事项级别。

Core Operating Rules

核心操作规则

Use INVEST as the primary evaluation framework. Every story must be checked for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Preserve intent, improve expression. Do not change the user's intended outcome unless a gap makes the story unsafe, unclear, or untestable.
Refocus technical wording on user value. If the input is a technical task, rewrite it as a user or business outcome while preserving necessary implementation constraints as notes.
Make acceptance criteria observable. Replace vague phrases with measurable, testable Given/When/Then criteria.
Include unhappy paths. Always check for error cases, alternative flows, empty states, permission failures, validation failures, unavailable dependencies, and recovery behavior.
Split oversized work. If the story is too large, propose 2-3 smaller stories with separate value and acceptance criteria direction.
Ask only blocking questions. If missing information prevents a correct refinement, ask specific questions. If a safe assumption exists, state it explicitly.
Avoid implementation overreach. Do not prescribe internal design, frameworks, database tables, or APIs unless the user provides them as constraints.
Keep the story sprint-ready. The refined output must be understandable by product, design, engineering, and QA.

以INVEST为主要评估框架。每个故事都必须检查是否符合Independent（独立）、Negotiable（可协商）、Valuable（有价值）、Estimable（可估算）、Small（体量小）和Testable（可测试）标准。
保留意图，优化表述。除非差距导致故事不安全、不清晰或不可测试，否则不要更改用户的预期结果。
将技术表述重新聚焦于用户价值。如果输入是技术任务，将其重写为用户或业务成果，同时保留必要的实施约束作为备注。
使验收标准可观测。用可衡量、可测试的Given/When/Then标准替换模糊表述。
包含异常路径。始终检查错误案例、替代流程、空状态、权限失败、验证失败、依赖不可用以及恢复行为。
拆分过大的工作。如果故事体量过大，提出2-3个更小的故事，每个都有独立的价值和验收标准方向。
仅提出阻塞性问题。如果缺失信息会影响正确细化，提出具体问题。如果可以做出合理假设，需明确说明。
避免过度涉及实现细节。除非用户提供相关约束，否则不要指定内部设计、框架、数据库表或API。
确保故事可用于冲刺。优化后的输出必须能被产品、设计、开发和QA团队理解。

INVEST Evaluation Criteria

INVEST评估标准

Criterion	Question to Ask	Failure Signal	Refinement Action
Independent	Can this story be delivered without strict dependency on another story in the same sprint?	Requires multiple unfinished stories to provide value.	Identify dependency or split by independently valuable increments.
Negotiable	Does it leave room for delivery collaboration?	Reads like a rigid technical contract.	Reframe around outcome and constraints, not detailed design.
Valuable	Is the user or business value explicit?	Describes only a task or component.	Add clear `so that` value and identify beneficiary.
Estimable	Does the team have enough information to estimate effort?	Missing scope, actors, rules, data, or interfaces.	Add assumptions or ask targeted questions.
Small	Can it fit comfortably within a sprint?	Multiple workflows, roles, systems, or large unknowns.	Suggest smaller stories or an epic split.
Testable	Can QA objectively verify completion?	No acceptance criteria or vague outcomes.	Write observable Given/When/Then criteria.

评估标准	需提出的问题	不合格信号	细化操作
Independent（独立）	该故事能否在不依赖同冲刺中其他故事的情况下交付？	需要多个未完成的故事才能提供价值。	识别依赖关系，或拆分为具有独立价值的增量。
Negotiable（可协商）	是否留有交付协作的空间？	读起来像严格的技术合同。	围绕成果和约束重构，而非详细设计。
Valuable（有价值）	用户或业务价值是否明确？	仅描述任务或组件。	添加清晰的 `so that` 价值部分，并明确受益方。
Estimable（可估算）	团队是否有足够信息来估算工作量？	缺失范围、角色、规则、数据或接口。	添加假设或提出针对性问题。
Small（体量小）	是否能轻松容纳在一个冲刺周期内？	包含多个工作流、角色、系统或大量未知项。	建议拆分为更小的故事或标记为史诗（Epic）。
Testable（可测试）	QA能否客观验证完成情况？	没有验收标准或成果模糊。	编写可观测的Given/When/Then标准。

Common Gap Detection

常见差距检测

Actively detect and correct these issues:

Gap	Detection Pattern	Required Response
Vague acceptance criteria	Words like `fast` , `simple` , `works well` , `user-friendly` , `robust` , or `intuitive` without measurement.	Replace with observable behavior, thresholds, or explicit examples.
Happy-path only	No mention of errors, empty states, permissions, invalid input, unavailable dependencies, or recovery.	Add negative and alternative scenarios.
Purely technical task	Story focuses on internal components rather than user or business outcome.	Reframe using `As a [profile], I want [action], so that [value]` .
Missing UX context	No validation messages, visible states, accessibility expectations, or interaction feedback where user interaction exists.	Add UX notes and acceptance criteria for visible behavior.
Hidden dependencies	Needs upstream data, approvals, designs, access, integrations, or decisions.	List dependencies and ask blocking questions if needed.
Oversized story	Multiple actors, workflows, outcomes, or lifecycle stages.	Propose 2-3 smaller stories and mark original as an epic candidate.
Ambiguous actor	`user` is too broad for permissions, goals, or workflows.	Ask or infer a more specific role and mark assumptions.
Weak value statement	`so that` is missing or repeats the action.	Add a concrete user, operational, compliance, or business benefit.

主动检测并修正以下问题：

差距类型	检测模式	应对措施
模糊的验收标准	使用 `fast` 、 `simple` 、 `works well` 、 `user-friendly` 、 `robust` 或 `intuitive` 等无衡量标准的词汇。	替换为可观测的行为、阈值或明确示例。
仅包含正常路径	未提及错误、空状态、权限、无效输入、依赖不可用或恢复机制。	添加异常和替代场景。
纯技术任务	故事聚焦于内部组件而非用户或业务成果。	使用 `As a [角色], I want [操作], so that [价值]` 的格式重构。
缺失UX上下文	用户交互场景中未提及验证消息、可见状态、无障碍要求或交互反馈。	添加UX备注和针对可见行为的验收标准。
隐藏依赖关系	需要上游数据、审批、设计、权限、集成或决策支持。	列出依赖关系，必要时提出阻塞性问题。
过大的故事	包含多个角色、工作流、成果或生命周期阶段。	提出2-3个更小的故事，并将原故事标记为史诗候选。
模糊的角色	`user` 一词对于权限、目标或工作流来说过于宽泛。	询问或推断更具体的角色，并标记假设。
薄弱的价值陈述	`so that` 部分缺失或重复操作内容。	添加具体的用户、运营、合规或业务收益。

Execution Workflow

执行流程

Phase 1: Ingest and Analyze

阶段1：接收与分析

Read the raw story, notes, constraints, and any existing acceptance criteria.
Identify actor, action, value, scope, dependencies, risks, and unknowns.
Score each INVEST criterion as
```
Pass
```
,
```
Partial
```
, or
```
Fail
```
.
Produce a short
```
Detected Gaps
```
report.

读取原始故事、备注、约束条件以及任何现有验收标准。
识别角色、操作、价值、范围、依赖关系、风险和未知项。
将每个INVEST标准评为
```
Pass
```
（通过）、
```
Partial
```
（部分通过）或
```
Fail
```
（不通过）。
生成简短的
```
检测到的差距
```
报告。

Phase 2: Progressive Refinement

阶段2：渐进式细化

If the story is too large, suggest 2-3 smaller stories before writing the final version.
If critical information is missing, ask specific blocking questions.
If missing information is non-blocking, proceed with stated assumptions.
Convert technical wording into user-value wording.
Add acceptance criteria, negative scenarios, dependencies, and notes.

如果故事体量过大，在编写最终版本前先建议拆分为2-3个更小的故事。
如果缺失关键信息，提出具体的阻塞性问题。
如果缺失的信息不影响进程，基于明确的假设继续推进。
将技术表述转换为以用户价值为导向的表述。
添加验收标准、异常场景、依赖关系和备注。

Phase 3: Generate the Refined Story

阶段3：生成细化后的故事

Produce a complete refined story using the required output structure.

使用要求的输出结构生成完整的细化后故事。

Required Output Structure

要求的输出结构

Use this format unless the user requests only a review or only acceptance criteria:

markdown

undefined

除非用户仅要求评审或仅要求验收标准，否则请使用以下格式：

markdown

undefined

<Clear Story Title>

<清晰的故事标题>

Readiness Summary

就绪状态总结

Status: Ready | Needs Clarification | Split Recommended
Reason:

状态：就绪 | 需要澄清 | 建议拆分
原因：

INVEST Review

INVEST评审

Criterion	Status	Notes	Fix Applied

评估标准	状态	备注	已应用的修正

Detected Gaps

检测到的差距

<Gap and impact>

<差距及影响>

Refined User Story

细化后的用户故事

As a <specific actor>, I want <action or capability>, so that <clear value or outcome>.

As a <具体角色>, I want <操作或能力>, so that <明确的价值或成果>.

Acceptance Criteria

验收标准

AC1: <Observable behavior>

AC1: <可观测行为>

Given <context>
When <action>
Then <expected result>

Given <上下文>
When <操作>
Then <预期结果>

AC2: <Observable behavior>

AC2: <可观测行为>

Given <context>
When <action>
Then <expected result>

Given <上下文>
When <操作>
Then <预期结果>

Negative and Edge Scenarios

异常与边缘场景

Given <error or edge context>
When <action>
Then <safe, visible, or recoverable outcome>

Given <错误或边缘上下文>
When <操作>
Then <安全、可见或可恢复的结果>

Dependencies

依赖关系

<Dependency, owner if known, and why it matters>

<依赖项，已知的负责人，以及其重要性>

Assumptions

假设

<Assumption made to keep refinement moving>

<为推进细化而做出的假设>

Open Questions

待解决问题

<Only questions that block correctness, estimation, or testing>

<仅列出影响正确性、估算或测试的问题>

Suggested Splits

建议拆分方案

<Smaller story title>: <value and scope>

undefined

<更小的故事标题>: <价值与范围>

undefined

Splitting Rules

拆分规则

When a story fails

Small

, split by one or more of these dimensions:

User role or permission level.
Happy path before edge cases.
Read-only before write/update behavior.
One workflow step before end-to-end automation.
One channel, platform, or interface before multiple channels.
Core validation before advanced validation.
Manual workflow before automated workflow.

Each split story must still provide independent value and include a testable outcome.

当故事不符合

Small

（体量小）标准时，可通过以下一个或多个维度拆分：

用户角色或权限级别。
先处理正常路径，再处理边缘案例。
先处理只读行为，再处理写入/更新行为。
先处理单个工作流步骤，再处理端到端自动化。
先处理单个渠道、平台或接口，再处理多个渠道。
先处理核心验证，再处理高级验证。
先处理手动工作流，再处理自动化工作流。

每个拆分后的故事仍需具备独立价值，并包含可测试的成果。

Acceptance Criteria Rules

验收标准规则

Use English Given/When/Then wording.
Each criterion must describe one observable behavior.
Include at least one happy-path criterion when applicable.
Include at least one negative or edge scenario when applicable.
Avoid implementation details unless they are externally visible constraints.
Replace vague performance or quality words with measurable thresholds or explicit examples.
If a threshold is unknown, write
```
TBD threshold
```
and ask who can define it.

使用英文Given/When/Then格式表述。
每个标准必须描述一种可观测行为。
适用时至少包含一个正常路径标准。
适用时至少包含一个异常或边缘场景。
避免涉及实现细节，除非是外部可见的约束。
用可衡量的阈值或明确示例替换模糊的性能或质量词汇。
如果阈值未知，写入
```
TBD threshold
```
并询问谁可以定义该阈值。

Quality Checklist

质量检查清单

Before presenting the result, verify:

The output is written in English.
The actor, action, and value are explicit.
INVEST review is complete.
Acceptance criteria are testable and observable.
Error, empty, invalid, permission, and dependency scenarios were considered.
Dependencies and assumptions are visible.
Oversized work is split or marked as split recommended.
The story avoids unnecessary technical implementation detail.
The final output can be used by product, engineering, design, and QA without repeated clarification.

在呈现结果前，需验证：

输出内容为英文。
角色、操作和价值明确。
已完成INVEST评审。
验收标准可测试且可观测。
已考虑错误、空值、无效输入、权限和依赖场景。
依赖关系和假设清晰可见。
过大的工作已拆分或标记为建议拆分。
故事避免不必要的技术实现细节。
最终输出无需反复澄清即可被产品、开发、设计和QA团队使用。

Response Style

响应风格

Be direct, structured, and practical.
Prefer concise tables for evaluation.
Prefer Gherkin bullets for acceptance criteria.
Use neutral role names such as
```
domain user
```
,
```
authorized user
```
,
```
operator
```
,
```
administrator
```
, or
```
system actor
```
when the exact persona is unknown.
Mark unknowns as
```
TBD
```
instead of inventing business context.

直接、结构化且实用。
优先使用简洁表格进行评估。
优先使用Gherkin格式的项目符号列出验收标准。
当具体角色未知时，使用中性角色名称，如
```
domain user
```
、
```
authorized user
```
、
```
operator
```
、
```
administrator
```
或
```
system actor
```
。
将未知项标记为
```
TBD
```
，而非编造业务上下文。