| name | prototype-orchestrator-pro |
| description | 将口语化需求、会议纪要、聊天记录或半结构化需求文档编排为可交互的单文件 HTML 产品原型。用于”帮我做原型””把需求变成界面””根据会议纪要出后台页面””做个低保真/中保真页面””prototype from requirements””convert notes to UI”等场景；先归一需求，再输出 ProductSpec、页面方案与 frontend-design 渲染指令。 |
Prototype Orchestrator Pro
把模糊需求转成可评审、可渲染的原型规格，而不是只列功能点。
按阶段工作
只在当前阶段读取必要资源，避免一次性加载全部上下文。
- 识别输入类型和输出模式。
- 读取
references/input-normalization.md。
- 将输入识别为：口语化需求、会议纪要、半结构化需求、目标导向型需求、需求文档。
- 用户只说“先看效果”“先出图”“不用解释太多”时，切换到快速模式。
- 建立产品规格。
- 读取
references/prototype-spec-schema.md。
- 选择视觉预设时，再读取
references/design-presets.md。
- 展开页面和交互。
- 需要具体交互时，读取
references/interaction-recipes.md。
- 生成渲染交接。
- 读取
references/rendering-prompt-template.md（已包含渲染规范）。
- 需要骨架时，再读取
assets/prototype-template.html。
- 只在此阶段读取
frontend-design skill。
- 结束前自检。
需要校准输出风格时，再读取 examples/meeting-notes-to-prototype.md。
坚持这些原则
- 先归一事实，再做页面。
- 先定义角色、任务、页面树和状态，再做视觉。
- 把补全内容标记为
[默认推断]，不要伪装成已确认需求。
- 除非缺失会改变产品方向，否则不要频繁追问。
- 永远输出页面、动作、状态和跳转，不要只输出模块名。
选择运行模式
快速模式
在用户更看重“先看到效果”时使用。
输出：
[需求解析摘要（压缩版）][页面设计方案][原型渲染指令]
规则：
- 只保留主链路。
- 默认先做 1 个总览页 + 1 个列表页 + 1 个详情层。
- 默认先渲染 P0，再补 P1。
专业模式
在用户需要需求梳理、方案评审或多角色页面结构时使用。
按顺序输出：
[需求解析摘要][产品建模结果][页面设计方案][原型渲染指令]
产出每个阶段
产出 [需求解析摘要]
提取并整理：
- 产品方向
- 目标用户
- 业务目标
- 关键对象
- 已确认事实
[默认推断]- 待确认项（最多 5 条，只保留高影响项）
会议纪要额外提炼：
产出 [产品建模结果]
严格按 references/prototype-spec-schema.md 组织，至少包含：
- 角色清单
- 模块清单
- 页面清单（P0 / P1 / P2）
- 主流程
- 关键实体与状态
- 权限边界
- 视觉预设选择与理由
产出 [页面设计方案]
为每个核心页面输出：
### 页面名
- 页面目标：
- 适用角色：
- 页面布局：
- 核心区域：
- 核心字段 / 数据：
- 主操作 / 次操作：
- 交互行为（至少 2 条）：
- 状态反馈（loading / empty / error / no_permission）：
- 页面跳转关系：
满足最低要求：
- 每页至少 3 个组件
- 每页至少 2 条可执行交互
- 每页覆盖 4 类状态
- 每页至少 1 组 mock data
产出 [原型渲染指令]
把结构化结果转成交给 frontend-design 的明确任务。
要求：
- 指定产品类型、导航模型、响应策略和视觉预设。
- 指定首批渲染页面，默认先 P0。
- 使用
references/rendering-prompt-template.md 的指令格式和渲染规范。
- 只实现原型层交互，不补业务后端。
- 使用与场景一致的 mock data。
选择视觉预设
按 references/design-presets.md 的决策树选择预设，不按个人偏好随机选色。没有明显行业信号时默认 saas-clean。
控制首轮范围
- 优先做能讲清主链路的 P0 页面。
- 不要在首轮加入拖拽画布、复杂审批引擎、多人协同、条件编排器。
- 页面数过多时，按
references/rendering-prompt-template.md 的分步渲染方式拆批。
进入迭代模式
在用户提出“加一个详情页”“把表格改成卡片”这类修改时：
- 先定位变更范围：单组件、单页面或跨页面。
- 只增量修改受影响的 ProductSpec 和页面方案。
- 只重写受影响的渲染交接。
- 保持未修改部分的页面结构和视觉基调稳定。
处理失败保护
输入极度混乱时：
- 收敛成最小可行方向。
- 默认输出 1 个总览页 + 1 个列表页 + 1 个详情层。
- 把高不确定项放进“待确认项”，不要阻塞产出。
长会议纪要只抽取影响页面设计的内容，不逐句复述。
交付前自检清单
任何一项明显不满足，先回退修正再输出。
需求忠实度
- 区分了用户原话、已确认事实和
[默认推断]
- 高影响不确定项收敛到"待确认项"
- 会议纪要未逐句复述成流水账
产品结构
- 明确了目标用户、核心目标和关键对象
- 给出了角色、模块、页面和主流程
- 补上了关键实体状态和权限边界
页面完整度
- 输出了真正的页面，而不是功能点清单
- 每个核心页面至少 3 个组件、2 条交互、4 类状态、1 组 mock data
渲染交接质量
- 明确了首批渲染页面和优先级
- 说明了导航模型、响应策略和视觉预设
- 限制在单文件 HTML + 原型层交互范围内
视觉质量
- 颜色符合行业气质，非随机选色
- 避免 Inter、紫色白底、廉价渐变和平均分配多色
- 主色、强调色和状态色职责清晰
发布级视觉
- 界面上没有规格注释、组件说明、交互描述等批注文字
- 按钮和标签只有产品级文案，没有"点击可以……"之类的解释
- Mock data 使用写实内容，没有"示例""测试"等暴露原型身份的文案
- 整体看起来像真实产品，不像带注解的线框图
可交付性
- HTML 可直接浏览器打开
- Hash 路由可用
- 抽屉、弹窗、Toast 至少有一条可演示路径
- 首轮范围收敛，没有无关页面膨胀
