gemini-designer

Grok Designer — UI, UX, and Visual Design Advisor

Use Grok 4.5 as an external advisor for visual design, UI finish, UX task flow, interaction friction, art direction, and lightweight design artifacts.

API Key 配置入口

需要外部服务凭据时先读API Key 配置与业务读取：复用已有安全入口；本机缺少 Key 时使用随附固定页面，保存后通过业务包装入口读取。内置能力与纯本地流程不要求配置 Key。

关键规则

• 只能通过 grok-designer CLI（PATH 中已有的版本或本 Skill 自带的脚本）与 Grok 交互。不要直接调用 API 或特定提供商的脚本。
• 使用此 Skill 时，在给出 UI 建议、UX 建议、设计图像、艺术指导、评审、视觉建议、HTML 或 SVG 输出之前，必须先调用 grok-designer。不要凭 Agent 自身判断编写这些交付内容。
• 已有运行时凭据时直接调用；使用本机页面保存的凭据时，必须按配置说明通过 run 包装本 Skill 自带脚本。命令不存在时，使用当前 Skill 目录下 scripts/grok-designer 的绝对路径，不要自动安装或覆盖全局命令。
• 对现有文件进行视觉/UI 评审时，使用 grok-designer ui。
• 对 UX、任务模型、组件选择、交互流程、操作阻碍或状态行为进行评审时，使用 grok-designer ux。
• 如果请求同时需要 UI 和 UX 评审，请分别运行 ui 和 ux。可以使用 CLI 的逗号分隔形式，例如 grok-designer ui,ux ...，也可以并行运行单独的命令。
• 需要整体艺术指导时，使用 grok-designer direction。可以将文件作为背景上下文提供。
• 需要生成设计图像 Markdown 时，使用 grok-designer direction，并在回复前阅读生成的 Markdown。
• 需要创建独立的 HTML/SVG 设计草稿时，使用 grok-designer html 或 grok-designer svg。
• 需要手绘单个 SVG 品牌字标、字母标记、签名标记或类似 Logo 的文字素材时，使用 grok-designer svg。
• 需要制作包含多个字标候选方案的对比图时，使用 grok-designer html。
• 如果用户提供了截图、模型图、情绪板或视觉参考，在有助于 Grok 判断视觉风格、布局、层级、氛围、还原度、交互顺序或状态变化时，请通过 -i / --image 添加相关图像。
• Grok 不保留状态。除非在当前命令中提供，否则它不了解当前项目、先前对话、截图、本地文件、设计规则或之前的 Grok 输出。
• 除非用户明确提出，否则不要让 Grok 评审代码质量、技术债务、CSS lint、工程一致性、性能或架构。让 Grok 聚焦于用户能感知和操作的内容。
• 不要让 Grok 为现有文件输出代码补丁或差异。使用其设计建议，然后自行进行实际修改。
• Grok 返回 UI 建议、UX 建议、设计图像 Markdown、视觉方向或 HTML 模型图后，向用户展示输出或简要总结，并等待确认后再在项目代码中实施，除非用户已在本次对话中授权实施。
• 由于 UX 变更通常会影响状态逻辑、路由、表单行为、数据加载或验证，在重构组件逻辑之前，请总结结构或逻辑变更并等待确认，除非用户已在本次对话中授权实施。
• 生成 HTML/SVG 后，检查文件是否存在、结构是否完整，以及是否满足用户的明确要求。结构校验无法证明视觉效果；如果已获授权且具备视觉能力，请检查实际渲染效果，否则应如实说明未进行视觉验收。不要自动扩展为多轮付费评审。
• 对普通 HTML、SVG 或图标请求，每项任务只运行脚本一次。读取输出文件后继续处理。
• 传入用户陈述的要求和具体项目上下文。除非用户明确提出，否则不要添加 Agent 自己的风格标签、布局选择、颜色选择、隐喻选择、交互概念或评估标准。
• 不要替 Grok 预先设计。对于创意生成，只说明用户目标、源材料、输出格式和硬性限制。除非用户明确提供，否则不要指定视觉方向、隐喻、布局、调色板、排版、材质、动画或交互模式。
• 需要多个备选方案时，请让 Grok 给出彼此独立、明显不同的选项。除非用户提供了方向，否则不要给选项命名为“仪表盘方向”“编辑方向”或“雷达方向”等。
• CLI 会自行管理配置和授权。不要预先检查授权。如果调用失败并返回 error=not_authorized，请告知用户 Grok Designer 尚未获得授权。

Grok CLI

每项 Grok 任务都使用 grok-designer。 以下示例展示业务参数。使用页面凭据时，统一通过 node "<Skill目录>/scripts/credential-ui/src/profile.ts" run default -- python3 "<Skill目录>/scripts/grok-designer" 加上这些参数运行；已有运行时凭据时可直接调用，不重复安装。

命令不存在时直接用 python3 "<Skill绝对目录>/scripts/grok-designer"；Python 3.11+ 为必需依赖。仅在用户要求时进行全局安装。

如果 CLI 返回 error=not_authorized，请停止并告知用户 Grok Designer 未获授权。不要读取、复制或打印 API Key；缺少配置时，按本 Skill 的配置说明展示固定页面，由用户亲自保存。

每个命令都有自己的内置提示词。选择合适的命令，并直接传入用户的任务；除非用户明确提出，否则不要添加跨命令提示词框架、设计方向、UX 解决方案或额外输出规则。

命令：

• grok-designer ui — 用于视觉/UI 评审：布局、层级、密度、排版、色彩、间距、表面、阴影、组件外观、视觉一致性和 UI 完成度。可通过 -f 和 -i 添加参考上下文，并且必须通过 -o 指定易读的 Markdown 文件名。
• grok-designer ux — 用于 UX 和交互评审：任务模型、组件选择、流程、阻力、控件结构、可供性、可恢复性、验证、导航清晰度、影响可用性的无障碍设计，以及加载、错误、空白、成功、禁用、悬停、焦点和激活状态。可通过 -f 和 -i 添加参考上下文，并且必须通过 -o 指定易读的 Markdown 文件名。
• grok-designer ui,ux — 用户同时需要视觉/UI 和 UX 评审时使用。CLI 会运行独立的 Markdown 评审命令，并为每个命令写入一个输出文件。
• grok-designer direction — 任务需要更鲜明的创意、艺术指导、视觉隐喻、设计意象 Markdown 或高层设计方向时，在实现前使用。文件为可选项。始终通过 -o 指定易读的 Markdown 文件名。
• grok-designer html — 用于创建独立的新 HTML 模型或概念页面。可通过 -f 和 -i 添加参考上下文，但不要用它直接修改现有项目文件。
• grok-designer svg — 用于创建新的 SVG 图标、简单插图或单个手绘 SVG 字标。可通过 -f 和 -i 添加参考上下文。

当 ui 或 ux 需要评判现有 UI 时，默认传入完整的相关文件。除非文件太大、超出 CLI 限制，或用户要求限定评审范围，否则不要概述、截取或添加注释。对于一般设计问题，可以只用提示词运行 ui 或 ux。

对于 ui、ux 和 direction，始终在调用时通过 -o 指定 Markdown 文件名。优先使用易读的简单文件名，例如 accounts-filter-ui.md、tag-editor-ux.md、museon-home-art-direction.md 或 pricing-page-design-imagery.md；CLI 会将简单文件名保存到 .grok-designer/ 下。仅在需要指定目录时使用显式路径。

对于多命令 Markdown 评审，传入一个易读的 -o 名称。CLI 会按命令为其添加后缀：

grok-designer ui,ux "评审这个标签编辑组件" \
  -f ./TagEditor.tsx \
  -f ./tag-editor.css \
  -o tag-editor-review.md

这会分别写入 tag-editor-review-ui.md 和 tag-editor-review-ux.md 等输出文件。

对于 html 和 svg，如果 Grok 需要参考现有内容、设计规则、之前的模型、主题令牌、示例组件或品牌参考，请使用 -f 传入文件。将这些文件视为新设计草案的上下文，而不是需要 Grok 原地修补的文件。

对于 html，只描述设计目标。不要要求 Grok 保存文件、返回 file:// URL、提供下载链接或说明文件位置。CLI 会写入输出文件；Grok 必须只返回完整的原始 HTML 源码。

对于 html，默认不要提及资源或依赖项政策。由 Grok 判断图片、字体、脚本、样式表、图标库、音频或视频是否有助于设计。仅在用户明确提出要求时才添加资源约束，例如完全自包含、可离线使用、不使用外部资源或使用真实的公开图片。 对于手写字标，如果用户只需要一个素材，请使用 svg；如果用户想要多个候选方案进行比较，请使用 html。描述文字内容、氛围，以及用户明确提出的材质偏好。除非用户提出要求，否则不要指定霓虹、金属、科幻或其他效果繁复的风格。默认方向是清晰易读的纸墨风格 SVG 字样，配以细腻的书写动画，并在有助于效果时添加雅致的收笔装饰。

内置的 direction、html 和 svg 提示词会适度提醒 Grok：避免使用泛化的 AI 模板和刻板的类别印象；通过具体的感官要素，让主题一目了然；让设计选择贴合产品主题和真实内容；在有助于视觉传达时运用有目的的对比；将视觉上的大胆表达集中在一个重要位置，并让周围的 UI 保持克制。

上下文规则

Grok 只能接收命令文本、通过 -f 传入的文件，以及通过 -i 传入的图片。它不会在不同调用之间保留记忆。

CLI 会把最终用户目标放在参考文件和图片清单之后，以便 Grok 最后看到具体任务。Agent 应尽量沿用用户的措辞描述任务，避免在多个地方重复约束。

询问现有 UI 时，只传入完成判断所需的最少完整文件集：

• 被评估的目标文件或组件
• 如果工作区中存在项目设计指南或样式参考，请一并提供
• 会对视觉结果产生实质影响的相关 CSS／主题／令牌文件
• 仅当相邻组件文件定义了可见结构、可见状态或复用的 UI 模式时，才将其纳入
• 会对 UX 行为产生实质影响的状态、钩子、表单、验证、路由或上下文文件
• 如果用户的问题取决于 UI 的外观或变化方式，请提供截图、模型图、情绪板、参考图片、导出预览或连续状态截图

对于 ui，优先提供可见／渲染后的上下文：

• 目标组件或页面文件
• CSS／主题／令牌文件
• 设计系统或样式参考文件
• 截图、渲染预览、模型图或视觉参考

对于 ux，仅有视觉文件并不足够。还应提供定义用户任务和状态转换的上下文：

• 定义控件、状态、验证和可见行为的组件文件
• 当问题取决于选择合适的控件模式时，提供现有的组件库文件或相邻示例
• 控制流程的钩子、上下文、路由、表单、架构或数据加载文件
• 会影响标签、错误、确认信息、空状态或成功状态的文案／配置文件
• 当体验涉及多个状态时，提供连续图片，例如 -i step1.png -i step2.png
• 如果无法从文件中明确看出用户的预期任务，请说明该任务

优先提供完整文件，而非摘录。使用多个 -f 标志：

grok-designer ui "判断这个页面是否符合项目现有视觉风格，并给出具体优化建议" \
  -f ./design.html \
  -f ./src/styles/tokens.css \
  -f ./src/components/Button.tsx \
  -o design-page-ui.md

grok-designer ux "评审这个标签编辑组件的任务模型和交互状态" \
  -f ./src/components/TagEditor.tsx \
  -f ./src/hooks/useTags.ts \
  -i ./screenshots/tag-editor-open.png \
  -o tag-editor-ux.md

使用 -i 提供图片上下文：

grok-designer ui "结合截图给这个页面提视觉设计建议" \
  -f ./design.html \
  -i ./screenshots/current.png \
  -o current-page-ui.md

grok-designer direction "参考这张图，生成设计意象 markdown" \
  -i ./references/moodboard.png \
  -o product-design-imagery.md

通过 -i 传入图片时，CLI 可能会在内部向 Grok 发送经过优化的 WebP 版本，以缩小请求体积，同时保留清晰可读的 UI 细节。Agent 仍应传入原始截图或参考图片的路径。

不要传入无关的源文件、构建产物、依赖目录、日志，或不会影响视觉结果或用户可见交互的实现细节。如果所需上下文过大，请选择有代表性的设计系统文件，并在任务文本中说明缺少哪些内容。

如果 Grok 的 ui 或 ux 输出表示需要更多上下文，不要将其视为最终建议。如果能找到所需文件或信息，请收集后使用新增的 -f 或 -i 输入重新运行同一命令一次。如果找不到所需上下文，请明确告知用户缺少什么，并向其索取。

内置的 ui 提示词会要求 Grok：

• 关注视觉效果、信息层级、阅读节奏、排版、色彩、间距、表面样式、组件外观、UI 完成度和情绪基调
• 避免代码审查、CSS 规范批评、技术债务、架构、业务逻辑和新增功能建议
• 明确说明具体修改位置、修改方式，以及这样做如何改善视觉效果
• 在有帮助时提供伪代码、CSS 或 JSX 代码片段，长度足以说明修改内容，但不要输出完整文件
• 提醒实现 Agent 优先使用现有组件、选择器、类、设计令牌、变量、布局模式和交互模式
• 仅在提供的文件中确实可见时，才提及可复用组件或设计令牌；否则不要虚构项目专属名称
• 如果有应保留的具体区域、设计令牌、组件、视觉特征、文案或状态，请添加简短的“不要更改”部分
• 如果缺少上下文，无法做出可靠的 UI 判断，请先询问，不要猜测

内置的 ux 提示词要求 Grok：

• 关注自然的任务模型、组件选择、认知负荷、交互阻力、控件结构、可供性、可恢复性、验证、导航清晰度、影响可用性的无障碍设计，以及可见的状态反馈
• 判断所选组件或控件模式是否适合任务，例如，编辑标签时应使用可编辑的标签/胶囊编辑器，而不是分别使用添加和删除输入框
• 在相关时评估加载、错误、空、成功、禁用、悬停、焦点和激活状态
• 避免纯粹的视觉润色，除非它会直接损害可用性
• 避免产品战略、功能膨胀、游戏化、大范围重新定位、代码审查、CSS 规范批评、技术架构和文件结构评判
• 在现有产品范围和用户目标内开展工作
• 提供具体的结构、组件模式、交互、文案、状态或布局修改建议
• 如果缺少状态逻辑、路由、组件代码、组件库示例、表单验证或连续截图，导致无法做出可靠的 UX 判断，请先询问，不要猜测

并行评审

当用户要求从多个维度进行评审时，分别独立运行每个相关命令。不要把 UI、UX、艺术指导、HTML 或 SVG 工作合并成一个宽泛的提示词。

对于 UI + UX 评审：

1. 分别运行 grok-designer ui 和 grok-designer ux，或运行 grok-designer ui,ux，让 CLI 分别生成独立的输出。
2. 将相同的用户目标传递给两个命令，不要添加由 Agent 编写的视觉风格、交互隐喻、配色方案、布局或 UX 解决方案。
3. 为 ui 提供屏幕截图、渲染预览、样式令牌、主题文件和可见的组件文件。
4. 为 ux 提供组件逻辑、状态文件、路由文件、组件库示例、表单／验证逻辑，以及可用的连续截图。
5. 两份输出都返回后，为用户综合整理：
   • 先呈现 UX：任务模型、组件选择、流程、状态反馈、摩擦点和可恢复性。
   • 再呈现 UI：层级、排版、间距、精细度和视觉一致性。
   • 如果 UX 和 UI 建议冲突，优先采用 UX 的结构性决策，并明确说明只有在受影响元素保留时，哪些 UI 建议才适用。

实用命令：

grok-designer ui "给这个页面提视觉/UI设计建议" -f ./design.html -o design-page-ui.md
grok-designer ux "评审这个页面的任务流、交互摩擦和状态反馈" -f ./design.html -o design-page-ux.md
grok-designer ui,ux "同时从 UI 和 UX 角度评审这个标签编辑组件" -f ./TagEditor.tsx -o tag-editor-review.md
grok-designer ui "结合截图给这个页面提视觉/UI设计建议" -f ./design.html -i ./screenshots/current.png -o page-screenshot-ui.md
grok-designer direction "给这个产品生成设计意象 markdown" -o product-design-imagery.md
grok-designer direction "基于这个页面生成设计意象 markdown" -f ./design.html -o page-design-imagery.md
grok-designer html "基于这个页面生成一个完整、全新的落地页方案。保留产品信息，由你独立判断视觉方向，不要复刻原稿。" -f ./design.html -o ./designs/page.html
grok-designer html "基于这个页面生成第 1 个完整落地页方案。保留产品信息，由你独立判断视觉方向。后续方案需要彼此明显不同。" -f ./design.html -o ./designs/page-option-1.html
grok-designer svg "为 Museon 生成一个手写 SVG 字标，气质像策展笔记标题" -o museon-wordmark.svg
grok-designer html "展示 Museon、Mel、Signal 三个手写 SVG 字标候选，默认偏纸面墨迹和真实笔触" -o wordmark-candidates.html
grok-designer svg "生成一个设置图标" -f ./brand.md -o ./icons/settings.svg

采取行动前，请先阅读所有输出文件。只应用适合该项目的建议。

ui、ux 和 direction 输出包含一个末尾的 原始提示词 部分。该部分记录任务文本，以及所引用文件或图像的可读路径，不会在附录中复制完整文件内容。

对于 Grok 的建议性输出（ui、ux 和 direction）及 HTML 样稿，不要立即编辑项目文件。先向用户展示 Grok 的输出或简要摘要，询问用户选择或确认方向，然后只实现已确认的部分。如果用户只要求创建 SVG 图标素材，则可以直接保存 SVG 图标输出。不要仅仅因为创建了 HTML 或 SVG 文件就执行自审。

脚本成功时会打印：

output_path=<path to output file>

对于多命令评审，每个命令会打印一个路径：

output_path[ui]=<path to UI output file>
output_path[ux]=<path to UX output file>

对于 html 和 svg，脚本还会打印：

integrity=passed

读取 output_path 指向的文件以获取 Grok 的回复。

失败时，CLI 会打印固定字段：

error=<code>
message=<short explanation>
hint=<next step>

如果 hint 中有可执行的操作，请按其提示处理。如果 error=not_authorized，请停止并告知用户 Grok Designer 未获授权。

对于生成的 HTML／SVG，output_path 加上 integrity=passed 是通常的完整性信号。除非用户要求额外的浏览器或视觉验证，否则不要在 Agent 中重复 CLI 检查。

输出类型

• grok-designer ui — Markdown 格式的 UI 评审输出。
• grok-designer ux — Markdown 格式的 UX 评审输出。
• grok-designer direction — Markdown 格式的设计方向输出。
• grok-designer html — 包含内联 CSS 的完整独立 HTML 源码，可直接在浏览器中打开。CLI 会拒绝不完整的 HTML、缺少 head/body 的 HTML、文件 URL、Markdown 代码围栏、lorem ipsum 文本以及非 HTML 包装输出。
• grok-designer svg — 用于图标、简单插图或单个手写字标的干净 SVG 代码。CLI 会拒绝无效的 XML、包装文本、Markdown 代码围栏和本地文件 URL。可以直接保存，也可以嵌入 HTML/React。

配置

• 全局 CLI 会读取 ~/.config/grok-designer/config.toml。
• 如果本地 CLI 环境支持，图像优化默认使用 WebP。
• Agent 只展示固定配置页入口和脱敏状态，不读取或操作用户真实 Key。
• 正常情况下不要检查授权状态。仅在明确调试授权时使用 grok-designer auth status。

工作流

1. 选择最小且有用的 Grok 任务：ui、ux、direction、html 或 svg。
2. 使用清晰易读的 -o 路径运行 grok-designer，并在编写最终回复或文件前获取 output_path。
3. 尽可能使用用户的原话作为任务文本。仅添加识别文件、产品范围或用户实际提出的约束所需的事实背景。
4. 对于视觉/UI 评审，调用 grok-designer ui。
5. 对于 UX、任务模型、组件选择、交互流程、摩擦点或状态反馈评审，调用 grok-designer ux。
6. 对于 UI + UX 综合评审，运行 grok-designer ui,ux，或分别运行两条命令并综合输出。
7. 对于设计图像 Markdown 或视觉方向，调用 grok-designer direction。
8. 对于新的 HTML/SVG 设计草稿，调用 grok-designer html 或 grok-designer svg；需要参考背景时，添加 -f 或 -i。
9. 对于单个手写 SVG 字标，调用 grok-designer svg；对于在一张对比图中展示多个字标候选方案，调用 grok-designer html。
10. 阅读 Grok 的输出。
11. 如果 ui 或 ux 表示需要更多背景信息，请收集所需信息，并在向用户提供建议前用相同命令重跑一次。如果无法获取这些信息，请向用户询问。
12. 实施 ui 或 ux 输出时，先查找并复用现有项目组件、选择器、类、设计令牌、变量和布局模式。如果 Grok 建议替换大范围系统或另创无关 UI，应先将其收窄到现有模式，再进行编辑。
13. 如果 Grok 在设计评审任务中转而进行代码评审，请用范围明确的目标重跑，例如：“只从 UI/UX 角度判断，不要评论代码规范或工程债。”
14. 除非用户已在本次对话中授权实施，否则在编辑项目代码前，先将建议或 HTML 模型展示给用户确认。
15. 最终回复应以 Grok 的输出为依据。你可以总结、挑选或实施有用的部分，但不要用自行生成的设计方向取代 Grok 的设计判断。

提示

• 让任务提示尽量贴近用户的请求。
• 如果用户没有指定风格、颜色、字体、布局、隐喻、视觉方向或交互模式，不要在提示中自行设定。
• 不要按 Agent 自己设定的主题拆分多次 Grok 生成。使用“第 1 个独立方案 / 第 2 个独立方案 / 第 3 个独立方案”等中性措辞，并让 Grok 自行判断如何让方案明显不同。
• 提供参考设计时，说明 Grok 可以保留哪些内容，或应避免照搬哪些内容。不要用自行提出的替代概念取而代之。
• 对于 HTML 模型，除非用户提出要求，否则不要提及资源或依赖规则。不必要的约束可能削弱 Grok 的设计判断。
• 仅传递用户明确提出的偏好，例如“深色模式”或“使用蓝色”。
• 如果任务要求设计见解、方向或 HTML 模型，不要要求 Grok 撰写冗长说明文案。尽可能让 Grok 通过可见的 UI 结构、状态、示例、层级和交互来表达想法。
• 不要把“更有设计感”理解为堆砌视觉元素。鲜明的视觉处理应服务于关键操作、品牌记忆和关键内容入口；辅助区域则应保持简洁、稳定且易于浏览。
• 让 Grok 自行决定如何避免陈词滥调。不要自行列出禁止的风格，但如果用户提出明确约束，例如“避免俗套科技感、赛博朋克感”，则应传达这些要求。
• 让 Grok 主动考虑动效、内联 SVG、材质和微交互的可能性；除非用户提出要求，否则不要指定具体的动画或材质风格。
• 不要在任务提示中添加自行编写的反模板检查清单。CLI 已会向 Grok 提供简要提醒，涉及通用 AI 美学、令人难忘的创意、克制、真实内容和 UI 文案。
• 中文提示效果良好——Grok 会用同一种语言回复。