| name | frontend-design-spec |
| description | Use when the task is to convert a feature requirements document into a text-only frontend design specification with a complete page list, detailed per-page layout, UI, UX, colors, styling, and minimal copy that developers can implement directly. |
Frontend Design Spec
在当前任务是“把功能需求文档转换成可直接指导前端开发的设计说明文档”时使用这个 skill。
适用范围：
- 需求文档转前端设计文档
- 根据功能描述补全页面清单和页面层级
- 输出纯文字版 UI / UX 设计说明
- 明确每个页面的布局、颜色、圆角、阴影、间距、文案和交互状态
不适用范围：
- 直接实现前端代码
- 输出高保真图片稿、Figma 文件或视觉资源
- 只做技术方案、接口设计或组件库选型
输出目标
产出的文档必须写入 .dev/frontend_design_doc.md，并且让后续开发在没有设计图的情况下，也能按照文字说明完成页面实现，尽量减少二义性。
文档必须满足：
- 覆盖所有需要创建的页面，不遗漏主流程、辅助流程、空状态页、结果页或关键弹层
- 每个页面都有完整描述，而不是只写一句概述
- UI 和 UX 同时明确，既说明“长什么样”，也说明“为什么这样排布、如何交互”
- 文案尽可能少，只保留必要标题、按钮、提示和状态文字
- 多使用具体描述，少用“高级感”“现代”“简洁”这类空泛词
工作流程
- 先完整读取需求文档，提取目标用户、核心任务、主流程、关键状态、平台范围和品牌倾向。
- 从用户流程反推页面清单，补全被隐含但开发必需的页面、弹层和状态。
- 先写全局设计基线，再写页面级设计。
- 每个页面都按统一结构展开，写到可以直接开发。
- 如果需求缺失，做“最小有用假设”，统一写进
假设，不要把假设混进确定性描述里。
- 将最终文档写入
.dev/frontend_design_doc.md。
全局规则
- 文档是设计文档，不是 PRD，不是技术方案，不写组件实现、框架建议、接口格式或代码结构。
- 最终输出使用简洁 Markdown，写入
.dev/frontend_design_doc.md。
- 用户可见语言跟随任务语言；如果需求文档本身指定了语言，以需求文档为准。
- 默认同时考虑桌面端和移动端；如果需求明确只做单端，按需求执行。
- 任何页面都应说明信息层级，不要只列模块名称。
- 任何重要区域都应说明位置、尺寸倾向、间距、对齐、背景、边框、圆角、阴影、文字层级和交互反馈。
- 任何交互都应说明触发方式、反馈方式和异常状态。
- 缺少品牌规范时，主动给出一套完整但克制的配色和视觉系统，包含具体颜色值。
文档结构
输出文档建议使用下面的结构：
1. 项目概述
2. 全局设计系统
必须包含：
整体视觉方向
说明界面的气质、密度、节奏和内容呈现方式，用具体词描述，例如“浅底、高留白、信息块分层明显、主操作高对比”。色彩系统
至少给出：
- 主色
- 辅助色
- 强调色
- 页面背景色
- 卡片背景色
- 主文字色
- 次文字色
- 边框色
- 成功 / 警告 / 错误色
每个颜色都尽量写出十六进制值和使用位置。
字体与文字层级
说明页面标题、区块标题、正文、说明文字、按钮文字的大致层级关系。圆角与阴影
明确不同层级容器、按钮、输入框、弹层的圆角和阴影风格。间距系统
说明页面外边距、区块间距、模块内间距和栅格倾向。交互反馈规则
说明 hover、active、focus、disabled、loading、success、error 的视觉反馈。
3. 页面清单
先列出完整页面清单，每个页面至少写清：
4. 页面详细设计
每个页面必须单独展开，使用下面结构：
页面定位
- 页面目标
- 目标用户状态
- 该页面在整体流程中的前后关系
页面结构总览
- 页面采用几段式结构
- 首屏最重要的信息是什么
- 主次内容如何分区
- 桌面端和移动端是否改布局
详细布局说明
按照从上到下、从左到右的顺序描述每个区域。每个区域至少写清：
- 位置：在页面中的相对位置
- 宽度 / 高度倾向：全宽、定宽、双栏、单栏、吸顶、底部固定等
- 内容：标题、说明、输入、按钮、列表、卡片、图表、媒体、状态提示等
- 排列：水平或垂直、几列、间距、对齐方式
- 样式：背景色、边框、圆角、阴影、文字层级、按钮样式
- 文案：该区域实际应出现的最少文案
- 交互：点击、切换、展开、滚动、悬停、提交后的反馈
页面状态
按需覆盖：
- 默认状态
- 空状态
- 加载状态
- 错误状态
- 禁用状态
- 成功状态
- 权限不足状态
- 数据过多或异常状态
UX 说明
至少写清：
- 为什么这样安排主操作和次操作
- 用户视线先看到什么，再完成什么
- 哪些地方要减少认知负担
- 哪些地方要避免误操作
- 移动端如何保证点击和阅读效率
写作要求
- 优先使用“可开发描述”，不要使用只适合设计评审的空话。
- 不要写“可放一个按钮”“这里可以有一些说明”，必须说明具体放什么。
- 不要只写“卡片风格”，要说明卡片尺寸倾向、内边距、背景、边框、阴影和内容顺序。
- 不要堆砌长文案；页面 copy 默认精简，标题短、按钮短、提示短。
- 如果一个页面包含弹窗、抽屉、下拉、筛选面板、toast、tab、分页、底部操作栏，也要写进该页面设计里。
- 如果需求中隐含了登录、注册、找回密码、引导、列表详情切换、提交成功页等页面，必须主动补齐。
质量标准
完成后自检：
- 是否已经写入
.dev/frontend_design_doc.md
- 是否已经列出所有需要开发的页面
- 是否每个页面都能让前端直接实现，而不是仍需猜测
- 是否给出了具体颜色、圆角、阴影、层级和间距倾向
- 是否写了关键状态，而不仅是默认态
- 是否控制了文案数量，避免页面被无意义说明填满
- 是否避免技术实现细节，保持为设计说明文档
