Story Refiner by bobchao/pm-skills-rfp-to-stories
npx skills add https://github.com/bobchao/pm-skills-rfp-to-stories --skill 'Story Refiner'默认:使用与用户输入相同的语言或用户明确要求的语言进行回应。
如果用户指定了偏好语言(例如,“請用中文回答”、“Reply in Japanese”),则所有输出都使用该语言。否则,与提供的 Stories 的语言保持一致。
你同时扮演三个角色来评审用户故事:
此 Skill 接受以下输入:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
所有评分和评估必须遵循 references/evaluation-criteria.md 中定义的标准。
该文档定义了:
重要提示:快速扫描(第 1 阶段)和详细评估(第 2 阶段)都使用这些相同的标准,只是深度不同。
使用 references/evaluation-criteria.md 中的三个维度,为每个 Story 进行初步评分(1-5 分):
评分方法:
round((开发清晰度 + 可测试性 + 价值清晰度) / 3)references/evaluation-criteria.md 中的评分标准表作为参考快速评估重点:
| 分数 | 等级 | 操作 |
|---|---|---|
| 5 | 优秀 | 保留,无需修改 |
| 4 | 良好 | 保留,可能有次要建议 |
| 3 | 通过 | 标记为待观察,可能需要微调 |
| 2 | 不足 | 必须修正 |
| 1 | 严重不足 | 必须重写 |
只有评分 ≤ 3 的 Stories 进入第 2 阶段的详细评估。
对于需要评审的 Stories,使用 references/evaluation-criteria.md 中定义的具体检查点和常见扣分模式,从三个视角进行详细评估。
参考:references/evaluation-criteria.md - 维度 1:开发清晰度
详细检查点(来自 evaluation-criteria.md):
常见问题(参见 evaluation-criteria.md 中的扣分模式):
参考:references/evaluation-criteria.md - 维度 2:可测试性
详细检查点(来自 evaluation-criteria.md):
常见问题(参见 evaluation-criteria.md 中的扣分模式):
参考:references/evaluation-criteria.md - 维度 3:价值清晰度
详细检查点(来自 evaluation-criteria.md):
常见问题(参见 evaluation-criteria.md 中的扣分模式):
对于评分 ≤ 3 的 Stories,根据问题类型执行修正:
| 问题类型 | 修正方法 |
|---|---|
| 范围过大 | 拆分为多个 Stories |
| 范围模糊 | 添加具体操作描述 |
| 价值不清晰 | 重写"以便..."部分 |
| 不可测试 | 添加具体的验收标准 |
| 格式问题 | 调整为标准格式 |
| 角色错误 | 修正为正确的角色 |
| 粒度不当 | 拆分或合并 |
修正后的 Stories 需要重新评估,以确保质量达到标准。这是迭代优化的核心。
| 情况 | 单次优化的问题 | 迭代解决方案 |
|---|---|---|
| Story 被拆分 | 新的 Stories 未被评估 | ✅ 下一轮评估新的 Stories |
| 过度修正 | 可能会破坏某些东西 | ✅ 下一轮发现并进行微调 |
| 验收标准仍然不具体 | 可能通过 | ✅ 下一轮加强 |
第 1 轮:评估所有 Stories → 修正低分项 → 生成修正版本
↓
第 2 轮:评估"修正后的" + "新生成的" Stories → 如有需要再次修正
↓
第 3 轮:(如果仍有问题)最终微调
↓
终止:输出最终版本
| 规则 | 描述 |
|---|---|
| 渐进收敛 | 每轮应减少问题,而不是增加问题 |
| 历史记忆 | 跟踪每个 Story 的修正历史,避免来回更改 |
| 修正限制 | 同一 Story 只能进行一次重大更改,之后只能微调 |
| 新 Story 优先 | 从第 2 轮开始,优先评估上一轮生成的 Stories |
| 轮次 | 允许的修正类型 |
|---|---|
| 第 1 轮 | 所有修正(拆分、重写、添加验收标准等) |
| 第 2 轮 | 中等修正(添加验收标准、调整措辞、次要拆分) |
| 第 3 轮 | 仅微调(词语修正、添加细节、不拆分或重写) |
此设计确保:
每轮结束时记录:
### 第 N 轮优化摘要
| 指标 | 值 |
|--------|-------|
| 评估的 Stories 数 | XX |
| 进行的修正数 | XX |
| 新增(来自拆分) | XX |
| 平均分数提升 | +X.X |
**本轮修正**:
- US-XXX: [修正摘要]
- US-XXX: [修正摘要]
**继续?**: [是/否,原因]
# Story 优化报告
## 📊 优化摘要
### 总体结果
- 原始 Story 数量:XX
- 最终 Story 数量:XX(包括拆分新增的)
- 优化轮次:X / 3
- 终止原因:[质量达标 / 无需修正 / 达到限制]
### 每轮统计
| 轮次 | 评估数 | 修正数 | 新增数 | 平均分数 |
|-------|-----------|-----------|-------|---------------|
| 第 1 轮 | XX | XX | XX | X.X |
| 第 2 轮 | XX | XX | XX | X.X |
| ... | ... | ... | ... | ... |
## 🔄 优化历史
[每轮修正摘要,可折叠]
## ✅ 最终通过的 Stories
[评分 ≥ 4 的 Stories]
## 🔧 修正过的 Stories
[原始 → 最终版本对比,注明修正轮次]
## ➕ 拆分生成的新 Stories
[拆分产生的新 Stories]
## 🗑️ 建议移除的 Stories
[不符合需求或重复的 Stories]
## 📋 最终 Story 列表
[完整的整合列表,可供使用]
### 🔧 US-XXX: [标题]
**原始版本**:
> 作为 [角色],我想要 [操作],以便 [价值]。
**问题诊断**:
- 🧪 QA 视角:验收标准不清晰,无法编写测试
- 👨💻 开发人员视角:范围包含多个独立功能
**修正方法**:拆分为两个 Stories + 添加验收标准
**改进版本**:
**US-XXX-A**:作为 [角色],我想要 [操作 A],以便 [价值]。
- 验收标准:
- [ ] 条件 1
- [ ] 条件 2
**US-XXX-B**:作为 [角色],我想要 [操作 B],以便 [价值]。
- 验收标准:
- [ ] 条件 1
---
这可能表明 Story Writer 阶段存在系统性问题:
如果与 RFP 对比发现 Stories 未覆盖的功能:
如果所有 Stories 评分 ≥ 4:
参考 assets/refine-example.md 获取完整的输出示例。
references/evaluation-criteria.md - 定义了所有三个维度的详细评分标准assets/refine-example.md - 完整的优化报告示例[rfp-analyzer] → [story-writer] → [story-refiner] → 最终输出
用法:在 Story Writer 生成用户故事草稿后,使用 Story Refiner 评估质量并自动修正低分 Stories。这是一个单独的步骤,当需要优化时应明确调用。
当用户要求"严格检查"或项目风险较高时:
当用户要求"快速通过"或项目是 MVP/POC 时:
完成优化后,确认以下项目:
当用户明确表示"快速优化"或"仅一次"时:
如果 3 轮后仍有大量低分 Stories:
每周安装数
0
仓库
GitHub 星标
24
首次出现
Jan 1, 1970
安全审计
Default : Respond in the same language as the user's input or as explicitly requested by the user.
If the user specifies a preferred language (e.g., "請用中文回答", "Reply in Japanese"), use that language for all outputs. Otherwise, match the language of the provided Stories.
You simultaneously play three roles to review User Stories:
This Skill accepts the following inputs:
All scoring and evaluation must follow the standards defined inreferences/evaluation-criteria.md.
This document defines:
Important : Both Quick Scan (Phase 1) and Detailed Evaluation (Phase 2) use these same criteria, with different levels of depth.
Score each Story initially (1-5 points) using the three dimensions from references/evaluation-criteria.md:
Scoring Method :
round((Development Clarity + Testability + Value Clarity) / 3)references/evaluation-criteria.md as referenceQuick Assessment Focus :
| Score | Level | Action |
|---|---|---|
| 5 | Excellent | Keep, no modification |
| 4 | Good | Keep, may have minor suggestions |
| 3 | Passing | Mark for observation, may need minor adjustments |
| 2 | Insufficient | Must correct |
| 1 | Severely insufficient | Must rewrite |
Only Stories scoring ≤ 3 enter Phase 2 detailed evaluation.
For Stories needing review, perform detailed evaluation from three perspectives using the Specific Checkpoints and Common Deduction Patterns defined in references/evaluation-criteria.md.
Reference : references/evaluation-criteria.md - Dimension 1: Development Clarity
Detailed Checkpoints (from evaluation-criteria.md):
Common Problems (see evaluation-criteria.md for deduction patterns):
Reference : references/evaluation-criteria.md - Dimension 2: Testability
Detailed Checkpoints (from evaluation-criteria.md):
Common Problems (see evaluation-criteria.md for deduction patterns):
Reference : references/evaluation-criteria.md - Dimension 3: Value Clarity
Detailed Checkpoints (from evaluation-criteria.md):
Common Problems (see evaluation-criteria.md for deduction patterns):
For Stories scoring ≤ 3, execute corrections based on problem type:
| Problem Type | Correction Method |
|---|---|
| Scope too large | Split into multiple Stories |
| Scope vague | Add specific operation description |
| Value unclear | Rewrite "so that..." part |
| Not testable | Add specific acceptance criteria |
| Format issue | Adjust to standard format |
| Wrong role | Correct to proper role |
| Improper granularity | Split or merge |
Corrected Stories need re-evaluation to ensure quality meets standards. This is the core of iterative refinement.
| Situation | Single-Pass Refinement Problem | Iterative Solution |
|---|---|---|
| Story is split | New Stories aren't evaluated | ✅ Next round evaluates new Stories |
| Over-correction | Might break something | ✅ Next round catches and fine-tunes |
| Acceptance criteria still not specific | Passes through | ✅ Next round strengthens |
Round 1: Evaluate all Stories → Correct low-scoring items → Produce corrected version
↓
Round 2: Evaluate "corrected" + "newly generated" Stories → Correct again if needed
↓
Round 3: (If still issues) Final fine-tuning
↓
Terminate: Output final version
| Rule | Description |
|---|---|
| Progressive convergence | Each round should reduce problems, not increase them |
| History memory | Track each Story's correction history, avoid back-and-forth changes |
| Correction limit | Same Story can only be majorly changed once, then only fine-tuned |
| New Story priority | From round 2, prioritize evaluating Stories generated in previous round |
| Round | Allowed Correction Types |
|---|---|
| Round 1 | All corrections (split, rewrite, add acceptance criteria, etc.) |
| Round 2 | Moderate corrections (add acceptance criteria, adjust wording, minor splits) |
| Round 3 | Fine-tuning only (word corrections, add details, no splitting or rewriting) |
This design ensures:
Record at end of each round:
### Round N Refinement Summary
| Metric | Value |
|--------|-------|
| Stories Evaluated | XX |
| Corrections Made | XX |
| New (from splits) | XX |
| Average Score Improvement | +X.X |
**This Round's Corrections**:
- US-XXX: [Correction summary]
- US-XXX: [Correction summary]
**Continue?**: [Yes/No, reason]
# Story Refinement Report
## 📊 Refinement Summary
### Overall Results
- Original Story Count: XX
- Final Story Count: XX (including split additions)
- Refinement Rounds: X / 3
- Termination Reason: [Quality achieved / No corrections needed / Limit reached]
### Per-Round Statistics
| Round | Evaluated | Corrected | Added | Average Score |
|-------|-----------|-----------|-------|---------------|
| Round 1 | XX | XX | XX | X.X |
| Round 2 | XX | XX | XX | X.X |
| ... | ... | ... | ... | ... |
## 🔄 Refinement History
[Per-round correction summaries, collapsible]
## ✅ Final Passing Stories
[Stories scoring ≥ 4]
## 🔧 Corrected Stories
[Original → Final version comparison, noting correction round]
## ➕ Split-Generated Stories
[New Stories from splits]
## 🗑️ Recommended for Removal
[Stories not matching requirements or duplicates]
## 📋 Final Story List
[Complete integrated list, ready for use]
### 🔧 US-XXX: [Title]
**Original Version**:
> As a [role], I want [action], so that [value].
**Problem Diagnosis**:
- 🧪 QA Perspective: Acceptance criteria unclear, can't write tests
- 👨💻 Developer Perspective: Scope includes multiple independent features
**Correction Method**: Split into two Stories + add acceptance criteria
**Improved Version**:
**US-XXX-A**: As a [role], I want [action A], so that [value].
- Acceptance Criteria:
- [ ] Condition 1
- [ ] Condition 2
**US-XXX-B**: As a [role], I want [action B], so that [value].
- Acceptance Criteria:
- [ ] Condition 1
---
This may indicate systematic issues in Story Writer phase:
If comparing to RFP reveals features not covered by Stories:
If all Stories score ≥ 4:
Refer to assets/refine-example.md for complete output example.
references/evaluation-criteria.md - Defines detailed scoring standards for all three dimensionsassets/refine-example.md - Complete refinement report example[rfp-analyzer] → [story-writer] → [story-refiner] → Final output
Usage : After Story Writer produces User Stories draft, use Story Refiner to evaluate quality and automatically correct low-scoring Stories. This is a separate step that should be called explicitly when refinement is needed.
When user requests "strict check" or project risk is higher:
When user requests "quick pass" or project is MVP/POC:
After completing refinement, confirm the following items:
When user explicitly says "quick refine" or "one pass only":
If large numbers of low-scoring Stories remain after 3 rounds:
Weekly Installs
0
Repository
GitHub Stars
24
First Seen
Jan 1, 1970
Security Audits
Skills CLI 使用指南:AI Agent 技能包管理器安装与管理教程
29,800 周安装
Docnify自动化:通过Rube MCP和Composio工具包实现文档操作自动化
1 周安装
Docmosis自动化集成指南:通过Rube MCP与Composio实现文档生成自动化
1 周安装
Dictionary API自动化教程:通过Rube MCP和Composio实现词典API操作自动化
1 周安装
detrack-automation:自动化追踪技能,集成Claude AI提升开发效率
1 周安装
Demio自动化工具包:通过Rube MCP和Composio实现Demio操作自动化
1 周安装
Deel自动化工具:通过Rube MCP与Composio实现HR与薪资操作自动化
1 周安装