Communitygithub.com

前端应用构建器

用于从零开始打造新的前端应用、仪表盘、游戏、创意网站、英雄区域和视觉驱动的UI,或在用户明确要求重新设计/重新样式/现代化时使用。基于清晰、通透、高品位的图像生成概念设计,包含特定部分的参考、忠实实现和浏览器测试。

前端应用构建器 是什么?

该技能是一个专业级前端应用构建器,集高级设计构思与精准代码实现于一体。它专为创建视觉驱动的用户界面而设计,涵盖从完整的仪表盘、游戏、创意网站到单个英雄区域和UI重新设计等场景。技能的核心标准是:首先作为高级前端设计师,利用图像生成工具创作出干净、通透且具有鲜明视觉概念的完整设计稿;然后作为工程师,严格遵循已批准的设计规范进行实现,并通过浏览器测试确保最终UI与设计稿达到10/10的像素级匹配。它支持在Codex等平台上运行,并智能地与其他已安装的技能(如OpenAI API密钥管理)协同工作。技能内置了严格的规则,例如优先使用图像生成进行视觉概念设计、设计完成前不写代码、构建小型设计系统以确保一致性,以及在最终交付前进行设计稿与浏览器截图的直接对比审查。它默认采用React + Vite栈(适用于复杂应用),并提供了详细的图像生成工作流、质量标准和视觉方向默认值,以确保输出兼具专业产品的设计感与可构建性。

兼容平台~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/illuminatedworm/terrarium-tavern/tree/HEAD/.agents/skills/frontend-app-builder

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

前端应用构建器 是做什么的?

使用此技能来创建精致的前端应用、仪表盘、游戏、创意网站、英雄区域、重新设计以及其他视觉驱动的UI。首先扮演高级前端设计师,然后作为工程师实现已批准的设计规范。

核心标准

此技能的两个优先级高于其他一切:

  1. 首先创建足够多的精美图像生成设计:清晰、通透、独特、完整、可读,必要时为特定部分设计,且默认不重复。
  2. 在已接受的设计和浏览器实现达到10/10匹配之前不要停止。持续修复视觉、交互、响应式、资源和排版差异,直到view_image对比能通过代理认可。

硬性规则

  1. 除非用户明确选择退出,或任务是在现有设计系统内进行小UI修复,否则必须使用图像生成进行视觉概念设计。
  2. 在编码之前设计完整的请求界面。对于一个完整的页面、应用、仪表盘、游戏或产品界面,仅有一个头部或英雄概念是不够的。对于多节网站和长着陆页,倾向于协调的逐节概念,外加一个可选的概览用于把握节奏,而不是生成一张会丢失细节的高大图像。对于应用、仪表盘、游戏或紧凑的产品界面,首先生成完整的主屏幕以及任何所需的状态、响应式或资源概念。
  3. 在Codex内部,对于多节网站概念化,默认每个主要部分生成一张全新的、大尺寸、可读的图像生成截图。如果请求包含1-10个部分,预期大约需要1-10张主要部分图像。当文本、按钮、卡片结构、排版、间距或颜色太小无法提取时,生成额外的部分/细节截图。不要裁剪或放大旧的整页图像作为主要参考;重新生成一张保留相同设计系统的独立部分或细节图像。
  4. 在计划模式下,先生成设计,然后使用request_user_input获取设计批准,然后再计划实现细节。
  5. 一旦设计被接受,该概念即成为生产设计规范。实现过程中不得进行创意发挥:不要重新解释布局、可见文案、层级、容器模型、样式、图像、密度或部分,除非用户批准或存在具体障碍需要调整。通用设计启发式方法永远不能覆盖已接受的概念。
  6. 完成标准是代理级认可的忠实实现:10/10的保真度加上生产级代码。如果浏览器渲染的UI会收到设计评审意见,请继续修复。
  7. 在编码之前,根据接受的图像构建一个小型设计系统:令牌、排版、组件家族、变体、间距、图标处理和容器规则。包括内容排版和UI界面排版(用于工具、编辑器和仪表盘)。基于该系统进行实现,以确保重复元素的风格一致。
  8. 对于新的复杂应用UI,如仪表盘、管理工具、编辑器、数据密集型工具和多面板产品界面,默认使用 React + Vite,除非用户指定了其他框架、现有仓库已指定了一种框架,或者任务明确是单文件/静态交付物。
  9. 默认禁止在主标题上方使用英雄区域的眼眉、引子、前置标题、徽章或药丸形标签。仅当用户明确要求或已接受/参考设计中已包含时才使用。
  10. 首先在浏览器插件 / 内置浏览器中验证。仅当浏览器/IAB不可用或不可靠时,才使用Playwright Chromium,并说明回退原因。
  11. 最终交付被阻止,直到你使用view_image同时查看已接受的概念和最新的浏览器截图。此步骤不可跳过,也不能仅用浏览器检查替代。直接判断这对组合:这是否是代理级认可的忠实实现?一个优秀的、技艺精湛的设计代理公司是否会认可这个基于已接受设计的精确实现?如果不是,请继续修复。
  12. 在交付前移除临时的QA工件,除非用户或任务明确要求保留。

与其他已安装技能的协调

此技能负责视觉概念化和忠实的前端实现。当应用需要前端设计之外的能力时,使用其他已安装的技能。提供商的设置不应阻止不涉及提供商支持行为的图像生成概念化、静态UI工作或设计评审,但提供商支持行为的实现和验证应通过该能力的已安装技能进行协调。当有其他已安装技能涵盖该设置时,避免使用占位符设置说明。

对于AI/模型生成的输出,当openai-developers:openai-platform-api-key可用时,优先使用它,除非用户指定了其他提供商或明确表示不使用OpenAI。当该技能可用时,始终使用其凭据流程,而不是使用假密钥、占位符环境变量或手动API密钥设置说明。

图像生成工作流

阅读并遵循已安装的 @imagegen 技能。对于网站特定的简报指导,请使用 references/imagegen-website-concepts.md。

在调用图像生成之前:

  • 将用户的具体需求复制到简报中:产品/页面的目的、受众、所需的部分或状态、工作流、提供的文案、导航标签、CTA标签、数据字段、所需媒体、响应式需求和实现约束。
  • 询问完整的请求界面:完整的页面、应用屏幕、仪表盘、游戏屏幕、或协调的部分/状态集合。如果交付物不仅仅是一个英雄区域,说明概念必须包括下游部分、状态或响应式延续。如果部分数量已知或已暗示,说出每个需要自己概念截图的部件/状态的名称。
  • 重复实现约束:代码原生应用UI文本和控件、完全渲染的产品/背景资源(带其自身文本和品牌)、可分离资源、可复用的组件家族、有意的容器模型、没有默认的卡片网格、没有发明的英雄眼眉/踢脚/徽章/药丸,以及实用的HTML/CSS/组件实现。
  • 保留用户内容、截图或现有应用中的信息架构。不要让图像生成发明无关的部分、虚假指标、新的产品声明、额外的仪表盘、新的导航或不同的产品故事。
  • 对于多节网站或长着陆页,默认每个主要部分生成一张协调的概念图像。仅在结构和节奏上使用可选的概览;永远不要依赖一张巨大的压缩面板,因为它会使文本、按钮细节、卡片结构、间距或排版难以分析。
  • 对于密集的应用、仪表盘、编辑器、产品界面和复杂的部分,为那些在单个全屏图像中变得不可读的区域生成单独的状态或细节概念:表格、侧边栏、检查器、模态框、工具栏、图表、表单、卡片、定价块、推荐或媒体模块。
  • 如果任何概念截图对于实现来说太小、模糊、裁剪、拥挤或模糊不清,在编码前生成一张新的独立部分/状态/细节截图。保持相同的调色板、排版风格、组件家族、资源处理、密度和部分顺序。不要裁剪、切片、缩放或重复使用早期图像的一小部分作为事实来源。
  • 对于游戏,除了概念图之外,规划一个专门的图像生成资源阶段:透明角色/状态精灵或精灵图、地形/平台瓦片、收藏品、障碍物、目标/检查点对象、道具,以及2-3个视差/背景层(当环境具有深度时)。HUD文本、得分、控制、物理和碰撞保持代码原生。

拒绝或迭代那些仅包含头部而要求完整界面的概念、杂乱的概念、通用的概念、重复的概念、规格不足的概念、不可读的概念、过度装饰的概念、包含未明确要求或参考中未出现的英雄眼眉/踢脚/徽章/药丸的概念,或者不切实际无法忠实实现的概念。

设计质量标准

概念应看起来像高级产品设计师制作的专业产品模型:

  • 一个清晰的创意理念或视觉观点。
  • 强有力的第一视口,具有清晰的提议、产品信号和主要操作。
  • 全页节奏:部分、状态、过渡和移动视图感觉像是作为同一系统设计的,没有重复的卡片堆叠或重复的部分公式。
  • 连贯的部分间流程:通过共享间距、调色板、排版节奏、媒体处理和微妙的过渡连接部分,而不是发明主要的新UI组件。
  • 优秀的排版:清晰的层级、比例、字重、行高、标签处理,以及从不依赖于浏览器默认大小的控制/界面文本。
  • 有意的空白和密度;没有填充卡片、英雄眼眉/踢脚标签、药丸、徽章、虚假指标或图标行,除非明确请求或已接受的设计中包含。
  • 默认更简洁:使用更少但更强的视觉元素,而不是用插画、图标、装饰性小部件或复杂的UI界面填满页面。
  • 连贯的视觉系统:调色板、间距、圆角、边框、阴影、渐变、图标样式、图像和组件几何形状。
  • 图标存在时,图标保真度很重要。匹配已接受设计的图标隐喻、笔画粗细、填充样式、拐角形状、大小、颜色、对齐和间距,而不是替换为通用的附近图标。
  • 颜色保真度是强制性的。匹配已接受设计的实际背景色、表面色、文本色、边框色、阴影色和强调色;如果设计使用白色背景,则使用白色,而不是奶油色、象牙色、米色、暖灰色或任何柔化的偏白替代色。
  • 英雄区域媒体处理必须匹配已接受的设计。如果概念中的英雄图像没有颜色叠加或色调,则实现不得添加。仅使用边缘淡入淡出、蒙版或背景渐变将图像边缘混合到页面中;不要用颜色叠加覆盖图像。
  • 高品质生成的资源,用于标志、品牌标记、英雄图像、产品渲染、背景场景、插画、纹理、海报、头像、空状态以及游戏精灵/瓦片/背景层。产品/背景资源应完全渲染,具有一致的品牌标识和资源内文本(当该文本属于资源时)。
  • 有目的性的动效,用于阐明层级、揭示状态或使产品感觉更真实。
  • 当用户未提供确切文案时,使用具体而非通用的文案。

默认采用干净、通透、有品味、7/10的创意度:足够独特以显得经过设计,又足够克制以便于构建,并且不重复。将“干净”理解为经过编辑和可读,而非空荡或无菌。

视觉方向默认值

当用户没有提供更强的艺术指导时,使用这些默认值。根据产品类型进行调整,而不是强制每个应用都采用营销网站风格。

  • 基线:约7/10创意度,低至中密度,慷慨的间距,高实现清晰度,高排版纪律,以及当领域受益于真实视觉效果时的图像主导时刻。
  • 在生成概念之前,选择一个连贯的视觉方向:一个主题范式、背景特征、排版特征、英雄或主屏幕架构、部分/应用节奏、2-4个标志性组件主题,以及1-2个动效线索。坚持组合体,使设计感觉有意为之,而不是通用模板。
  • 英雄或第一视口:保持一个明显的焦点、一个简短可读的标题或主要任务、克制的辅助文案、一个可见的主要操作,以及足够的负空间以便在小笔记本电脑上工作。不要用统计数据、筹码、徽章、虚假控件或竞争的小面板挤满开场视图。
  • 头部简洁性:默认使用一个干净的品牌标记、必要的导航和一个主要操作或控件。避免在头部使用大量图标导航、额外按钮、搜索栏、状态小部件、分段控件、装饰性插画或密集的产品界面,除非用户明确要求或产品工作流需要它们。
  • 视觉经济性:倾向于使用一两个高质量图像或插画时刻,而不是许多小型装饰性视觉元素。仅在图标能澄清导航、控件或产品含义时使用。
  • 容器纪律:避免嵌套卡片、每个部分周围都用巨大的圆角包裹、默认的便当/卡片网格和过度框架的仪表盘,除非概念或产品类型真正需要它们。倾向于开放的布局、带状、轨道、列表、表格、画布或单一有目的的框架移动。
  • 部分节奏:长页面应在保持一个连贯品牌系统的同时,变化密度、图像与文本比例、对齐、比例、空白和视觉节奏。不要在整个页面重复相同的居中块或左文本/右卡片的公式。
  • 部分连续性:当多个部分概念需要变成一个页面时,使用现有设计系统中的连接组织:排水沟、带状、对齐、重复的排版、重复的媒体框架、颜色节奏和微小的过渡间距变化。不要发明主要的新轮播、手风琴、定价卡片、仪表盘、表单、导航系统、功能网格或其他组件家族,除非用户请求或已接受的概念显示了它们。
  • 媒体框架:生成的图像通常应位于清晰、易于实现的框架内,具有稳定的宽高比、一致的裁剪逻辑、圆角、阴影和间距。避免随意的图像大小或拼贴混乱,除非用户明确要求这种方向。
  • UI限制:小标签、实用药丸、伪系统标记、虚假指标和装饰性仪表盘术语仅在它们能澄清产品时才被允许。如果它们只是视觉填充物,在接受前应将其移除。

概念审查模式

仅当用户要求首先生成概念、审查选项或等待批准时使用。

  • 生成并展示概念。
  • 迭代直到用户批准。
  • 在用户仍在审查时不要实现。
  • 一旦批准,将概念视为活动规范

…

[因翻译截断]

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相关技能