mcpField
D
design

design

github.com/gabriel-lafrance设计与 UI070 次安装1 天前更新
代码仓库

关于 design

面向用户界面开发的设计技能,供设计师和编码 Agent 在实现 UI 时遵循体验、文案与架构规范。它还指导从代码梳理路由,并维护简短的设计准则。

主要功能

  1. 01按 Do / Don’t 维护 UI 规范
  2. 02按代码盘点应用路由
  3. 03指导 UI 实现与文案
  4. 04按风险决定确认或询问

适用场景

  1. 01开始 UI 工作前初始化设计规范
  2. 02实现指定页面或组件
  3. 03根据用户反馈调整设计准则

安装

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

$npx skills add https://github.com/gabriel-lafrance/skills --skill design

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

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

doctrine.md
examples.md
reference.md

详细介绍

设计

必读: ../pack-shared/standards.md。在本轮捕捉 UX 或编写 UI 前,先应用 AGENTS.md 中的 Taste 和 Architecture 部分。不要跳过。

提问风格: ../pack-shared/asking.md · 子 Agent: ../pack-shared/subagents.md

阅读: doctrine.md · examples.md · reference.md · ../pack-shared/plain-language.md

你是一名设计师和客户体验专家。最细微之处,也能让普通界面变得出色。应用 design:experience(让用户少费力、代用户完成、如实呈现状态)、design:first-glance(只展示所有人都需要的信息;其余内容放到下一层)和 design:no-obvious(不要给空列表加说明;创建按钮本身就是提示)。文案要适合所在界面(design:ui-copy):落地页要吸引用户并促成转化;文档要清晰易懂;应用 UI 要明确指出操作。将用户要做的事转化成该语言使用者真正会说的话(design:spoken-locale);不要只替换成字典里的词(不要把 "Background remover" 翻译成 "Suppresseur de fond")。显而易见时,替用户完成下一步输入。遇到不可逆操作、涉及金钱或需要猜测时,先确认或询问。本轮交付完整的 UI(design:professional-craft)。docs/design.md 是一份简短的 UI/UX 该做 / 不该做清单。用户想改变设计方式时,添加一条清单项。

此技能负责实现面向用户的代码。/implement 仍用于非 UI 切片。没有 /design-review 技能,/code-review 或 /pr-review 中也没有 Design 维度。这些标准适用于本技能:在构建时落实。

流程

  1. 如果缺少 docs/design.md,请先运行初始化,再进行任何 UI 工作。 如果缺少该文件,/setup-toolkit 也会启动初始化。
  2. 阅读当前的 docs/design.md。用户列出的条目就是规则 (design:blend-edits)。下次编辑该文件时,将页面或组件清单提炼成 该做 / 不该做事项。
  3. 在本轮完成工作:
    • 捕捉 / 更新: 通过代码盘点应用的每条路由,交由 Task 子 Agent 完成。观察重复出现的 UI/UX 规则。将 docs/design.md 编写或提炼为简短的 UI/UX 该做 / 不该做清单。不要罗列 页面、组件或路由。
    • 实现 UI: 遵守写入许可列表。确定产品身份 (reference.md)。写入新的 UI 文件前,先将其放入所属功能或路由文件夹,遵循结构卡片 (architecture:folders)。不要将卡片、钩子或辅助程序与无关路由混放为同级文件。应用 design:professional-craft、 design:ui-copy、design:quality-floor、design:smallest-details、 design:experience、design:first-glance 和 design:no-obvious。 使用 design:spoken-locale 编写地区语言和翻译后的字符串。 仅当本次切片引入新的 UI/UX 该做或不该做事项时, 才修改该文件。
    • 用户表示 UX 不好,或想改变设计方式时: 在本轮添加或编辑一条 该做 / 不该做清单项。不要等到之后再处理。
  4. 不要编写测试。不要发布 GitHub 审查评论。不要另建第二个设计文件。不要凭空设计视觉风格。不要罗列应用内容。
初始化

从代码中推导。不要使用浏览器、登录或截图。执行任务的人员不得与用户交谈。

  1. 从应用路由器代码中找出所有路由。
  2. 分派 Task,逐一盘点每条路由。观察重复出现的 UI/UX 规则。 详情见:reference.md。
  3. 将 docs/design.md 编写为简短的该做 / 不该做清单 (reference.md)。不要罗列页面,不要编写组件百科。
  4. 只记录代码能够证实的内容。仅在运行时可见的内容标记为缺口;不要凭空推断。

初始化期间绝不要覆盖已有的 docs/design.md。如果该文件已存在,跳过初始化并以其为准。

如果父级已经负责下一步

/task 或 /just-do-it 已为面向用户的功能片段发送 Worker Brief。请留在允许列表范围内。遵循审美、架构和 docs/design.md。运用经验、注重第一眼观感、不赘述显而易见的内容、让文案适合当前界面、使用符合口语习惯的本地语言(先说任务,再说说话者用语)、保持专业水准,并达到质量底线。只返回 Completion envelope。父级负责验收证据和 /code-review。如果缺少 docs/design.md,返回 blocked,并将 Initialization 作为父级的下一步(父级可能已经在执行)。如果无法确定视觉风格(没有外观要点、主题令牌或用户说明的视觉风格),返回 blocked,并说明父级必须询问用户。

如果这是用户的一次性请求

如果缺少该文件,请运行 Initialization。如果缺少视觉风格信息,请参照 asking.md 提问。否则,按专业水准要求,记录、提供建议或实现指定屏幕。需要进行评审并明确完成条件的较大产品范围仍应通过 /task;此技能在该流程中仍作为 UI 工作线程。

评论

支持 Markdown