产品设计工作流

问题从哪来

大型产品设计慢，往往不是缺自动化，而是需求和早期决策边做边变：design 一改，PRD 跟着改，原型往往要整段重做。若把错误决策自动一路带到交付物，返工会级联放大。

本技能把「设计系统 → PRD → 计划书 → 原型 → 对抗性审查」串成分阶段设卡的编排：每阶段产出一个可交付物，经你确认后再进下一阶段，下游始终站在已验证的上游之上。

工作方式

主 agent 负责规划、派活、纠错、整合与审查；子 agent 按计划执行单一交付物。

• Phase 0：用 AskUserQuestion 问清技术形态、入口承载、首版范围等会改变方案走向的决策；有现成设计规范或 PRD 模板则先读再沿用。
• Phase 1：产出 design.md（遵循 Stitch / awesome-design-md 骨架）及 assets/design.css，可选 preview.html；门：配色与组件基调确认后再继续。
• Phase 2～3：PRD 与 PLAN.md（角色纪律、文件结构、地基优先、子 agent 分工与逐条验收标准、边界清单）；各阶段各有确认门。
• Phase 4：主 agent 先搭共享地基，再并行派子 agent 做视图；子 agent 须复用 design.css / mock，禁止自造 token；主 agent 对照验收标准打回不达标项。
• Phase 5：对抗性审查，输出 REVIEW.md（已覆盖 / 已修复 / 范围外 / 建议下一步 / 安全语义结论）。

各阶段也可单独调用（例如只重做 PRD 或只审查某模块）。

边界与注意

铁律是分阶段人工门，不做无人值守的全自动流水线；模板化设计判断容易产出千篇一律的 PRD，关键决策应通过提问问清，而不是替用户猜。具体设计 token、领域业务与技术选型不进 skill 固化，每次在 Phase 0 与交付物里现定。