ClawHub

CC Design

Other

High-fidelity HTML design and prototype skill for landing pages, slide decks, mobile mockups, interactive prototypes, dashboard explorations, design-direction advising, and design review work. Use when Codex needs to design a screen, make an interface look polished, explore multiple visual directions, recommend a style direction before building, adapt an existing brand style, critique a design, or deliver a reviewable HTML-based visual artifact. Also use when the user mentions presentations, design systems, wireframes, UI mockups, motion studies, design philosophy, style selection, or asks to 'make it look good'. Do not trigger for pure content strategy, pure writing, or bitmap image generation alone.

Install

openclaw skills install cell-cc-design

CC Design

Overview

这个 Skill 只处理一类任务：

  • 把视觉需求做成可预览、可截图、可迭代的 HTML 设计产物

它覆盖的是：

  • 落地页
  • 演示稿 / slide deck
  • dashboard / UI mockup
  • 移动端 screen / onboarding
  • 可点击交互原型
  • 视觉方向探索与对比

它不处理：

  • 纯文案策划
  • 纯内容写作
  • 纯图片生成
  • Figma 文件生产

如果用户真正缺的是内容策略、文章、脚本或图片素材，不要在这里偷偷扩 scope。

Quick Start

  1. 先判断输出类型：landing page、deck、mobile mockup、prototype，还是视觉探索。
  2. 先看项目里有没有现成设计系统、token、组件、品牌文档或现有页面。
  3. 再决定加载哪些 references，必要时复制 assets/templates/ 下的模板。
  4. 写 HTML 之前，先明确视觉焦点、情绪基调、层级和留白策略。
  5. 完成后默认做结构检查和截图检查；需要导出时再调用脚本。

Routing Guide

任务类型先读什么可复用模板重点检查
任意设计任务references/design-excellence.md-视觉层级是否成立
任务模糊 / 需要先选风格references/design-direction-advisor.mdassets/templates/design_canvas.jsx 可选3 个方向是否真的不同
需要设计评审references/design-review-guide.md-反馈是否可执行
没有现成设计系统references/frontend-design.md按场景选择是否落入通用 AI 风
有现成设计系统 / 代码 / 品牌资产references/design-context.md按场景选择是否真的复用了上下文
具体品牌 / 产品任务references/brand-asset-protocol.md + references/brand-style-loader.md按场景选择事实和资产是否核实
品牌风格克隆references/brand-style-loader.md按场景选择品牌气质是否对味
Landing page / 产品页references/design-patterns.mdassets/templates/browser_window.jsx 可选响应式与首屏层级
Slide deckreferences/starter-components.mdassets/templates/deck_stage.js固定画布缩放与翻页
多方案探索references/tweaks-system.mdassets/templates/design_canvas.jsx方案切换是否清晰
Mobile mockupreferences/starter-components.md + references/interactive-prototype.mdassets/templates/ios_frame.jsx / android_frame.jsx安全区、触达区、设备框
Interactive prototypereferences/interactive-prototype.md + references/react-babel-setup.md按场景选择导航、状态、交互是否成立
动画 / motion studyreferences/starter-components.md + references/react-babel-setup.mdassets/templates/animations.jsx时间轴和播放状态
设计系统 / token 体系references/design-system-creation.md-token 是否完整且被真正使用
需要导出references/platform-tools.md-文件是否实际生成

Default Contract

默认采用以下约定，除非用户另有说明：

  • 输出语言：中文说明
  • 核心交付：HTML 文件
  • 默认优先复用现有设计上下文，而不是凭空发明新风格
  • 如果任务提到真实品牌或产品，默认先核实事实与资产，再设计
  • 如果没有设计系统，先用可控 token 和字体组合建立视觉基线
  • 如果需求模糊，默认先提 3 个方向而不是直接拍板
  • 默认至少提供 2-3 个方向中的一个可比较入口，或通过 tweaks 暴露变化
  • 交付前默认检查 console、结构和截图
  • 需要导出时，优先导出 PDF / PPTX / 单文件 HTML，而不是口头说“可以导出”

Workflow

Step 0: Verify Facts for Real-World Entities

如果任务里出现了具体品牌、产品、公司或已命名服务：

  • 先核实它是否存在、是否已发布、当前形态是什么
  • 先找 logo、产品图、UI 截图或官方资产
  • 不要直接凭印象写“像某某品牌”

需要时读 references/brand-asset-protocol.md。

Step 1: Scope the Request

至少先弄清：

  • 最终产物是什么
  • 几屏 / 几页 / 几个方向
  • 保真度要到什么程度
  • 有没有现成品牌或参考对象
  • 是否需要导出
  • 是先做方向建议，还是直接做成品

如果信息不够，读 references/question-protocol.md。

Step 2: Acquire Design Context

开始做之前，先主动搜：

  • 现有 HTML / CSS / 组件
  • token 文件 / 设计系统说明
  • 已上线页面
  • 品牌文案或视觉参考

已有系统时，优先复用它的颜色、字体、间距、圆角、阴影和组件语言。

如果上下文很少，先读 references/design-context.md。

Step 3: Lock the Visual Intent

写代码之前，先用 references/design-excellence.md 的思路回答这些问题：

  • 这一屏最重要的视觉焦点是什么
  • 目标情绪更偏信任、兴奋、专业还是创意
  • 层级如何建立
  • 留白和节奏如何组织
  • 颜色和字体如何配合
  • 是否需要多个方向并列比较

如果没有设计系统，再读 references/frontend-design.md。

如果用户还没能决定方向，不要硬做，先读 references/design-direction-advisor.md。

Step 4: Work Like a Junior Designer, Not a Black Box

开始实现时，不要直接闷头做完整稿。

优先做：

  • 一版 assumptions + placeholder
  • 一次早期展示
  • 用户确认后的主版本推进
  • 中途再展示一次
  • 最后才做 polish

需要更细流程时，读 references/junior-designer-workflow.md。

Step 5: Build with the Right Level of Structure

按场景选择最省力的方式：

  • deck 用 assets/templates/deck_stage.js
  • 多方案对比用 assets/templates/design_canvas.jsx
  • 手机稿用 assets/templates/ios_frame.jsx 或 android_frame.jsx
  • 浏览器场景用 assets/templates/browser_window.jsx
  • 桌面工具窗口用 assets/templates/macos_window.jsx
  • 动画场景用 assets/templates/animations.jsx

如果要写 React 内联原型，读 references/react-babel-setup.md。

Step 6: Add Variation without File Explosion

如果用户要多个方向，不要默认拆成一堆 HTML。

优先：

  • 用 design_canvas 并列展示
  • 用 tweaks 面板切换颜色、排版、布局、文案层级

需要时读 references/tweaks-system.md。

Step 7: Verify Before Delivery

完成后必须做验证，不要“写完即交”。

默认检查：

  • 有没有 console error / 关键 warning
  • 主要结构有没有渲染出来
  • 截图里层级、留白、对比和对齐是否成立
  • slide / prototype 的导航和缩放有没有坏掉

详细流程见 references/verification-protocol.md。

Step 8: Review When Asked, Export When Needed

如果用户要求 review、比较多个方向、或交付前做专家审查：

  • 从方向匹配、层级、做工、功能性、辨识度 5 个维度看
  • 给出可执行问题，不要只说“还差点意思”
  • 最后附 Quick Wins

需要时读 references/design-review-guide.md。

如果用户需要导出，再读 references/platform-tools.md 并调用脚本：

  • node skills/cc-design/scripts/gen_pptx.js
  • node skills/cc-design/scripts/open_for_print.js
  • node skills/cc-design/scripts/super_inline_html.js

Hard Rules

Do not:

  • 在已有设计系统时无视上下文另起炉灶
  • 在真实品牌 / 产品任务里跳过事实核验和资产采集
  • 把视觉任务做成普通模板页
  • 在需求模糊时直接默认一个 generic 方向
  • 用一堆花哨效果掩盖信息层级问题
  • 明明需要多方向，却只给一个含糊方案
  • 没截图、没检查就直接交付
  • 把图片生成需求硬塞进 HTML 设计流程

Always:

  • 先明确输出类型和约束
  • 先搜上下文，再设计
  • 具体品牌任务先核实事实与资产
  • 先做视觉判断，再写代码
  • 在大任务里先给 assumptions / placeholder，再继续
  • 需要模板时优先复用模板
  • 交付前至少做一轮结构检查和截图检查
  • 诚实说明哪些导出 / 预览环节已验证，哪些还没验证

Resource Map