makelore/.opencode/skills/designer-design-spec/SKILL.md

name, description

name	description
designer-design-spec	当 NianCode 美术设计师角色为学习者软件项目研究或定义 UI/UX 视觉方向、设计规则、布局、颜色、字体、无障碍、响应式行为和设计质检时使用。

设计规范

使用这个 skill，把项目计划和原型 Demo 转成开发工程师和市场运营都能遵循的清晰视觉规则。

给学生看的说话规则

必须使用 youth-plain-language。设计建议要翻译成看得见的规则，不只说“高级”“好看”“统一”；要说明颜色、文字、按钮和布局应该怎么做。

工作流程

1. 阅读项目目标、受众、第一版范围和原型 Demo。
2. 选择适合学习者项目的视觉方向，不套用泛泛风格。
3. 基于原型流程定义颜色、字体、间距、布局、组件和状态。
4. 包含响应式和无障碍规则。
5. 交接前指出风险。

设计保护规则

• 先理解产品目标、学习者范围和原型流程，再选择风格。
• 把视觉偏好转成可实现规则：明确色彩角色、字号层级、间距、组件状态和布局行为。
• 区分必须遵守的规则和可选打磨项。
• 交接前标出对比度、溢出、触控区域太小、固定宽布局、文字不可读等风险。
• 不要要求下一位角色“做得好看”，要给出可以执行的规则。

UI/UX 课程质量

必须使用的子 skill： 交接设计规范前，使用 ui-ux-course-quality。

当无障碍、触控与交互、响应式布局、字体与颜色、状态反馈会影响产品流程时，设计规范必须覆盖这些内容。如果某项不相关，要简短说明原因，不要默认省略。

必须输出

返回设计规范，包含：

1. 设计方向
2. 参考关键词
3. 色彩规则
4. 字体和层级
5. 页面布局
6. 组件规则
7. 交互状态
8. 响应式和可访问性要求
9. UI/UX 质量检查
10. 给开发工程师的交付说明

纠偏清单

出现这些情况时纠偏：

• 设计只有装饰效果，没有支撑产品目标。
• 配色使用了太多无关颜色。
• 文字对比度或按钮状态不清楚。
• 布局只依赖固定桌面尺寸。
• 设计规范只说“可爱一点”或“现代一点”，没有具体规则。

用可实现规则替代模糊风格词。

交接

交接给开发工程师时，提供与原型一致的页面结构、组件规则、状态和视觉约束。如果原型缺少关键页面或操作，先请产品经理修补原型，再定稿设计规范。