ln-230-story-prioritizer

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

故事优先级排序

类型： L3 Worker
类别： 2XX Planning

使用 RICE 评分结合市场调研评估故事。生成 Epic 的汇总优先级排序表。

目的与范围

• 在 ln-220 创建故事后对其进行优先级排序
• 在开展深入调研前，先对所有故事进行低成本分诊
• 仅在市场规模和竞争情况会影响优先级判断信心时进行调研
• 计算每个故事的 RICE 分数
• 生成优先级排序表（P0/P1/P2/P3）
• 输出：docs/market/[epic-slug]/prioritization.md

适用场景

在以下情况下使用此技能：

• ln-220 已创建故事，需要进行业务优先级排序
• 规划冲刺，但产能有限（哪些故事应优先处理？）
• 利益相关者评审需要数据驱动的优先级
• 在实施前评估功能 ROI

以下情况不要使用：

• Epic 尚无故事（先运行 ln-220）
• 故事纯属技术工作（基础设施、重构）
• docs/market/ 中已有优先级排序结果

---

输入参数

参数	必填	说明	默认值
epic	是	Epic ID 或“Epic N”格式	-
stories	否	要进行优先级排序的特定 Story ID	Epic 中的全部故事
depth	否	调研深度（quick/standard/deep）	"standard"

depth 选项：

• quick - 每个故事 2-3 分钟，每种类型进行 1 次 WebSearch
• standard - 每个故事 5-7 分钟，每种类型进行 2-3 次 WebSearch
• deep - 每个故事 8-10 分钟，进行全面调研

---

输出结构

docs/market/[epic-slug]/
└── prioritization.md    # Consolidated table + RICE details + sources

运行时约定

必须读取： 加载 references/planning_worker_runtime_contract.md、references/coordinator_summary_contract.md
必须读取： 当故事引用 H/G/run ID，或项目中的 researchgraph 证据可能影响优先级判断信心时，加载 references/researchgraph_mcp_usage.md。

运行时系列：planning-worker-runtime

标识符：

• epic-{epicId}

阶段：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_LOAD_STORY_METADATA
4. PHASE_3_ANALYZE_STORIES
5. PHASE_4_GENERATE_PRIORITIZATION
6. PHASE_5_WRITE_SUMMARY
7. PHASE_6_SELF_CHECK

摘要约定：

• summary_kind=story-prioritization-worker
• payload 包含 epic_id、depth、stories_analyzed、priority_distribution、top_story_ids、prioritization_path、warnings
• 托管模式写入调用方提供的 summaryArtifactPath
• 默认托管产物路径模式：.hex-skills/runtime-artifacts/runs/{parent_run_id}/story-prioritization-worker/ln-230--{identifier}.json

表格列（来自用户要求）：

优先级	客户问题	功能	解决方案	理由	影响	市场	来源	竞争
P0	用户痛点	故事标题	技术方案	重要原因	业务影响	$XB	[链接]	Blue 1-3 / Red 4-5

---

输入

输入	必填	来源	说明
epicId	是	args、kanban、用户	要处理的 Epic

解析： Epic 解析链。 状态筛选： 活跃（planned/started）

工具配置

必须读取： 加载 references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md

提取：task_provider = Task Management → Provider

调研工具

工具	用途	示例查询
WebSearch	市场规模、竞争对手	"[domain] market size {current_year}"
mcp__Ref	行业报告	"[domain] market analysis report"
hex-research	本地假设、目标和基准证据	对明确的 H/G/run 上下文使用 find_hypotheses、inspect_goal、find_runs
任务提供方	加载故事	若为 linear：list_issues / 否则：Glob story.md
Glob	检查现有内容	"docs/market/[epic]/*"

---

工作流

阶段 1：发现（2 分钟）

目标： 验证输入并准备上下文。

流程：

1. 解析 epicId： 按照指南运行 Epic 解析链。

2. 加载 Epic 详情：

   • 如果 task_provider == "linear"： get_project(query=epicId)
   • 否则如果 task_provider == "github"： gh issue view {epicId} -R {REPO} --json number,title,body
   • 否则： Read("docs/tasks/epics/epic-{N}-*/epic.md")
   • 提取：Epic ID、标题、描述

3. 自动发现配置：

   • 读取 docs/tasks/kanban_board.md 获取 Team ID
   • 将 Epic 标题转换为 slug，作为输出路径

4. 检查是否已有优先级排序：

   Glob: docs/market/[epic-slug]/prioritization.md
   

   • 如果存在：询问“更新现有内容还是新建？”
   • 如果是新建：继续

5. 创建输出目录：

   mkdir -p docs/market/[epic-slug]/
   

输出： Epic 元数据、输出路径、现有内容检查结果

---

阶段 2：加载 Story 元数据（3 分钟）

目标： 仅使用元数据构建 Story 队列，并为所有 Story 准备粗略评分输入。

流程：

1. 从 Epic 查询 Story： 如果 task_provider == "linear"：

   list_issues(project=Epic.id, label="user-story")
   

   否则如果 task_provider == "github"：

   gh api /repos/{O}/{R}/issues/{epic_num}/sub_issues --jq '.[].number'
   → for each: gh issue view {num} -R {REPO} --json number,title,state,labels
   → filter: label "user-story"
   

   否则（文件模式）：

   Glob("docs/tasks/epics/epic-{N}-*/stories/*/story.md")
   

2. 仅提取元数据：

   • Story ID、标题、状态
   • 可用的最少 Epic 上下文
   • 暂不加载完整描述

3. 筛选 Story：

   • 排除：已完成、已取消、已归档
   • 包含：待办、待处理、进行中

4. 构建处理队列：

   • 排序依据：现有优先级（如有），然后按 ID 排序
   • 计数：待处理的 N 个 Story

输出： Story 队列（ID + 标题 + 最少上下文），每个 Story 约 50-80 个 token

---

阶段 3：两轮 Story 分析

目标： 先以较低成本为所有 Story 评分，然后只对可能改变决策的候选项进行深入研究。

重要： 即使在深入研究期间，也要将上下文限制为一次只包含一个完整 Story。

如果存在 researchgraph 布局，仅对优先级取决于假设状态、目标覆盖范围、基准证据或实现准备度的 Story 运行本地图检查。本地图证据可以改变 RICE 置信度和风险，但不能替代市场规模或竞争对手研究。

第一轮：对所有 Story 进行低成本初筛

对于每个 Story，仅加载足够的信息来估算：

• 客户问题
• 大致解决方案
• 可能的覆盖范围
• 可能的影响
• 可能的工作量
• 初始置信度等级

步骤 3.1：加载 Story 描述

如果 task_provider == "linear"：

// configured tracker provider: getStory(id=storyId)

否则如果 task_provider == "github"：

gh issue view {storyId} -R {REPO} --json number,title,body,state,labels

否则（文件模式）：

Read("docs/tasks/epics/epic-{N}-*/stories/us{NNN}-*/story.md")

从 Story 中提取：

• 功能： Story 标题
• 客户问题： 来自“这样就能 [价值]”和上下文部分
• 解决方案： 来自技术说明（实现方案）
• 理由： 来自 AC 和成功标准

步骤 3.2：构建粗略的 RICE 估算

使用 Story + Epic 上下文，估算：

• 粗略的 Reach
• 粗略的 Impact
• 粗略的 Effort
• 初始 Confidence

标记为以下其中一项：

• full_research_required
• rough_estimate_ok
• borderline_needs_review

仅在以下情况下转入第二轮：

• 粗略评分显示候选项可能属于 P0/P1
• 置信度较低
• Story 接近优先级阈值
• Story 存在战略性或对市场敏感的不确定因素

第二轮：有选择地进行深入研究

仅对第一轮选中的 Story 进行完整的外部研究。

步骤 3.3：研究市场规模

WebSearch 查询（依据研究深度）：

"[customer problem domain] market size TAM {current_year}"
"[feature type] industry market forecast"

mcp__Ref 查询：

"[domain] market analysis Gartner Statista"

提取：

• 市场规模：$XB（单位：B = 十亿，M = 百万）
• 增长率：X% CAGR
• 来源：URL + 日期

置信度映射：

• 行业报告（Gartner、Statista）→ 置信度 0.9-1.0
• 新闻文章 → 置信度 0.7-0.8
• 博客/论坛 → 置信度 0.5-0.6

步骤 3.4：研究竞争情况

WebSearch 查询：

"[feature] competitors alternatives {current_year}"
"[solution approach] market leaders"

统计竞争对手并分类：

发现的竞争对手数量	竞争指数	市场类型
0	1	蓝海
1-2	2	新兴
3-5	3	成长
6-10	4	成熟
>10	5	红海

步骤 3.5：计算最终 RICE 分数

RICE = (Reach x Impact x Confidence) / Effort

触达人数（1-10）： 每季度受影响的用户数

分数	用户数	指标
1-2	<500	小众，面向单一角色
3-4	500-2K	部门级
5-6	2K-5K	覆盖整个组织
7-8	5K-10K	覆盖多个组织
9-10	>10K	覆盖整个平台

影响力（0.25-3.0）： 业务价值

分数	级别	指标
0.25	极小	可有可无
0.5	低	生活质量提升
1.0	中	效率提升
2.0	高	营收驱动因素
3.0	极大	战略差异化优势

置信度（0.5-1.0）： 数据质量（来自步骤 3.2）

数据置信度评估：

针对每个 RICE 因素，评估数据置信度：

置信度	标准	分数调整
高	多个权威来源（Gartner、Statista、SEC 文件）	因素按原值使用
中	1-2 个来源，质量参差不齐（博客 + 报告）	显示因素 ±25% 的范围
低	没有来源，仅为团队估算	显示因素 ±50% 的范围

输出： 在优先级表中显示每个因素的置信度，以及 RICE 范围（乐观/悲观），明确呈现不确定性。

工作量（1-10）： 人月

分数	时间	Story 指标
1-2	<2 周	3 个 AC，简单 CRUD
3-4	2-4 周	4 个 AC，集成
5-6	1-2 个月	5 个 AC，复杂逻辑
7-8	2-3 个月	外部依赖
9-10	3+ 个月	新基础设施

步骤 3.6：确定优先级

优先级	RICE 阈值	竞争情况调整
P0（关键）	>= 30	或竞争情况 = 1（蓝海垄断）
P1（高）	>= 15	或竞争情况 <= 2（新兴市场）
P2（中）	>= 5	-
P3（低）	< 5	竞争情况 = 5（红海）时强制设为 P3

步骤 3.7：存储并清理

• 将行追加到内存结果表
• 标记该行属于 full-research 还是 rough-estimate
• 从上下文中清除 Story 描述
• 转到队列中的下一个 Story

每个 Story 的输出： 包含置信度等级的优先级表完整行

---

第 4 阶段：生成优先级表（5 分钟）

目标： 创建汇总的 Markdown 输出。

流程：

1. 对结果排序：

   • 主要排序：优先级（P0 → P3）
   • 次要排序：RICE 分数（降序）

2. 生成 Markdown：

   • 使用 references/templates/prioritization_template.md 中的模板
   • 填写：优先级摘要、主表、RICE 详情、来源
   • 明确标示每个 Story 使用的是完整研究还是粗略估算

3. 保存文件：

   Write: docs/market/[epic-slug]/prioritization.md
   

输出： 已保存的 prioritization.md

---

第 5 阶段：总结与后续步骤（1 分钟）

目标： 展示结果和建议。

输出格式：

## Prioritization Complete

**Epic:** [Epic N - Name]
**Stories analyzed:** X
**Time elapsed:** Y minutes

### Priority Distribution:
- P0 (Critical): X Stories - Implement ASAP
- P1 (High): X Stories - Next sprint
- P2 (Medium): X Stories - Backlog
- P3 (Low): X Stories - Consider deferring

### Top 3 Priorities:
1. [Story Title] - RICE: X, Market: $XB, Competition: Blue/Red

### Saved to:
docs/market/[epic-slug]/prioritization.md

### Next Steps:
1. Review table with stakeholders
2. Run ln-300 for P0/P1 Stories first
3. Consider cutting P3 Stories

---

时间限制

深度	每个 Story	总计（10 个 Story）
快速	2-3 分钟	20-30 分钟
标准	5-7 分钟	50-70 分钟
深入	8-10 分钟	80-100 分钟

时间管理规则：

• 如果 Story 超出时间预算：保留粗略估算，并标记较低置信度
• 如果总时间超出预算：仅对高潜力或优先级临界的 Story 进行深入研究
• 尽可能并行执行 WebSearch（市场 + 竞争情况）

---

Token 效率

加载模式：

• 第 2 阶段：仅加载元数据（每个 Story 约 50 个 token）
• 第 3 阶段：逐个加载完整描述（每个 Story 约 3,000-5,000 个 token）
• 每个 Story 完成后：清除描述，仅保留结果行（约 100 个 token）

内存管理：

• 顺序处理（不并行）
• 上下文上限：一次仅保留 1 个 Story 描述
• 结果以紧凑的表格行累积

---

与生态系统的集成

在工作流中的位置：

ln-210 (Scope → Epics)
     ↓
ln-220 (Epic → Stories)
     ↓
ln-230 (RICE per Story → prioritization table) ← THIS SKILL
     ↓
ln-300 (Story → Tasks)

依赖项：

• WebSearch、mcp__Ref（市场调研）
• 任务提供方：根据 references/tracker_provider_contract.md 配置的跟踪器提供方（加载 Epic、Stories）
• Glob、Write、Bash（文件操作）

下游用法：

• Sprint 规划使用 P0/P1 筛选 Stories
• ln-300 按优先级顺序处理 Stories
• 实施前由利益相关者审查

结构化工作器输出：

• 即使在独立模式下，也要返回优先级排序摘要信封
• 提供 summaryArtifactPath 时，写入相同的 JSON 文件

---

关键规则

1. 先进行分类 - 在深入调研前，对所有 Stories 进行低成本评分
2. 为所有深入调研数据注明来源 - 每个市场数据都需要来源和日期
3. 优先使用近期数据 - 最近 2 年的数据；如数据更早，请发出警告
4. 在深入调研有充分依据时进行交叉参考 - 对市场敏感型 Story 使用 2 个以上来源
5. 严格限制时间 - 如果深入调研不会改变决策，则保留粗略估算
6. 置信度等级 - 标记为高/中/低，并注明评分是粗略评分还是完整调研评分
7. 不做推测 - 仅陈述有来源支持的内容，对缺失项注明「[无数据]」
8. 一次处理一个 Story - Token 效率至关重要
9. 保留语言 - 如果用户用俄语提问，则用俄语回复

---

完成定义

• 通过配置的跟踪器提供方验证 Epic
• 通过元数据优先队列加载所有 Stories
• 完成所有 Stories 的 A 阶段粗略分类
• 深入调研仅限于高潜力或低置信度的 Stories
• 为每个 Story 计算 RICE 分数
• 分配竞争指数（1-5）
• 分配优先级（P0/P1/P2/P3）
• 在输出中展示置信度等级和调研深度
• 表格按优先级 + RICE 排序
• 文件保存至 docs/market/[epic-slug]/prioritization.md
• 提供包含最高优先级事项和后续步骤的摘要
• 返回结构化的 story-prioritization-worker 摘要
• 提供 summaryArtifactPath 时写入摘要文件
• 总耗时在预算范围内

---

示例用法

基本用法：

ln-230-story-prioritizer epic="Epic 7"

带参数：

ln-230-story-prioritizer epic="Epic 7: Translation API" depth="deep"

指定 Stories：

ln-230-story-prioritizer epic="Epic 7" stories="US001,US002,US003"

输出示例（docs/market/translation-api/prioritization.md）：

优先级	客户问题	功能	解决方案	理由	影响	市场	来源	竞争
P0	「重复翻译会产生 GPU 成本」	翻译记忆库	Redis 缓存，5ms 查询	GPU 成本降低 70-90%	高	$2B+	M&M	3
P0	「无法翻译 PDF」	PDF 支持	PDF 解析 + 布局	企业级阻碍	高	$10B+	Eden	5
P1	「需要视频字幕」	SRT/VTT 支持	保留时间信息	蓝海机会	中	$5.7B	GMI	2

---

第 6 阶段：元分析

可选参考：仅当用户要求运行后元分析或按协议格式进行运行复盘时，才加载 references/meta_analysis_protocol.md。

技能类型：planning-worker。收到请求时，在所有阶段完成后运行。使用 planning-worker 格式在聊天中输出。

参考文件

• 必须阅读： 加载 references/environment_state_contract.md
• 必须阅读： 加载 references/storage_mode_detection.md
• 必须阅读： 加载 references/research_tool_fallback.md

文件	用途
prioritization_template.md	输出 Markdown 模板
rice_scoring_guide.md	RICE 因素等级和示例
research_queries.md	按领域分类的 WebSearch 查询模板
competition_index.md	蓝海/红海分类规则

---

版本： 2.0.0 最后更新： 2026-04-05