requirement-evallisted

# Requirement Evaluation Skill PM 抛来一个需求，问「值得做吗 / 优先级多高」，本 skill 按步骤分析，产出一份 **评估初稿 + 明确建议（做 / 不做 / 补充信息再定）**。 ## 铁律（先声明，避免糊弄） 1. **先暴露假设**：Reach/Effort 没有真实数据支撑的，**必须写明是估的**，并把 Confidence 压低， 不许用假数字装出高信心。 2. **产出是初稿不是拍板**：结论用「建议」措辞，末尾列出「需核实的数据」。 3. **信息不足先问**：需求描述、目标用户、涉及端缺失时先问，别猜着算。 4. **数据现状决定 Confidence 上限**：product.md「数据现状」写了无真实行为数据的， Reach 靠估 → Confidence ≤50%，并提示"埋点补齐后重估"。 ## 第 0 步：读产品上下文 按 prd-writing skill 目录下的 `PRODUCT-CONTEXT.md` 协议定位 `product.md`，取覆盖端、 产品知识库、数据现状。不存在 → 按协议做首次访谈并落盘（**之后 prd-writing / tracking-plan 直接复用，不再重问**）；有知识库的，评估现状/竞品前先去查。 **未安装 prd-writing（找不到该协议文件）时单独可用**：跳过协议，直接问涉及端、有无真实 行为数据两项，本次会话内用，不落盘。 ## 第 1 步：收集本需求信息（缺就问） - 需求一句话描述 - 来源（用户反馈 / 评审意见 / 竞品 / 数据 / 内部想法）——影响可信度 - 目标用户 & 使用场景 - 涉及端（在 product.md 覆盖端范围内勾选） - 是否有大致工作量预估 ## 第 2 步：KANO 定位（这是哪类需求） 判断落在哪一类，并说明理由： - **基础型**（必备，缺了掉信任）→ 倾向于做，属底线 - **期望型**（越好越满意）→ 看竞争态势和 RICE 分 - **兴奋型**（惊喜、差异化）→ 结合战略，可能值得为它赌一把 - **无差异型**（有没有无所谓）→ 倾向不做 - **反向型**（做了招人烦）→ 建议砍掉 定位时结合产品定位（product.md 一句话定位）：同一个功能在工具型产品是基础型， 在内容型产品可能是无差异型——别脱离产品谈 KANO。 ## 第 3 步：RICE 打分（能排序） 逐项给值 + 依据，算 `(Reach × Impact × Confidence) ÷ Effort`： | 因子 | 取值 | 依据/假设 | |------|------|-----------| | Reach | ? | 从哪估的，有没有真实数 | | Impact | 3/2/1/0.5/0.25 | 为什么这档 | | Confidence | %-数 | 数据支撑程度（受 product.md 数据现状约束） | | Effort | ?人月 | 谁的估计 | ## 第 4 步：综合建议 把 KANO 定位和 RICE 分放一起给结论： - **明确建议**：值得做 / 暂不做 / 补数据再定 / 拆小做一部分 - **理由**：一句话说清为什么 - **建议排期**：进哪个版本 / 放需求池观察 - **需核实的数据**：列出���确认的假设（尤其 Reach 和 Effort） ## 第 5 步：输出为需求池可用的一行 最后给一行能直