UIUX 原型设计
围绕真实任务设计产品界面。在应用实现之前交付可审查的 HTML。使用用户的语言工作；默认使用中文解释并辅以必要的英文术语。此技能是自包含的：上游技能和付费参考服务是可选的，而非依赖项。
1. 确立产品并保留其基线
首先阅读适用的 AGENTS.md、HANDOFF.md、现有的 DESIGN.md 和当前的原型文件。确定用户、场景、入口、主要任务、结果、商业价值、要求的界面以及本次版本范围之外的内容。保留已有的品牌决策和其他人的编辑。自行解决常规细节；仅就那些会实质性改变设计而你又缺少的信息进行询问。
根据需求说明确定有边界的屏幕/流程清单，而非任意数量的页面。覆盖每个要求的界面（Web、小程序、移动端、桌面端）；不要发明不相关的应用。如果界面范围未知且项目无法确定，则在继续之前询问一次。对于继承的 UI，进行审计并使用不覆盖的版本，而非未经请求的重新设计。
阅读 source-synthesis.md 中的相关决策规则章节（第 1-7 节）；当需要解释权衡时，使用其源映射（第 8-10 节）。它整合了所有七个源代码仓库。产品任务清晰度、现有设计合同和用户选择优先于登录页面惯例、样式禁令和随机主题。
2. 研究参考，然后停止以进行样式决策
阅读 reference-research.md。从 Dribbble 开始；使用 即时设计 和 Behance 作为备选或补充。搜索产品类别、用户的任务和相关平台，而不仅仅是“漂亮的 UI”。使用可用的浏览器/搜索工具；记录实际检查了哪些页面和图片。不要将搜索结果摘要视为视觉审查。注意访问限制；如果无法查看真实案例，则报告此情况并要求用户提供参考或明确豁免研究。
在 docs/prototype/versions/vX.Y.Z/（或项目已建立的原型根目录）下创建一个新版本。使用下面的 CLI 安全启动。首先编写 style-reference.html：通常包含 2-3 个差异化、适合任务的方案方向、真实案例链接/创作者、观察到的证据与你的解释对比、令牌样本以及针对相同任务的原创小型 UI 研究用于比较。包括平台适配性、局限性以及你的推荐。保留已知的品牌选择；当用户已提供一个方向时，验证它而非强制提供替代方案。
交付实际的样式参考 HTML 并请用户选择或修改。在此步骤停止。 在用户明确批准一个命名方向（或在当前任务中委派该确切选择）之前，不要创建完整的应用界面、design-system.html 或最终的 DESIGN.md。本地选中的单选按钮/卡片、推荐的偏好、已过时间或 CLI 记录均不构成用户授权。保留批准证据以及已批准 HTML 的 SHA-256 哈希值；对该看板的实质性更改需要重新决策。不要将此关口视为再次询问无关的、已授权工作的许可。
3. 批准后构建完整的 HTML 原型
阅读 prototype-contract.md 以及 platforms-and-quality.md 的相关章节。记录用户的实际决策；助手记录证据，但无法验证是谁给出的。然后准备并替换生成的脚手架为设计好的、可工作的制品：
index.html：原型主页/导航，包含版本号、界面入口、核心流程、样式参考和视觉规范链接。每个应用也应有自己的任务导向主页。将实现/状态细节保留在此审查中心中，而非产品 chrome 中。design-system.html：此版本中使用的组件的完整视觉规范：语义色板、排版、间距、布局/密度、图标、界面、适用的组件状态、交互/动效以及响应式/平台差异。展示实际的渲染示例，而不仅仅是名称表格。DESIGN.md：规范决策、令牌值、屏幕/流程清单、交互、平台覆盖项、可访问性、来源和已知的原型限制。按界面的 DESIGN.md 仅解释相关变体。- 每个请求界面的 HTML 屏幕：完整的商定关键路径、合理的带标签合成数据、导航和有意义的状态变更。共享语义令牌；采用适合平台的交互方式，而非缩小后的桌面截图。
默认使用语义化 HTML、CSS 变量和较小的本地脚本。若有助于降低复杂度，可复用现有框架/组件；不要求必须使用 React、Tailwind、shadcn 或网络依赖。静态 HTML 原型必须能通过本地 HTTP 服务器打开，并且应尽可能通过文件 URL 导航。审查原型所需的资源文件应是本地的且已获得许可。保持原型与应用源代码分离。
4. 验证、版本化并移交
使用 platforms-and-quality.md 在窄视口和宽视口、键盘焦点、缩放和减少动效模式下审查渲染结果；检查适用的设备/平台行为。测试实际的用户主路径以及相关的空状态、加载状态、错误状态、成功状态和极端内容状态。不要仅凭浏览器模拟就断言设备或原生 SDK 的接受度。修复观察到的问题并重新检查受影响的路径。
运行结构验证，然后在 QA.md 中记录浏览器证据、视口尺寸、测试过的流程和未解决的问题。结构验证无法证明视觉质量、业务完整性、权限执行、外部集成或生产就绪性。显式报告未测试的项目。对于部署工作，需测量相关的加载/运行时/资源成本，而非仅报告功能性检查；普通的本地原型不需要一套生产基准测试套件。
保留之前的版本不变。阅读 versioning.md 了解关于批准无效化、修订、封存快照、变更日志和最新版本导航的内容。不要静默编辑已批准的看板或覆盖旧的原型。交付实际文件的链接、打开方式、已验证的内容以及仍被模拟的内容。
助手（Python 3，标准库）
将 <skill-dir> 解析为此已安装技能的目录。命令仅对指定的项目进行操作；它们不发布或更改应用源代码。
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# 用真实研究编辑 style-reference.html；获取用户的决定。
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "来自此对话的确切用户决策"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# 替换每个待处理的脚手架，实现商定的流程，然后渲染/审查。
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "已审查范围和实质性更改"
record-approval 存储工作流记录，而非身份或安全边界。切勿伪造其证据。prepare 生成脚手架，而非完成的原型。seal 记录文件哈希值；它并非视觉签核或不可变存储。请结合使用清单文件和 QA 证据。