ris-prioritize

ris-prioritize 属于 Personal Corp 框架，该框架的目标是通过 AI 智能体运营一人公司。本技能用于对需求列表进行结构化排序，核心思路是：用明确的框架打分，让每个分数都有依据，团队可以针对分数争论，而不是针对最终建议争论。

用途与输入

输入包括：需求列表（必填，至少 3 项，每项含名称和简要描述，可来自反馈分析技能输出的痛点列表或 PRD 技能输出的功能列表）；框架（可选，RICE、ICE、MoSCoW、Kano，未指定时自动推荐）；业务目标（可选，如增长、留存、收入、效率，影响权重）；资源约束（可选，可用开发容量，以人天或 Story Point 计）。

可选配置

多数场景开箱即用。若希望跨多次运行保持默认值，可在项目的 CLAUDE.md 中添加 ## Ris Prioritize Config 段，配置默认框架、默认资源约束（如 sprint_capacity: 20 person-days per Sprint）和待办来源（gh-issues、github-project、tasks-file、paste，并附 gh_owner、gh_repo、gh_label、tasks_file 等字段）。配置项已设置时技能静默使用，未设置时会询问。

当用户指向待办来源而非直接粘贴条目时，技能可通过 gh issue list、gh project item-list 或读取本地待办文件自行拉取列表。

第一步：选择框架

未指定框架时按下表推荐：有可信的用户影响数据（DAU、转化率）选 RICE，最量化、可追溯；有直觉但无精确数据选 ICE，评分快、容忍主观性；需要快速达成四桶共识（如团队会议）选 MoSCoW；需要理解需求性质、规划功能选 Kano，识别惊喜型功能。

各框架特点：RICE 适合数据支撑的季度规划，最客观可比，但依赖数据质量，耗时中等；ICE 适合快速决策和头脑风暴，简单快速但高度主观，耗时低；MoSCoW 适合发布规划和干系人对齐，强制共识，但容易把一切都放进 Must，耗时低；Kano 适合功能规划和满意度研究，能识别惊喜功能，但需要用户调研数据，耗时高。

第二步：评分

RICE 维度包括 Reach（一个周期内受影响用户数，需具体数字）、Impact（单用户影响幅度：3 巨大、2 高、1 中、0.5 低、0.25 极小）、Confidence（100% 有数据、80% 间接证据、50% 凭直觉）、Effort（跨角色总人月，须含设计、开发、QA、集成）。RICE 分数 = (R×I×C)/E，越高越优先。技能含校准机制：先对所有条目评同一维度再评下一维度，避免锚定偏差；Reach 选基线相对评分；Impact 最多 50% 条目可打 3 分以强制区分；Effort 须含设计 20%、开发 50%、QA 20%、集成 10%。

ICE 各维度打 1-10 分，ICE 分数 = I×C×E/10。Impact 1 微不足道、5 中等、10 变革性；Confidence 1 纯猜测、5 间接证据、10 A/B 测试数据；Ease 1 很难（超 3 个月）、5 中等（2-4 周）、10 极简（少于 1 天）。

MoSCoW 分四桶：Must Have（不满足无法发布，建议占比不超过 60%）、Should Have（重要但有替代方案，约 20%）、Could Have（锦上添花，约 10%）、Won't Have this time（明确不在本期范围，约 10%）。常见陷阱是全部变成 Must，需以 60% 上限强制取舍。

Kano 分五类：Must-be（缺失导致不满，存在被视为理所当然，及格即可，勿过度投入）、One-dimensional（越多越满意，用户主动要求，核心竞争区）、Attractive（缺失无不满，存在带来惊喜，差异化来源）、Indifferent（无所谓，不投入）、Reverse（存在反而降低满意度，立即移除）。Kano 有衰减效应：今天的 Attractive 功能在 2-3 年内会变为 One-dimensional 再变为 Must-be（如指纹解锁），需持续创造新的惊喜点。

第三步：输出排序

包括 RICE 结果表（排名、需求、R、I、C、E、分数、建议）、影响×投入 2×2 矩阵（Quick Wins 高影响低投入先做；Strategic 高影响高投入审慎规划；Fill-ins 低影响低投入空闲时做；Avoid 低影响高投入不做）、Sprint 分配（按 sprint_capacity 或声明的资源约束分配；Quick Wins 优先填充，Strategic 按 RICE 分数排；每 Sprint 预留 10-20% 应对突发工作）。

第四步：决策日志

记录核心取舍（本期为何选 A 而非 B）、有争议的条目及原因、置信度标记（C 低于 80% 的分数提出验证实验）、下期候选（最可能在下期提升的 Won't-Have 条目）。

质量标准与红线

每个分数附一句理由；Effort 含设计、开发、QA、集成；C 低于 80% 的条目标注“通过小实验验证”；Must Have 不超过总数 60%；应用校准机制避免锚定。红线：技能不是决策者，输出仅为建议，最终决定由团队做出；不得有隐藏假设，每个分数的假设须显式；绝不忽略 Effort，不得仅凭 Impact 就建议“必须做”。

输入不完整时

未提供待办来源时询问清单位置（粘贴、文件路径或 GitHub issues 过滤条件）；未提供业务目标时询问本期焦点（增长、留存、收入、效率）；未提供资源约束时询问可用容量；框架未设置时不询问，按第一步决策表自动推荐并附一句理由，由用户确认或覆盖；需求少于 3 项仍排序，但标注“样本过小，建议补充以提高稳定性”；完全无数据时改用 ICE 或 MoSCoW，并标注“因缺少定量数据采用定性排序”。

技能介绍