Rice prioritization
Skill marsloting/product-thinking-pack/skills/rice-prioritization
7 self-contained product-thinking skills that make an AI agent reason like a sharp PM before it acts. MIT.
npx -y skills add marsloting/product-thinking-pack --skill rice-prioritizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply RICE / ICE / WSJF / MoSCoW prioritization frameworks when ranking multiple feature ideas, backlog items, experiments, or initiatives. Use whenever 用户 asks "哪个先做" / "这个值不值得" / "怎么排序" / "优先级排一下" / "rank these" / "should we do X first". Forces explicit scoring on Reach × Impact × Confidence ÷ Effort (RICE) or job size / time-criticality / risk-reduction (WSJF). Stops gut-feel prioritization, forces dimension-by-dimension reasoning, surfaces hidden Confidence assumptions, separates "feels important" from "scores high". Self-contained methodology — no external docs required.
SKILL.md
5.5 KB, as published. Nobody here has run it
RICE / 优先级评分
何时触发
- 用户 列出 ≥ 3 个待办 / 想法 / 实验 / 需求要排序
- "这个先做还是那个先做"类二选一以上
- "这个值不值得做" / "这个需求该不该接"
- backlog grooming / sprint planning 准备阶段
- 老板列了一堆"都很重要"的东西要消化
- 多个团队抢资源时的仲裁需求
何时不触发
- 单一选项是否做 → 用 pre-mortem 做正反推演
- 已有明确数据驱动的 A/B 实验排序 → 用 gtm-ops:growth-engine
- 紧急 hot fix 不需要评分（救火不是优先级问题）
默认框架：RICE（最常用）
RICE Score = (Reach × Impact × Confidence) / Effort
| 维度 | 含义 | 单位 / 范围 |
|---|---|---|
| Reach | 一个时间窗口内会被影响的用户数 | 具体数字（每月触达人数） |
| Impact | 命中后单用户的影响程度 | 3 = 大量影响 / 2 = 高 / 1 = 中 / 0.5 = 低 / 0.25 = 极低 |
| Confidence | 你对前三项估计的自信度 | 100% 高 / 80% 中 / 50% 低 / < 50% 不要做 |
| Effort | 团队投入（person-month） | 具体数字 |
输出：每个候选项一个 RICE 分数，按分数降序排列。不允许只看分数，必须列出 Confidence < 80% 的项哪些假设需要验证。
备选框架（按场景挑）
ICE（轻量版，没 Reach 数据时用）
ICE Score = Impact × Confidence × Ease
适合早期阶段、没 reach 数据、需要快速排序。
WSJF（SAFe 框架，跨团队多 epic 时用）
WSJF = Cost of Delay / Job Size
Cost of Delay = Business Value + Time Criticality + Risk Reduction / Opportunity
适合多 epic 跨团队竞争资源、季度规划、年度路线图。
MoSCoW（产品阶段定义时用）
- Must have：核心价值，没它产品不成立
- Should have：重要但不致命
- Could have：锦上添花
- Won't have（this time）：明确 kill
适合 MVP 范围定义、版本边界划定。
6 步标准流程
- 列候选：把所有要排序的项列清单（写下来，不在脑里）
- 选框架：默认 RICE。没 reach 数据 → ICE。跨 epic → WSJF。MVP 范围 → MoSCoW
- 维度评分：每个项每个维度写具体数字 / 等级，不允许"高/中/低"模糊填
- 算分排序：算出 RICE/ICE/WSJF 分数，降序排列。MoSCoW 直接归类
- 审视 Confidence：所有 Confidence < 80% 的项标"⚠️ 假设需验证"，列具体要验证什么
- 二级决策：分数前 30% 进 do-list；中段 30% 标"等条件"；后 30% 标 kill 或归档
小红线
- 不接受全 100% Confidence：意味着没人在认真估
- 不接受 Reach = 1：单用户级需求要么是 Tier A 战略合作（直接走例外通道），要么不该上 backlog
- Effort 估错优于不估：先填一个数后续调整 > 留空导致整个 RICE 算不出
- Impact = 3 不超过 20%："大量影响"是稀缺信号，不能稀释
模板（Markdown 表格）
| 项目 | Reach | Impact | Confidence | Effort | RICE 分 | 假设需验证 |
|---|---|---|---|---|---|---|
| <项目 1> | 5000/月 | 2 | 80% | 2 | 4000 | - |
| <项目 2> | 1000/月 | 3 | 50% ⚠️ | 1 | 1500 | "用户真的会用"未验证 |
| <项目 3> | 10000/月 | 1 | 100% | 3 | 3333 | - |
排序后给：top 3 do-list / 中段 hold-list / 底部 kill-list。
Anti-Rationalization
| 逃逸路径 | 为什么不行 |
|---|---|
| "凭直觉排个序就行了" | 直觉排序 = 隐藏的"我觉得"。强迫维度拆分会暴露被低估 / 高估的假设 |
| "Reach 没数据就跳过 RICE" | 没 reach 数据用 ICE。完全跳过评分 = 回到 gut-feel = 决策不可追溯 |
| "Confidence 全填 80%" | 80% 是默认偷懒值。必须按具体维度想：reach 数据可信度？impact 估算可信度？effort 估算可信度？三者同 80% 概率极低 |
| "Effort 估不准就不估" | 估不准也要估。估错可调整，不估整张表就废了 |
| "排出来分高的不是我想做的，那 RICE 是错的" | RICE 没错，是你想做的项假设没列清。回 step 5 把"我想做"的真实理由列出来——可能是战略 / 个人偏好 / 老板压力——这些是另外的输入维度，不该让 RICE 背锅 |
| "Impact 全打 3 反映这些都很重要" | Impact = 3 上限是 20% 候选项。全 3 = 没认真区分 = 评分失效 |
| "MoSCoW 比 RICE 简单先用 MoSCoW" | MoSCoW 是 MVP 范围工具不是优先级工具。Must have 之间还要 RICE 排，Could have 也要 RICE 评。框架场景不同 |
关联
- 评分完后下一步：do-list 项进
story-splitting拆故事 →pre-mortem失败推演 - 假设需验证项进
gtm-ops:growth-engine设 A/B 验证 - 大型 epic 用 WSJF 后再往下拆 sprint →
product-management:sprint-planning
Status
v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。