design-studio

设计工作室

统一设计技能。一个入口、两种引擎、一个设计系统文件。

DESIGN.md：设计系统文件

在建立或更改可复用的视觉规则时，创建或更新 DESIGN.md。如果是评审或不会改变这些规则的小型编辑，则使用现有设计上下文，完成所请求的评审或编辑。开始设计工作前，先阅读现有的 DESIGN.md。

格式

遵循 Google DESIGN.md 规范。结构：

---
version: alpha
name: <Project Name>
colors:
  primary: "#hex"
  secondary: "#hex"
  tertiary: "#hex"
  neutral: "#hex"
typography:
  h1:
    fontFamily: <Font Name>
    fontSize: 48px
    fontWeight: 600
    lineHeight: 1.1
  body-md:
    fontFamily: <Font Name>
    fontSize: 16px
    fontWeight: 400
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  lg: 32px
components:
  button-primary:
    backgroundColor: "{colors.tertiary}"
    textColor: "#fff"
---

## Overview
<Brand personality, audience, emotional intent>

## Colors
<Palette rationale and usage rules>

## Typography
<Type hierarchy and pairing logic>

## Layout
<Grid system, spacing rhythm>

## Elevation & Depth
<Shadows, layers, or flat alternatives>

## Shapes
<Corner radius language>

## Components
<Button, card, input, chip specs with token refs>

## Do's and Don'ts
<Guardrails>

DESIGN.md 生命周期

场景	操作
不存在 DESIGN.md，且任务需要确立视觉规则	将 shared/DESIGN-template.md 复制到项目根目录，重命名为 DESIGN.md，并在本次会话中填写
存在 DESIGN.md，用户提出“重新设计”	先运行 shared/redesign-protocol.md——判断是保留还是全面改造，审查当前状态——然后据此重写 DESIGN.md
存在 DESIGN.md，用户希望进行更改	先阅读，然后扩展或修改特定章节。保留未更改的令牌。
存在 DESIGN.md，同一项目有新任务	先阅读，除非用户另有要求，否则与现有令牌保持一致

铁律：开始工作前，务必先阅读现有的 DESIGN.md。设计应在已有基础上发展，而不是从零开始。

流程文件的存放位置

DESIGN.md 是唯一应放在项目根目录中的设计文件。设计会话生成的所有工作文件都应放在 docs/design/ 中：

文件	引擎	内容
docs/design/decisions.md	cinematic-ui	第 1 阶段——导演、影片参考、外壳禁用清单、独特性审查
docs/design/storyboard.md	cinematic-ui	第 2 阶段——逐场景设计方案
docs/design/compiled-spec.md	cinematic-ui	第 3 阶段——唯一实现依据（Web）
docs/design/slide-spec.md	cinematic-ui	第 3 阶段——用于 PPTX 时替代 compiled-spec.md
docs/design/product-facts.md	practical	设计前收集并核实的产品事实
docs/design/brand-spec.md	shared	固定的品牌素材路径和提取的颜色

如果该目录不存在，请创建它。本技能及其子技能中的裸文件名均相对于 docs/design/ 解析。

这些是会话工作状态，不是项目素材。用户打开仓库根目录时，应该看到 DESIGN.md 和自己的文件，而不是某次设计运行产生的六个中间产物。

路由决策

阅读 DESIGN.md（或决定创建一个）后，路由到合适的引擎：

信号	引擎	子技能
导演、电影、影院、编辑感	Cinematic	cinematic-ui/GUIDE.md
具有视觉叙事的高端静态网站	Cinematic	cinematic-ui/GUIDE.md
原型、模型、交互式演示	Practical	practical/GUIDE.md
PPT、幻灯片、演示文稿、簡報	Practical	practical/GUIDE.md
动画、动态效果、MP4、GIF	Practical	practical/GUIDE.md
专家评审、点评、评分	Practical	practical/GUIDE.md
信息图表、数据可视化	Practical	practical/GUIDE.md
App/iOS/Android 原型	Practical	practical/GUIDE.md
快速设计变体（3 个方向）	Practical	practical/GUIDE.md
模糊需求 /“做点好东西”	Practical（备用顾问）	practical/GUIDE.md
带有特定品牌的品牌素材	Either — 使用共享品牌协议	视输出类型而定
从零开始创建新品牌形象（Logo 概念设计、品牌套件展示板）	Practical	practical/GUIDE.md → practical/references/brand-identity-board.md
高转化率落地页（明确的 CTA / 价值主张 / 转化目标）	移交	landing-page-studio 技能 — 它会读取本技能的共享规则和风格库，然后运行自己的转化工作流
基于 Web 的演示文稿 — 实时演示、演讲者模式、部署到 URL（而非可编辑的 PPTX）	移交	open-slide-studio 技能 — 本技能提供 DESIGN.md 和风格方向；它负责 open-slide 工作区、创作移交和交付

需求模糊时：问一个问题：“你有想作为视觉参考的电影或导演吗？还是希望我推荐一些方向？”

会话流程（本文件驱动每次会话）

1. 上下文 — 如果 DESIGN.md 存在，则阅读它（见上方生命周期表）；当任务确立了视觉规则时，使用 shared/DESIGN-template.md 创建一个。

2. 共享规则 — 阅读 shared/anti-slop.md、shared/hard-rules.md、shared/guardrails.md、shared/brand-asset.md、shared/verification.md。这些规则适用于每条路由。

3. 路由 — 从“路由决策”表中选择引擎，然后只阅读该引擎的 GUIDE 并运行其工作流：

   • Cinematic → cinematic-ui/GUIDE.md — 导演 + 电影 → 电影化语法 → Web 结构，分 4 个阶段：决策 → 故事板 → 编译规范 → 构建。最适合落地页、品牌网站、编辑式版面。参考资料：cinematic-ui/references/（200 位导演、主视觉原型、构图、调色）。
   • Practical → practical/GUIDE.md — 任务路由器 → 品牌协议 → 备用顾问 → 初级设计师。最适合原型、演示文稿、动画、评审、信息图表。参考资料：practical/references/（40 种风格、动画常见问题、幻灯片、评审指南）。

   GUIDE 是执行手册，而非独立技能：它在本次会话中运行，并遵循共享规则以及已加载的 DESIGN.md 上下文。本文件继续负责步骤 4–6。

4. 设计期间 — 将新增或变更的可复用颜色、排版、间距和组件规则记录到 DESIGN.md 中。

5. 交付前 — 运行 shared/verification.md；如果视觉规则发生变化，确保 DESIGN.md 反映最终设计。

6. 再次访问时 — 先阅读 DESIGN.md。在此基础上扩展，不要从头开始。

混合任务

当两种引擎都适用时，选择与主要输出相符的引擎。必要时参考另一个引擎的原则。切勿混用工作流。

PPTX

两种引擎都能生成 PPTX。Cinematic 原生使用 PptxGenJS。Practical 使用 HTML 演示文稿 → PptxGenJS 导出。请阅读所选路由对应的 PPTX 参考资料。