epic-breakdown-advisor by deanpeters/product-manager-skills
npx skills add https://github.com/deanpeters/product-manager-skills --skill epic-breakdown-advisor指导产品经理使用 Richard Lawrence 的完整 Humanizing Work 方法论,将史诗拆分为用户故事——这是一种系统化的、流程图驱动的方法,按顺序应用 9 种拆分模式。使用此方法来识别哪种模式适用,在保留用户价值的同时进行拆分,并根据拆分所揭示的可消除的低价值工作来评估拆分结果。这确保了垂直切片(端到端价值)而非水平切片(技术层)。
这不是随意的切割——这是一个经过验证的、有条不紊的过程,从验证开始,按顺序遍历模式,并战略性地评估结果。
用户故事是“从用户角度描述系统行为的改变”。拆分必须保持垂直切片——涉及多个架构层并交付可观察用户价值的工作——而不是处理单个组件的水平切片(例如,“前端故事” + “后端故事”)。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
将 workshop-facilitation 作为此技能的默认交互协议。
它定义了:
其他(请指定))此文件定义了特定领域的评估内容。如果存在冲突,请遵循此文件的领域逻辑。
代理询问:
请分享你的史诗:
你可以从 Jira、Linear 粘贴或简要描述。
在拆分之前,验证你的故事是否满足 INVEST 标准(除了“小”):
代理按顺序提问:
1. 独立的? “这个故事能否在没有硬性技术依赖其他故事的情况下进行优先级排序和开发?”
选项:
2. 可协商的? “这个故事是否为团队协作发现实现细节留出了空间,而不是规定确切的解决方案?”
选项:
3. 有价值的? “这个故事是否向用户交付了可观察的价值?(如果没有,请将其与相关工作结合,而不是拆分。)”
选项:
⚠️ 关键检查: 如果故事未通过“有价值的”检查,停止。不要拆分。相反,将其与其他工作结合以创建有意义的增量。
4. 可估算的? “你的团队能否(即使是粗略地)相对估算这个故事的大小?”
选项:
5. 可测试的? “这个故事是否有具体的验收标准供 QA 验证?”
选项:
如果故事通过所有检查 → 进入步骤 2(拆分模式) 如果故事未通过任何检查 → 在拆分前解决问题
按顺序处理模式。对于每种模式,询问“这适用吗?”
关键洞察: 拆分为薄端到端切片,而非逐步拆分。从涵盖完整工作流的简单案例开始,然后将中间步骤作为独立故事添加。
代理询问: “你的史诗是否涉及多步骤工作流,你可以先交付一个简单案例,然后再添加中间步骤?”
示例:
每个故事都交付完整工作流,只是复杂度逐渐增加。
选项:
如果是: 代理生成薄端到端切片拆分。
关键洞察: “管理”一词暗示了多个操作。拆分为创建、读取、更新、删除。
代理询问: “你的史诗是否使用了‘管理’、‘处理’或‘维护’等词语?如果是,它很可能捆绑了多个操作(CRUD)。”
示例:
选项:
如果是: 代理为每个操作生成一个故事。
关键洞察: 当相同功能在不同规则下运行时,每个规则都成为自己的故事。
代理询问: “你的史诗是否针对不同场景(用户类型、地区、层级、条件)有不同的业务规则?”
示例:
选项:
如果是: 代理为每个规则变体生成一个故事。
关键洞察: 复杂性源于处理不同的数据类型或结构。根据需要即时添加变体。
代理询问: “你的史诗是否处理不同的数据类型、格式或结构(例如,文件类型、地理层级、用户属性)?”
示例:
选项:
如果是: 代理为每个数据变体生成一个故事(先交付最简单的)。
关键洞察: UI 复杂性与核心功能无关。先构建最简单的界面,然后将复杂的 UI 作为后续任务添加。
代理询问: “你的史诗是否包含对核心功能非必需的花哨 UI 元素(日期选择器、自动完成、拖放)?”
示例:
选项:
如果是: 代理生成故事 1 = 基本输入,故事 2+ = UI 增强。
关键洞察: 当初始实现承载大部分复杂性,而添加部分微不足道时。构架为“实现一个 + 添加其余”。
代理询问: “你的史诗是否涉及构建基础设施,其中第一个实现很困难,但添加更多却很容易?”
示例:
⚠️ 注意: 第一个故事承担重担(支付网关、安全性、合规性)。后续故事是小的添加。
选项:
如果是: 代理生成故事 1 = 构建基础设施,故事 2 = 添加其余变体。
关键洞察: 通过询问“最简单的版本是什么?”来识别故事的核心。将变体提取为独立的故事。
代理询问: “这个史诗的最简单版本是什么,仍然能交付价值?你能剥离复杂性,稍后再加回来吗?”
示例:
选项:
如果是: 代理生成故事 1 = 最简单核心,故事 2+ = 变体。
关键洞察: 将“让它工作”与“让它变快”分开。非功能性需求(性能、安全性、可扩展性)可以在功能交付之后进行。
代理询问: “你能先交付功能价值,然后再优化性能/安全性/可扩展性吗?”
示例:
选项:
如果是: 代理生成故事 1 = 功能性,故事 2 = 优化。
关键洞察: 当不确定性阻碍拆分时的最后手段。进行时间盒调查以回答特定问题,然后在更好理解的基础上拆分实现故事。
代理说明: “模式 1-8 均不适用,这表明高度不确定性。在拆分之前,运行一个探针来减少不确定性。”
探针是一个时间盒调查(不是故事),回答诸如以下问题:
代理询问: “阻碍你拆分这个史诗的最大未知数是什么?”
选项:
代理建议: → “运行一个 1-2 天的探针来回答[问题]。探针结束后,回来,我们将在更好理解的基础上拆分史诗。”
⚠️ 探针产生的是学习成果,而非可交付的代码。探针结束后,从模式 1 重新开始。
拆分后,使用以下标准进行评估:
代理询问:
1. 这个拆分是否揭示了你可以降低优先级或消除的低价值工作?
2. 这个拆分是否产生了大小更相等的故事?
如果拆分不满足任一标准,请尝试不同的模式。
在所有模式中,遵循此顺序:
策略根据复杂性领域而变化:
代理询问: “这个史诗周围有多少不确定性?”
选项:
低不确定性(明显/复杂领域) —— “我们知道要构建什么;这只是工程工作” → 找出所有故事,按价值/风险排序优先级
高不确定性(复杂领域) —— “我们不确定客户想要什么或什么会有效” → 识别 1-2 个学习故事;避免详尽列举(工作本身会教给我们什么重要)
混乱 —— “一切都一团糟;优先级每天都在变化” → 推迟拆分,直到出现稳定性;首先专注于稳定化
# 史诗分解计划
**史诗:** [原始史诗]
**拆分前验证:** ✅ 通过 INVEST(除了小)
**应用的拆分模式:** [模式名称]
**理由:** [为什么此模式适用]
---
## 故事分解
### 故事 1:[标题](最简单完整切片)
**摘要:** [关注用户价值的标题]
**用例:**
- **作为** [用户画像]
- **我想要** [行动]
- **以便** [结果]
**验收标准:**
- **前提:** [前置条件]
- **当:** [行动]
- **那么:** [结果]
**为何先做这个:** [交付核心价值;更简单的变体后续]
**预估工作量:** [天数/点数]
---
### 故事 2:[标题](第一个变体)
[重复...]
---
### 故事 3:[标题](第二个变体)
[重复...]
---
## 拆分评估
✅ **这个拆分是否揭示了低价值工作?**
- [分析:哪些故事可以被降低优先级/消除?]
✅ **这个拆分是否产生了大小相等的故事?**
- [分析:故事的工作量是否大致相等?]
---
## INVEST 验证(每个故事)
✅ **独立的:** 故事可以按任何顺序开发
✅ **可协商的:** 实现细节可以协作发现
✅ **有价值的:** 每个故事都交付可观察的用户价值
✅ **可估算的:** 团队可以估算每个故事的大小
✅ **小的:** 每个故事适合 1-5 天
✅ **可测试的:** 每个故事都有清晰的验收标准
---
## 后续步骤
1. **与团队评审:** PM、设计、工程是否同意?
2. **检查是否需要进一步拆分:** 是否有故事仍然 >5 天?如果是,**从模式 1 重新开始**处理该故事。
3. **确定优先级:** 哪个故事首先交付最大价值?
4. **考虑消除:** 拆分是否揭示了低价值故事?取消或推迟它们。
---
**如果故事仍然太大,请从模式 1 开始重新应用模式。**
史诗: “发布博客文章(需要编辑审核、法律批准、预发布)”
拆分前验证: ✅ 通过 INVEST
模式 1: “这有工作流步骤吗?” → 是 ✅
❌ 错误拆分(逐步):
✅ 正确拆分(薄端到端):
为何有效: 每个故事都交付完整工作流,只是复杂度逐渐增加。
史诗: “管理用户资料”
模式 2: “这说了‘管理’吗?” → 是 ✅(暗示 CRUD)
拆分:
拆分评估:
史诗: “带最大经停数、附近机场、灵活日期的航班搜索”
模式 7: “最简单的版本是什么?” → 基本搜索 ✅
拆分:
拆分评估:
史诗: “带折扣(会员、VIP、首次)和支付(Visa、Mastercard、Amex)的结账流程”
第一轮 - 模式 1(工作流): 是 ✅
检查故事 2(“应用折扣”): 仍然 4 天 → 太大,重新拆分
第二轮处理故事 2 - 模式 3(业务规则): 是 ✅
检查故事 3(“完成支付”): 仍然 5 天 → 太大,重新拆分
第三轮处理故事 3 - 模式 6(主要工作量): 是 ✅
最终分解: 6 个故事,每个 1-2 天
症状: 不检查 INVEST 就直接开始拆分
后果: 拆分了不应该拆分的故事(例如,没有价值 = 技术任务)
解决方法: 在步骤 2(拆分模式)之前始终运行步骤 1(INVEST 检查)
症状: 故事 1 = “编辑审核”,故事 2 = “法律批准”
后果: 故事不交付端到端价值
解决方法: 每个故事应涵盖完整工作流(薄端到端切片),只是复杂度逐渐增加
症状: “故事 1:构建 API。故事 2:构建 UI。”
后果: 两个故事都不交付用户价值
解决方法: 垂直切片——每个故事都包含前端 + 后端以交付可观察的用户行为
症状: “即使没有顺序,我们也要按工作流拆分”
后果: 随意、无意义的拆分
解决方法: 如果模式不适用,说否并继续下一个模式
症状: 将史诗拆分为 3 个故事,但每个仍然 5+ 天
后果: 故事太大,不适合冲刺
解决方法: 对每个大型故事从模式 1 重新开始,直到所有故事都在 1-5 天
症状: 拆分但不评估是否揭示了低价值工作
后果: 错失消除浪费的机会
解决方法: 拆分后,询问:“这揭示了我们可以取消或推迟的工作吗?”
Humanizing Work 建议: 团队通过多次练习,在 2.5-3 小时内达到熟练。
实践方法:
不要跳过实践工作。 技能是通过分析过去的交付成果而发展的,而不仅仅是完善未来的工作。
user-story-splitting.md —— 9 种模式的详细说明user-story.md —— 编写故事的格式epic-hypothesis.md —— 原始史诗格式技能类型: 交互式 建议文件名: epic-breakdown-advisor.md 建议放置位置: /skills/interactive/ 依赖项: 使用 user-story-splitting.md, user-story.md, epic-hypothesis.md
每周安装数
233
代码库
GitHub 星标数
1.5K
首次出现
2026年2月12日
安全审计
安装于
codex203
opencode201
gemini-cli197
github-copilot196
kimi-cli193
amp193
Guide product managers through breaking down epics into user stories using Richard Lawrence's complete Humanizing Work methodology—a systematic, flowchart-driven approach that applies 9 splitting patterns sequentially. Use this to identify which pattern applies, split while preserving user value, and evaluate splits based on what they reveal about low-value work you can eliminate. This ensures vertical slicing (end-to-end value) rather than horizontal slicing (technical layers).
This is not arbitrary slicing—it's a proven, methodical process that starts with validation, walks through patterns in order, and evaluates results strategically.
A user story is "a description of a change in system behavior from the perspective of a user." Splitting must maintain vertical slices —work that touches multiple architectural layers and delivers observable user value—not horizontal slices addressing single components (e.g., "front-end story" + "back-end story").
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
Agent asks:
Please share your epic:
You can paste from Jira, Linear, or describe briefly.
Before splitting, verify your story satisfies INVEST criteria (except "Small"):
Agent asks questions sequentially:
1. Independent? "Can this story be prioritized and developed without hard technical dependencies on other stories?"
Options:
2. Negotiable? "Does this story leave room for the team to discover implementation details collaboratively, rather than prescribing exact solutions?"
Options:
3. Valuable? "Does this story deliver observable value to a user? (If not, combine it with related work rather than splitting.)"
Options:
⚠️ Critical Check: If story fails "Valuable," STOP. Don't split. Instead, combine with other work to create a meaningful increment.
4. Estimable? "Can your team size this story relatively (even if roughly)?"
Options:
5. Testable? "Does this story have concrete acceptance criteria that QA can verify?"
Options:
If story passes all checks → Proceed to Step 2 (Splitting Patterns) If story fails any check → Fix the issue before splitting
Work through patterns in order. For each pattern, ask "Does this apply?"
Key insight: Split into thin end-to-end slices , not step-by-step. Start with a simple case covering the full workflow , then add intermediate steps as separate stories.
Agent asks: "Does your epic involve a multi-step workflow where you could deliver a simple case first, then add intermediate steps later?"
Example:
Each story delivers full workflow , just with increasing sophistication.
Options:
If YES: Agent generates thin end-to-end slice splits.
Key insight: The word "manage" signals multiple operations. Split into Create, Read, Update, Delete.
Agent asks: "Does your epic use words like 'manage,' 'handle,' or 'maintain'? If so, it likely bundles multiple operations (CRUD)."
Example:
Options:
If YES: Agent generates one story per operation.
Key insight: When identical functionality operates under different rules, each rule becomes its own story.
Agent asks: "Does your epic have different business rules for different scenarios (user types, regions, tiers, conditions)?"
Example:
Options:
If YES: Agent generates one story per rule variation.
Key insight: Complexity from handling different data types or structures. Add variations just-in-time as needed.
Agent asks: "Does your epic handle different data types, formats, or structures (e.g., file types, geographic levels, user attributes)?"
Example:
Options:
If YES: Agent generates one story per data variation (deliver simplest first).
Key insight: UI complexity independent of core functionality. Build simplest interface first, then add sophisticated UI as follow-ups.
Agent asks: "Does your epic include fancy UI elements (date pickers, autocomplete, drag-and-drop) that aren't essential to core functionality?"
Example:
Options:
If YES: Agent generates Story 1 = basic input, Story 2+ = UI enhancements.
Key insight: When initial implementation carries most complexity, with additions being trivial. Frame as "implement one + add remaining."
Agent asks: "Does your epic involve building infrastructure where the first implementation is hard, but adding more is easy?"
Example:
⚠️ Note: First story does the heavy lift (payment gateway, security, compliance). Subsequent stories are small additions.
Options:
If YES: Agent generates Story 1 = build infrastructure, Story 2 = add remaining variants.
Key insight: Identify story's core by asking "What's the simplest version?" Extract variations into separate stories.
Agent asks: "What's the simplest version of this epic that still delivers value? Can you strip away complexity and add it back later?"
Example:
Options:
If YES: Agent generates Story 1 = simplest core, Story 2+ = variations.
Key insight: Split "make it work" from "make it fast." Non-functional requirements (performance, security, scalability) can follow functional delivery.
Agent asks: "Can you deliver functional value first, then optimize performance/security/scalability later?"
Example:
Options:
If YES: Agent generates Story 1 = functional, Story 2 = optimize.
Key insight: Last resort when uncertainty prevents splitting. Time-box investigation to answer specific questions, then split implementation story with better understanding.
Agent says: "None of patterns 1-8 apply, which suggests high uncertainty. Before splitting, run a spike to reduce uncertainty."
A spike is a time-boxed investigation (not a story), answering questions like:
Agent asks: "What's the biggest unknown preventing you from splitting this epic?"
Options:
Agent recommends: → "Run a 1-2 day spike to answer [question]. After the spike, come back and we'll split the epic with better understanding."
⚠️ Spikes produce learning, not shippable code. After the spike, restart at Pattern 1.
After splitting, evaluate using these criteria:
Agent asks:
1. Does this split reveal low-value work you can deprioritize or eliminate?
2. Does this split produce more equally-sized stories?
If split doesn't satisfy either criterion, try a different pattern.
Across all patterns, follow this sequence:
Strategy shifts based on complexity domain:
Agent asks: "How much uncertainty surrounds this epic?"
Options:
Low uncertainty (Obvious/Complicated domain) — "We know what to build; it's just engineering work" → Find all stories, prioritize by value/risk
High uncertainty (Complex domain) — "We're not sure what customers want or what will work" → Identify 1-2 learning stories ; avoid exhaustive enumeration (work itself teaches what matters)
Chaos — "Everything is on fire; priorities shift daily" → Defer splitting until stability emerges; focus on stabilization first
# Epic Breakdown Plan
**Epic:** [Original epic]
**Pre-Split Validation:** ✅ Passes INVEST (except Small)
**Splitting Pattern Applied:** [Pattern name]
**Rationale:** [Why this pattern fits]
---
## Story Breakdown
### Story 1: [Title] (Simplest Complete Slice)
**Summary:** [User-value-focused title]
**Use Case:**
- **As a** [persona]
- **I want to** [action]
- **so that** [outcome]
**Acceptance Criteria:**
- **Given:** [Preconditions]
- **When:** [Action]
- **Then:** [Outcome]
**Why This First:** [Delivers core value; simpler variations follow]
**Estimated Effort:** [Days/points]
---
### Story 2: [Title] (First Variation)
[Repeat...]
---
### Story 3: [Title] (Second Variation)
[Repeat...]
---
## Split Evaluation
✅ **Does this split reveal low-value work?**
- [Analysis: Which stories could be deprioritized/eliminated?]
✅ **Does this split produce equal-sized stories?**
- [Analysis: Are stories roughly equal in effort?]
---
## INVEST Validation (Each Story)
✅ **Independent:** Stories can be developed in any order
✅ **Negotiable:** Implementation details can be discovered collaboratively
✅ **Valuable:** Each story delivers observable user value
✅ **Estimable:** Team can size each story
✅ **Small:** Each story fits in 1-5 days
✅ **Testable:** Clear acceptance criteria for each
---
## Next Steps
1. **Review with team:** Do PM, design, engineering agree?
2. **Check for further splitting:** Are any stories still >5 days? If yes, **restart at Pattern 1** for that story.
3. **Prioritize:** Which story delivers most value first?
4. **Consider eliminating:** Did split reveal low-value stories? Kill or defer them.
---
**If stories are still too large, re-apply patterns starting at Pattern 1.**
Epic: "Publish blog post (requires editorial review, legal approval, staging)"
Pre-Split Validation: ✅ Passes INVEST
Pattern 1: "Does this have workflow steps?" → YES ✅
❌ Wrong Split (Step-by-Step):
✅ Right Split (Thin End-to-End):
Why this works: Each story delivers full workflow , just with increasing sophistication.
Epic: "Manage user profiles"
Pattern 2: "Does this say 'manage'?" → YES ✅ (signals CRUD)
Split:
Split Evaluation:
Epic: "Flight search with max stops, nearby airports, flexible dates"
Pattern 7: "What's the simplest version?" → Basic search ✅
Split:
Split Evaluation:
Epic: "Checkout flow with discounts (member, VIP, first-time) and payment (Visa, Mastercard, Amex)"
First Pass - Pattern 1 (Workflow): YES ✅
Check Story 2 ("Apply discount"): Still 4 days → Too large, re-split
Second Pass on Story 2 - Pattern 3 (Business Rules): YES ✅
Check Story 3 ("Complete payment"): Still 5 days → Too large, re-split
Third Pass on Story 3 - Pattern 6 (Major Effort): YES ✅
Final Breakdown: 6 stories, all 1-2 days each
Symptom: Jump straight to splitting without checking INVEST
Consequence: Split a story that shouldn't be split (e.g., not Valuable = technical task)
Fix: Always run Step 1 (INVEST check) before Step 2 (splitting patterns)
Symptom: Story 1 = "Editorial review," Story 2 = "Legal approval"
Consequence: Stories don't deliver end-to-end value
Fix: Each story should cover full workflow (thin end-to-end slice), just with increasing sophistication
Symptom: "Story 1: Build API. Story 2: Build UI."
Consequence: Neither story delivers user value
Fix: Vertical slicing—each story includes front-end + back-end to deliver observable user behavior
Symptom: "We'll split by workflow even though there's no sequence"
Consequence: Arbitrary, meaningless split
Fix: If pattern doesn't apply, say NO and continue to next pattern
Symptom: Split epic into 3 stories, but each is still 5+ days
Consequence: Stories too large for sprint
Fix: Restart at Pattern 1 for each large story until all are 1-5 days
Symptom: Split but don't evaluate if it reveals low-value work
Consequence: Miss opportunity to eliminate waste
Fix: After splitting, ask: "Does this reveal work we can kill or defer?"
Humanizing Work recommendation: Teams reach fluency in 2.5-3 hours across multiple practice sessions.
Practice approach:
Don't skip practice work. Skill develops through analyzing past deliverables, not just refining future work.
user-story-splitting.md — The 9 patterns in detailuser-story.md — Format for writing storiesepic-hypothesis.md — Original epic formatSkill type: Interactive Suggested filename: epic-breakdown-advisor.md Suggested placement: /skills/interactive/ Dependencies: Uses user-story-splitting.md, user-story.md, epic-hypothesis.md
Weekly Installs
233
Repository
GitHub Stars
1.5K
First Seen
Feb 12, 2026
Security Audits
Gen Agent Trust HubPassSocketFailSnykPass
Installed on
codex203
opencode201
gemini-cli197
github-copilot196
kimi-cli193
amp193
飞书日程待办摘要工作流:AI自动生成每日/每周开工报告,提升个人生产力
3,100 周安装
Medusa 管理员用户创建指南:使用 new-user Skill 快速配置后台账户
410 周安装
LobeHub桌面端开发指南:基于Electron的桌面应用架构与功能实现教程
410 周安装
精益用户体验画布 (Lean UX Canvas v2) 指南:产品经理假设驱动开发与实验验证工具
411 周安装
iOS StoreKit 2 应用内购买与订阅开发指南 - SwiftUI 实现教程
411 周安装
Sentry AI监控配置指南:追踪LLM调用、智能体执行与令牌消耗
411 周安装
macOS SwiftPM应用打包指南:无需Xcode构建、签名、公证全流程
411 周安装