solution-scoping

用途

Solution Scoping 用于在产品开发启动前，基于问题定义和用户模型对功能进行优先级排序，并划定 MVP（最小可行产品）边界。其核心理念是：在开发开始前砍功能成本最低，因此应在此阶段强制做出艰难的取舍决策。

上下文收集：接收上游产物（问题陈述、JTBD、假设、人物角色、场景、洞察），或直接询问用户正在解决的问题、目标用户、考虑的功能及约束条件（时间、预算、技能）。
功能清单生成：若用户未提供功能列表，则基于用户待办任务、人物角色痛点、用户建模场景及已知竞品功能进行头脑风暴，初期保持穷尽，后续再裁剪。
优先级排序：应用一种或多种框架强制排名：
- 影响-工作量矩阵：高影响低工作量→优先做；高影响高工作量→谨慎规划；低影响低工作量→可能稍后；低影响高工作量→砍掉。
- MoSCoW 方法：Must have（没有产品无法运作）、Should have（重要但非关键）、Could have（锦上添花）、Won't have（明确排除）。
- 用户价值过滤器：每个功能需回答是否解决核心问题、哪个角色最需要、不发布会怎样。
MVP 边界定义：明确首个版本包含什么、推迟到 v1.1 什么、完全砍掉什么。MVP 应是能测试核心假设的最小事物。
取舍验证：对每个被砍功能确认：产品是否仍能解决核心问题、用户是否仍能获得价值、砍掉是出于合理原因还是恐惧。

该技能以工作流方式运行，依次执行五个步骤：收集上下文、生成功能清单、应用优先级排序、定义 MVP 边界、验证取舍。输出自动保存至 design/04-solution-scoping.md，同时呈现给用户。输出文档包含以下结构：

上下文：问题与目标用户摘要、待测试的核心假设、约束条件（时间线、预算、技能、其他）。
功能清单：所有考虑的功能表格，含用户价值、工作量、备注。
优先级分类：Must Have（MVP）、Should Have（v1.1）、Could Have（未来）、Won't Have（砍掉），各附理由与依赖关系。
MVP 定义：构建内容描述、核心用户流程、成功标准、明确不构建的内容。
风险检查：可能造成伤害的取舍及缓解措施、范围蔓延触发点。
待解决问题：仍需决策的事项、提交前需验证的假设。

完成后会询问是否使用 /prd-generation 生成 PRD，或先调整优先级。Must Have 对应 MVP 功能，Should Have 对应 v1.1 路线图，Won't Have 对应范围外内容。