cinematic-ui

Cinematic Layout

主要平台

此技能专为 Claude Code 和 OpenAI Codex 这两个主要运行时构建并维护。

Claude Code

• 使用 /cinematic-ui 调用。
• 项目记忆和 Claude 专属说明位于 CLAUDE.md。
• 安装路径（Windows）：C:\Users\<your-user>\.claude\skills\cinematic-layout
• 安装路径（macOS / Linux）：~/.claude/skills/cinematic-ui

OpenAI Codex / ChatGPT

• Codex 专属上下文位于 CODEX.md。
• 安装路径：$CODEX_HOME/skills/cinematic-ui

其他兼容文件：

• GEMINI.md — Gemini / Antigravity 风格的工作流
• AGENTS.md — 跨工具共享参考
• .github/copilot-instructions.md — GitHub Copilot
• .cursor/rules/cinematic-ui.mdc — Cursor（克隆后自动加载）
• .windsurf/rules/cinematic-ui.md — Windsurf（克隆后自动加载）

---

像制作电影一样设计网站，而不是把它设计成通用的落地页。 将此技能视为兼具研究与转译能力、以及设计库能力的技能。它的工作是研究电影参考，提取可用的电影化信号，再将这些信号转化为页面叙事、区块结构、动效方向和可实现的 Web 规范。 核心机制是固定的：用一位导演和一部具体电影来确定网站的情感语言，再将这种语言转化为 Web 结构和实现。不要用通用的高端品牌逻辑取代这一机制。 不要混淆电影与工作流产物。电影是研究输入和情感素材。只有将观察结果转化为 decisions.md、storyboard.md、compiled-spec.md 和实现后，计算机可执行的工作流才正式开始。

开始

• 每次调用都必须完成开始问卷，之后才能进入第 1 阶段。
• 问卷完成前，不要进入 decisions.md、导演选择、电影选择、架构或视觉规划环节。
• 所有问题和交付内容都应使用与用户相同的语言。
• 问题要简短，每次只询问一个阻碍进程的问题。
• 每次调用都要进行以下开始问卷：
  1. 询问如何开始：
  • Screenshot：根据图片或 URL 逆向分析视觉参考。
  • Step-by-step：让用户选择类型、导演和电影。
  • Surprise me：选择一组新组合；如果有项目历史，则应与之前的工作有所不同。
  2. 询问设计是否应包含图片占位符。
  3. 在进入架构设计前，询问网站的细分领域和页面列表。
• 如果环境支持结构化问卷或表单，请使用。
• 如果环境不支持结构化问卷，请用普通语言询问相同内容。
• 如果用户在初始请求中已回答部分问题，请确认或记录这些答案，只询问尚未回答的内容。
• 只有在开始问卷的所有必答项都已得到回答，或可从用户请求中明确推断后，第 1 阶段才能开始。

Demo 独特性协议

当同一用户已经使用此技能创建过一个或多个其他网站、演示或首页概念时，请使用此协议。

• 将该用户先前的输出视为设计历史背景，而不是可复用的外壳。
• 在完成阶段 1 之前，检查可获取的最近一次输出，并在 decisions.md 中记录独特性审查。
• 编写一份 Previous-work audit，指出最可能重复出现的特征。例如：
  • 左侧文案、右侧主体的主视觉
  • 顶部导航加层叠式框架面板
  • 反复出现的圆角高端卡片
  • 胶囊形元数据行
  • 带细边框的暗色奢华配色
• 为新项目编写一份 Shell-ban list。其中列出明确禁止采用的布局特征，以免新作品与先前作品过于相似。
• 在开始任何页面设计之前，为新项目确定 Primary composition family。例如：
  • 全幅舞台
  • 长廊
  • 垂直塔楼
  • 档案墙
  • 全景长板
  • 剖切巨构
• 除非用户明确要求制作有意为之的续作，否则新项目必须选择与用户最近一次同类输出不同的主要构图类别。
• 如果用户长期以来要求制作多个不同的网站，应优先确保网站外壳、主视觉姿态、版块节奏、导航姿态、密度模式和主导几何形态各不相同，而不只是更换颜色或字体。
• 如果移除颜色、字体样式和装饰效果后，新演示的线框图看起来仍与先前演示相同，则该演示不合格。
• 如果无法获取项目历史，请说明这一点，并仍然针对最常见的默认模板编写 Shell-ban list，避免设计时不自觉地采用这些模板。

运行模式

严格按四个阶段执行。不得跳过阶段。每个阶段的输出都应分别保存在工作项目中的 Markdown 文件里。

1. 阶段 1：决策
2. 阶段 2：分镜脚本
3. 阶段 3：编译后的规格说明
4. 阶段 4：构建与验证

在阶段 2 和阶段 3 中，必须按以下顺序执行，不得跳过：

1. 定义全站电影化语法。
2. 为每种主要页面角色编写独立的场景主旨。
3. 为每个页面锁定一个不可替代的标志性构图。
4. 只有在页面构图明确后，才能推导共享系统。

创建这些文件前，请先阅读 references/output-templates.md。

委派模式

• 如果环境支持子 Agent 或并行工作者，则在确定导演和影片后，默认启用它们。
• 指定一位主 Agent 负责全站电影化语法和最终一致性。
• 委派边界明确的辅助任务，例如：
  • 影片或细分领域参考资料研究
  • 针对不同页面的页面角色场景探索
  • 为互不重叠的页面角色起草编译后的规格说明
  • 在不同文件中分别进行实现或验证
• 不要让多个 Agent 各自重新定义导演、影片或全站视觉主旨。
• 将委派工作整合回同一个有明确主导方向的系统中。最终成果仍须像一部完整的影片，而不是委员会拼凑的作品。
• 除非任务过小、不适合委派，或环境不支持子 Agent，否则不得跳过委派。

渐进式加载

保持 SKILL.md 精简。仅加载当前阶段所需的参考资料。

始终先阅读

• references/library-index.md
• references/premium-calibration.md

阶段 1：决策

• 仅阅读 references/data/directors-200.md。
• 如果可以使用子 Agent，请在明确用户方向后，将电影研究、细分领域研究或参考资料拆解分配为各自范围明确的任务。
• 如果工作区中有用户之前的网站或演示，只需审阅到足以识别哪些内容不得重复。
• 如果用户从截图或在线网站开始，先检查该参考资料，并推断可能的类型、导演和电影。确认后再做决定。
• 如果可以访问网络，请在最终确定本阶段前研究选定的导演和电影。这是必需项，不是可选项。
• 使用外部来源收集更丰富的创意素材，例如：
  • 电影的色彩和光线表现
  • 摄影模式、构图逻辑和场景节奏
  • 美术设计或材质线索
  • 导演的标志性手法
  • 同一细分领域中 2-3 个高品质网站
• 如有可用的一手或权威来源，优先使用；随后再补充二手分析，以深化解读。
• 记录研究来源和简短的解读说明。不要堆砌剧情简介或泛泛的趣闻。
• 如果无法访问网络，请明确说明，并基于本地资料库继续尽力推断。将结果标记为较弱的研究成果。
• 如果用户提供了参考资料，不要照搬。阅读 references/reference-protocol.md，并将每份参考资料拆解为节奏、质感、字体、构图或图像处理等特征。
• 在 decisions.md 中记录独特性审查、禁止使用的外壳清单和主要构图类型。
• 编写 decisions.md。

阶段 2：分镜设计

• 逐个阅读以下文件，不要一次性全部阅读：
  • references/anti-convergence.md
  • references/data/hero-archetypes.md
  • references/data/narrative-beats.md
  • references/data/section-functions.md
  • references/data/section-archetypes.md
• 使用 references/data/dna-index.tsv，根据氛围、字体方向、形状语言、动效、克制程度、信息密度和材质丰富度，选取 2-3 个兼容的设计 DNA 来源。
• 仅当索引指向有潜力的来源，且需要更深入的网站级 DNA 详情时，才阅读 references/data/design-dna-db.txt。
• 在设计任何单独页面之前，先定义全站通用的电影化语法。记录以下内容：
  • 页面外壳逻辑
  • 导航姿态
  • 取景规则
  • 信息密度节奏
  • 反复出现的材质或氛围层
  • 与所选影片相符的构图类型
• 确保所选的页面外壳逻辑和构图类型不违反阶段 1 中的外壳禁用列表。
• 编写导演简报，包含：
  • 一句话视觉主张
  • 3 种标志性手法及其在网页中的转译方式
  • 精确的颜色令牌
  • 字体排印方向
  • 动效规则
• 按照 references/premium-calibration.md 进行高级感校准。
• 针对每种主要页面角色，在定义共享组件之前，先独立撰写场景主张。先将每个页面视为独立场景或海报，再将页面串联成一个网站。
• 如果可以使用子 Agent，只有在全站通用的电影化语法获批后，才将不同的页面角色分配给不同的 Agent。
• 为每个页面定义一个页面级视觉主张。这是让页面令人难忘的单一主导理念。例如：纪念碑式字体、雕塑般的光线、编辑式取景、虚空与辉光、物体即舞台。所有其他元素都必须为这一理念服务，而不是与之争夺注意力。
• 写出英雄区域主导性说明，准确解释其为何显得高档或富有电影感，而不依赖泛化渐变或通用应用 UI。
• 在引入可复用布局基元之前，为每个页面定义一种不可替代的标志性构图。
• 为每个页面规划叙事弧线，不要默认采用 Hero -> Features -> Stats -> CTA。
• 选择英雄区域原型、叙事弧线和版块原型时，应用 references/anti-convergence.md 中的反趋同系统。
• 编写 storyboard.md。
• 如果任务涉及协作或探索，在进入阶段 3 之前征求用户批准。

第 3 阶段：编译规格

• 提取最终 CSS 和 JS 前，先阅读 references/implementation-guardrails.md。
• 只阅读已批准分镜所需的具体条目：
  • references/data/camera-shots-50.md
  • references/data/interaction-effects-50.md
  • references/data/compositions.md
  • references/data/visual-elements.md
  • references/data/background-techniques.md
  • references/data/typography-cinema.md
  • references/data/color-grades.md
  • references/data/font-moods.md
  • references/data/textures.md
• 最终确定规格前，先阅读 references/anti-garbage.md。
• 在推导共享布局原语之前，先确定每个页面的标志性构图。
• 共享系统最后处理。只有在页面专属构图已明确后，才提取导航、页脚、间距节奏、字体排版、设计令牌和实用工具。
• 如果可以使用子 Agent，可将互不重叠的页面规格提取或实现任务交给它们，再由一名主 Agent 审核并整合。
• 严格控制交互预算：
  • 每个页面最多 1 个重型交互
  • 每个页面最多 2 种吸引注意力的揭示效果
  • 其余动态效果必须服从页面的视觉主旨
• 与其堆叠许多巧妙效果，不如采用更少但更有力的设计手法。
• 将高端质感线索转化为表面处理、间距、字体层级、边缘处理和氛围层，而不只是动画。
• Grid 和 flex 可作为不可见的对齐基础设施使用，但除非选定的影片明确支持这种逻辑，否则可见构图不得退化为默认的卡片矩阵。
• 编写区块规格前，先为每个页面创建入场映射。
• 每个页面中，fadeUp / opacity + translateY 最多出现 2 次。
• 如果页面区块足够多，每个页面至少使用 4 种不同的入场类型。
• 如果根据 references/implementation-guardrails.md 选定的交互效果 ID 需要 JS，则必须在 compiled-spec.md 中提供完整 JS。
• 在 compiled-spec.md 中加入 references/implementation-guardrails.md 中的 External Library Decision 区块。
• 将规格视为已完成前，先运行 references/implementation-guardrails.md 中的第 3 阶段质量检查清单。
• 如果已有合适的库条目，不要凭记忆编造核心交互或氛围效果。
• 对每个页面，记录以下各项所选库条目的来源 ID：
  • 镜头 / 揭示行为
  • 交互行为
  • 构图
  • 字体排版处理
  • 使用时的氛围 / 背景技巧
• 每个重型交互、突出揭示效果、主视觉氛围层和标志性构图，都必须在 compiled-spec.md 中注明其库条目 ID。
• 如果仍需自定义效果，明确标记为 Custom，说明库为何不足以满足需求，并确保其服从选定的影片语言。
• 提取完整的布局、入场和交互 CSS。
• 只要选定的交互需要，就必须包含完整 JS。
• 将 compiled-spec.md 作为实现的唯一事实来源。

第 4 阶段：构建与验证

• 只阅读：
  • compiled-spec.md
  • references/anti-garbage.md
  • references/implementation-guardrails.md
• 根据规格进行构建，不得临场发挥新的布局逻辑。
• 添加减少动态效果的处理和响应式行为，同时不得破坏选定的影片语言。
• 根据分镜和编译规格验证输出。
• 首次构建后优化结果时，使用 references/implementation-guardrails.md 中的 Screening Room 和 Post-Screening Adjustments 规则。

硬性规则

• 通过色彩、字体、间距、构图和动效，保留所选导演与影片的语言。
• 让导演与影片成为情感表达的主要来源。使用高端校准来提升效果，而不是覆盖所选的电影基因。
• 默认将导演姓名、影片片名、章节标记、校准术语和工作流元数据保留在工作文件中，而非面向用户的界面中。
• 除非用户明确要求元叙事／编辑式处理，否则不要在最终界面中暴露 chapter、director、film、calibrated、report build、treatment 等标签或类似流程术语。
• 让各部分的节奏有所变化。兼顾恢弘场面、密集信息和留白。
• 页面只要包含足够多的部分，就至少使用 4 种不同的入场方式。
• 相邻部分的呈现方式不要相同。
• 除纯文本块之外，还要包含视觉结构。Hero 区域至少需要 3 个视觉元素。其他大多数部分需要 1 至 2 个。
• 让每个页面围绕一个核心视觉概念清晰展开。不要让每个部分都引入新概念。
• 先定义全站的电影化语法，再设计页面场景，然后打造不可替代的页面构图，最后才构建共享系统。
• 如果同一用户之前已有输出，就要在线框图层面确保独特性。不要只更换颜色、文案或表面样式，就复用之前网站的外壳。
• 内页必须像同一部影片中的新场景，而非简化版首页。
• 每种主要页面类型都需要一种标志性构图，且不能被通用的产品营销网格或默认模板布局取代。
• 只有当首页和所有主要页面类型都通过布局、节奏、层级和构图，而不只是色彩、字体或表面样式，体现出所选导演的风格时，网站风格才算成立。
• 将网格视为基础设施，而非构图。如果某个部分可以原封不动地用作通用的二乘二或三列产品网格，那么它的构图就不够有力。
• 首先将内页设计为独立场景。共享样式应服务于这些场景，而非抹平它们的差异。
• 将克制视为一种设计手段。高端作品往往会删去 20％ 显而易见的设计手法，而不是再增加 20％ 的细节。
• 优先使用精确的设计令牌和实现说明，避免使用含糊的形容词。
• 如果无法进行网页研究或访问参考网站，请说明这一限制，并继续基于最佳推断完成工作，不要停滞不前。
• 绝不要把影片本身当作规格说明表、组件清单或计算机工作流。先从电影角度研究影片，再将其转化为网页表达。

反模式

• 除非原片确实支持，否则不要输出居中放置文案的通用渐变 Hero 区域。
• 不要在 Hero 区域或导航中加水印，展示导演姓名、影片片名、章节标签或伪装成高端微文案的工作流标签。
• 不要在每个部分都重复使用相同的悬停、显示或卡片样式。
• 不要让页面变成动效演示或特效集锦。
• 不要把参考内容当作布局模板。借鉴其品质特征，而非完整构图。
• 不要让共享容器或可复用卡片抹去页面特有的场景辨识度。
• 不要在页面级构图定稿前确定共享组件系统。
• 除非用户明确要求保持连贯，否则不要复用之前 Demo 的 Hero 布局姿态、导航布局姿态、页面节奏或主导几何形态。
• 不要一次性阅读整个库。
• 不要跳过撰写 decisions.md、storyboard.md 和 compiled-spec.md，直接从用户请求跳到 HTML。

文件指南

• 使用 references/library-index.md 确定要加载哪个库。
• 使用 references/output-templates.md 组织交付内容。
• 使用 references/premium-calibration.md 判断如何让页面显得高端，同时不破坏电影感概念。
• 当用户提供视觉参考，但希望避免照搬模板时，使用 references/reference-protocol.md。
• 编码前，使用 references/anti-garbage.md 进行最终检查。