CC Design — CC设计
v0.1.0高保真HTML设计和原型技能，适用于登陆页面、幻灯片、移动模拟、交互式原型、仪表盘探索、设计方向咨询和设计审查工作。 当Codex需要设计一个屏幕、使界面看起来精致、探索多个视觉方向、在构建前推荐一个样式方向、适应现有的品牌样式、批评一个设计或交付一个可审查的基于HTML的视觉文物时使用。 当用户提到演示、设计系统、线框图、UI模拟、动态研究、设计哲学、样式选择或要求“让它看起来好”时，也使用此技能。 不适用于纯内容策略、纯写作或单独的位图图像生成。
by 运行时依赖
安装命令
点击复制技能文档
CC 设计概述 这个 Skill 只处理一类任务：把视觉需求做成可预览、可截图、可迭代的 HTML 设计产物 它覆盖的是：落地页、演示稿 / slide deck、dashboard / UI mockup、移动端 screen / onboarding、可点击交互原型、视觉方向探索与对比 它不处理：纯文案策划、纯内容写作、纯图片生成、Figma 文件生产 如果用户真正缺的是内容策略、文章、脚本或图片素材，不要在这里偷偷扩 scope。
快速开始 先判断输出类型：landing page、deck、mobile mockup、prototype，还是视觉探索 先看项目里有没有现成设计系统、token、组件、品牌文档或现有页面 再决定加载哪些 references，必要时复制 assets/templates/ 下的模板 写 HTML 之前，先明确视觉焦点、情绪基调、层级和留白策略 完成后默认做结构检查和截图检查；需要导出时再调用脚本
Routing Guide 任务类型 先读什么 可复用模板 重点检查 任意设计任务 references/design-excellence.md
- 视觉层级是否成立
- 反馈是否可执行
- token 是否完整且被真正使用
- 文件是否实际生成
默认合同 默认采用以下约定，除非用户另有说明： 输出语言：中文说明 核心交付：HTML 文件 默认优先复用现有设计上下文，而不是凭空发明新风格 如果任务提到真实品牌或产品，默认先核实事实与资产，再设计 如果没有设计系统，先用可控 token 和字体组合建立视觉基线 如果需求模糊，默认先提 3 个方向而不是直接拍板 默认至少提供 2-3 个方向中的一个可比较入口，或通过 tweaks 暴露变化 交付前默认检查 console、结构和截图 需要导出时，优先导出 PDF / PPTX / 单文件 HTML，而不是口头说“可以导出”
工作流程 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
硬性规则 Do not： 在已有设计系统时无视上下文另起炉灶 在真实品牌 / 产品任务里跳过事实核验和资产采集 把视觉任务做成普通模板页 在需求模糊时直接默认一个 generic 方向 用一堆花哨效果掩盖信息层级问题 明明需要多方向，却只给一个含糊方案 没截图、没检查就直接交付 把图片生成需求硬塞进 HTML 设计流程 Always： 先明确输出类型和约束 先搜上下文，再设计 具体品牌任务先核实事实与资产 先做视觉判断，再写代码 在大任务里先给 assumptions / placeholder，再继续 需要模板时优先复用模板 交付前至少做一轮结构检查和截图检查 诚实说明哪些导出 / 预览环节已验证，哪些还没验证
资源映射 references/question-protocol.md 范围不清时，用这个收口需求。 references/design-context.md 现有系统、代码、截图和品牌上下文的采集顺序。 references/brand-asset-protocol.md 具体品牌 / 产品任务的事实核验与资产协议。 references/junior-designer-workflow.md 假设、placeholder、中途回看和分阶段推进。 references/design-direction-advisor.md 需求模糊时先给 3 个方向。 references/design-excellence.md 写代码前先做视