| name | openprd-requirement-intake |
| description | OpenPrd 需求入口与 PRD 分流 skill：判断用户可见需求类型和内部 L0/L1/L2 路由码，决定直接澄清、mini-plan 或正式 PRD，并选择通用 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景的 PRD 视角。对用户复述时不要直接把 consumer / b2b / agent 当展示词；这些枚举值只用于内部记录和命令。 |
OpenPrd Requirement Intake
作用
这份 skill 只做需求入口分流，不负责实现代码。
- 判断当前用户输入的用户可见需求类型和内部 L0/L1/L2 路由码
- 决定下一步是直接澄清、mini-plan，还是正式 PRD
- 为 L2 选择通用、面向个人消费者场景、面向企业服务场景或以 Agent 为主要使用场景的 PRD 视角；
base/consumer/b2b/agent 只用于内部记录和命令
- 把用户当前需求和历史 active change 分开，避免“继续任务”吞掉新范围
- 给
$openprd-harness 输出下一步行动合同
分流原则
不要按关键词判断。按影响面、未知数、决策成本和验证成本判断。
如果用户明确说“帮我梳理下”“先想清楚”“进入脑暴模式”，或需求只有一句话但明显需要先收敛业务方向、用户、商业目标、竞品和复用能力，必须先进入脑暴模式，不要直接压进 PRD，也不要先拿一版 requirement 摘要代替脑暴产物。默认使用：
openprd brainstorm . --topic <当前主题> --open- 如需让 Agent 先提炼展示文案，再补
openprd brainstorm-presentation . --template
脑暴模式是独立 lane，不等于普通 clarify：
- 目的不是只补字段，而是先判断值不值得做、给谁做、为什么现在做、有哪些方向、当前工作区能复用什么。
- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、你为什么算这个社区里的自己人、现在怎么解决、当前 workaround 到底有多痛、如果先不做完整产品怎么手工交付、能否先用 spreadsheet 或 no-code 跑起来、什么真实承诺最能证明不是口头兴趣、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、先怎么低成本验证、验证阶段怎样先活下来，以及什么情况下先停。
- 资料来源默认同时包含 benchmark、knowledge、当前工作区文档/代码和开放问题。
- 如果用户能提供更大的工作区或历史项目目录，优先一起扫描可复用能力、旧流程和已有产品做法。
- 用户没有明确要求时，Agent 只能“建议进入脑暴模式”，不能静默切换。
- 用户认可脑暴方向后，再回到
capture -> classify -> synthesize -> review -> change -> tasks。
| 用户可见需求类型 | 内部路由码 | 判断含义 | 默认处理方式 |
|---|
| 直接处理 | L0 | 单点、低风险、可逆、验收清楚 | 可以直接处理并事后说明 |
| 现有功能优化 | L1 | 目标明确，但影响多个文件、状态或用户可见行为 | 先给对话内 mini-plan，再执行 |
| 新功能/新流程方案 | L2 | 新产品、模块、入口、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清 | 先走 PRD/review/change/tasks |
用户审查时优先把路由码并进“需求类型：直接处理（L0）”这类标签里，不要把内部调度码单独抬成标题。只有审查或调试真的受益时，才额外补“内部路由码：L1”这类信息，并保留上面的对照关系。
用户侧表达优先使用“面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景”这类自然语言，不要把 consumer、b2b、agent 直接当展示词抛给用户。
界面、页面、视觉、样式或前端体验需求需要额外判断 UI 影响面。若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选择设计方向，即使属于“现有功能优化”，也要先走“大界面改动视觉方案评审”：已有界面时用 Computer Use 截取当前产品内功能截图，冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 imagegen（Codex 原生 Image 2）生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。
工作流
- 读取
.openprd/ 状态和 openprd run . --context，但把它当作建议。
- 用
references/routing-rubric.md 判断 L0/L1/L2。
- 如果是 L2，读取
references/prd-template-lenses.md 选择 PRD 场景视角。
- 输出一个短的需求类型判断：
- 先总后分，优先按下面结构在对话里给用户看：
- 需求判断：需求类型（默认写成
直接处理（L0） / 现有功能优化（L1） / 新功能/新流程方案（L2））/ 产品类型 / 推荐下一步
- 只有内部排障真的受益时，才额外补一行“内部路由码”
- 需求理解：主要服务对象 / 使用场景 / 第一版先做什么 / 这轮先不做什么 / 必须守住什么
需求判断 和 需求理解 先用 1 到 2 句轻量主句说清“这次是什么 / 核心问题是什么 / 第一版先做到什么”；能一句话说清就不要写两句话。范围边界、风险边界、异常例子和技术细节下沉到后面的分项或表格，不要全塞进同一整段长话里。- 如果需求理解里同时出现多个角色、路径、状态、前后对比、风险传播或取舍关系，优先补一张解释型 SVG 图来承载结构；图后只保留必要结论、开放问题和下一步。
- 这里沉淀的是表达风格，不是固定示例文案；要根据本次内容自适应生成，不要机械套同一句模板。
- 功能范围：优先用 Markdown 表格写
功能模块 | 这次先做什么 | 这次先不做什么
- 技术方案：优先用 Markdown 表格写
技术部分 | 初步方案 | 主要负责什么；涉及前端、后端、Agent、数据或集成时，按用户能看懂的功能视角拆开
- L2 时补充 PRD 场景视角：通用场景 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景
- 把执行交回
$openprd-harness。
输出合同
L0
- 直接处理或问 1 个必要问题。
- 不生成 PRD。
- 完成后说明变更和验证。
L1
- 给 3-5 行 mini-plan。
- 明确范围内、范围外和验证方式。
- 默认先用业务/产品语言复述需求，再只追问 1 个最高价值问题；不要上来抛技术字段墙。
- 若是大界面改动，mini-plan 之后先做 3 方向效果图评审，用户确认方向后再实现。
- 用户已明确要求执行时可继续实现。
- 不生成正式 PRD，除非 mini-plan 暴露出新的决策缺口。
L2
- 如果用户明确要梳理、先想清楚、进入脑暴模式，或这句话明显还需要先收敛业务方向，先运行或建议
openprd brainstorm . --topic <当前主题> --open，不要只在对话里先给一版 requirement 摘要代替脑暴模式。
- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点强度、手工交付路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、初始收费假设、客户 1 盈利路径、10 个样本和付费验证信号、达到什么条件才允许产品化、default alive 约束、增长纪律、可逆性、客户真问题判断和价值观一致性（是不是你愿意长期住进去的业务形态），再补核心诉求、推荐方向、关键角色和复用基础。
- 进入脑暴模式后，至少要形成
brainstorm.html 这类可继续评审和推进的产物，再基于产物追问或收口。
- 其他 L2 默认先运行或建议
openprd clarify .。
- 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、你为什么算这个社区里的自己人、用户现在怎么解决、这个 workaround 到底有多痛、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、验证阶段怎样先活下来，以及这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态”。
- 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
需求判断 和 需求理解 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。- 如果 L2 摘要正在解释新流程、新角色关系、状态机、前后方案差异、依赖边界或失败恢复路径，先用解释型 SVG 图降低理解成本，再用表格承接范围和技术分工。
- 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
- 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
- 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、
capture/classify/synthesize 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
- 用户侧表达优先使用业务和产品语言，强调谁在什么场景下解决什么问题、会获得什么收益、要承担什么业务风险；避免过早暴露前端/后端/数据库这类技术黑话。
- 使用
openprd capture . --field ... 只写回已确认事实；agent-normalized 仅用于无语义变化的内部措辞整理，不替代用户确认。
- 选择并记录产品类型：
openprd classify . <consumer|b2b|agent>；无法判断时保持 base。
- requirement 摘要确认后，再进入
openprd classify .、openprd synthesize .、review artifact、change 和 tasks。
PRD 场景视角
base：通用产品或工程场景，强调问题、目标、首轮项目画像、范围、流程、需求矩阵、验收和风险。- 内部
consumer：面向个人消费者场景，强调用户旅程、首次成功、激活、留存、情绪价值和增长指标。
- 内部
b2b：面向企业服务场景，强调买方/使用者/管理员/运营者、权限矩阵、审批审计、集成依赖、SLA 和上线支持。
- 内部
agent：以 Agent 为主要使用场景，强调 Human-Agent contract、自主边界、工具边界、状态模型、失败恢复和评估计划。
模板视角应融入正文结构，不要作为 PRD 末尾的字段附录。比如企业服务场景的角色、权限和审批应该贯穿用户、流程、需求矩阵和验收标准；Agent 场景的自主边界应该贯穿范围、风险、任务和验证。
何时读取参考
- 分流有争议、用户输入很长、或涉及“继续旧任务 + 新范围”时，读
references/routing-rubric.md。
- 需要写 PRD、选择产品场景、或用户反馈 PRD 结构奇怪时，读
references/prd-template-lenses.md。
- 需要把 L2 或脑暴收口成更强的创业验证链时，读
references/startup-validation-lens.md。
