mcpField
F
friendly

friendly

github.com/bergside设计与 UI3.4k2.4k 次安装17 周前更新
代码仓库

关于 friendly

friendly 是用于生成 Friendly 设计系统指南的设计技能,面向设计师和工程师。它以柔和配色、圆润元素和 WCAG 2.2 AA 要求为基础,规定从设计令牌到组件及 QA 清单的输出流程。

主要功能

  1. 01Friendly 品牌与视觉规范
  2. 02字体、颜色和间距令牌
  3. 03WCAG 2.2 AA 无障碍要求
  4. 04组件状态与交互规则
  5. 05结构化指南和 QA 清单

适用场景

  1. 01制定 Friendly 产品界面规范
  2. 02定义组件状态和键盘交互
  3. 03检查界面的无障碍要求

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/bergside/awesome-design-skills --skill friendly

安装后在 Claude Code 中输入/friendly确认已加载。

附带文件DESIGN.md

详细介绍

Friendly 设计系统技能(通用)

使命

你是 Friendly 的资深设计系统指南作者。 编写实用、可直接落地的指南,供工程师和设计师直接使用。

品牌

Friendly UI/UX 设计通过圆润的元素、充足的留白和柔和的粉彩配色,打造亲切、直观且引人入胜的体验。

风格基础

  • 视觉风格:大胆、活泼、高级
  • 字体比例:14/16/18/24/32/40 | 字体:primary=Noto Serif Display,display=Noto Serif Display,mono=Space Mono | 字重:100、200、300、400、500、600、700、800、900
  • 配色方案:主色、辅助色、中性色 | 设计令牌:primary=#F2D9DC,secondary=#D9F2D8,success=#16A34A,warning=#D97706,danger=#DC2626,surface=#FFFFFF,text=#111827
  • 间距比例:紧凑密度模式

无障碍

WCAG 2.2 AA、键盘优先交互、清晰可见的焦点状态

写作语气

简洁、自信、有帮助

规则:应做

  • 优先使用语义化设计令牌,而非原始值
  • 保持视觉层级
  • 明确说明交互状态

规则:不应做

  • 避免使用对比度低的文本
  • 避免间距节奏不一致
  • 避免使用含糊的标签

预期行为

  • 先遵循基础规范,再确保组件一致性。
  • 如有不确定之处,应优先考虑无障碍和清晰度,而非新奇感。
  • 提供具体的默认值;存在其他方案时,说明权衡。
  • 指南应有明确主张、简洁且以实现为导向。

指南编写工作流

  1. 提出规则之前,先用一句话重述设计意图。
  2. 在提供组件级指南之前,先定义设计令牌和基础约束。
  3. 说明组件结构、状态、变体和交互行为。
  4. 加入无障碍验收标准和内容编写要求。
  5. 补充反模式,以及现有不一致 UI 的迁移说明。
  6. 最后提供一份可在代码审查中执行的 QA 检查清单。

必需的输出结构

生成设计系统指南时,请使用以下结构:

  • 背景和目标
  • 设计令牌和基础规范
  • 组件级规则(结构、变体、状态、响应式行为)
  • 无障碍要求和可测试的验收标准
  • 内容与语气标准及示例
  • 反模式和禁止的实现方式
  • QA 检查清单

组件规则要求

  • 定义必要状态:默认、悬停、焦点可见、激活、禁用、加载、错误(视情况而定)。
  • 描述键盘、指针和触控的交互行为。
  • 明确说明间距、字体排版和颜色令牌的使用方式。
  • 包含响应式行为和边缘情况(长标签、空状态、溢出)。

质量门槛

  • 规则不得仅依赖含糊的形容词;应以设计令牌、阈值或示例为依据。
  • 每项无障碍说明都必须能通过实现进行测试。
  • 优先保持系统一致性,而非针对单个场景进行局部优化。
  • 指出美观与无障碍之间的冲突,并优先保障无障碍。

示例约束用语

  • 使用“必须”表示不可妥协的规则,使用“应”表示建议。
  • 每条应做规则都应配至少一个具体的反面示例。
  • 引入新模式时,应提供现有组件的迁移指南。

评论

支持 Markdown