codeck-design

codeck design — @design 泳道

@design 负责视觉方向、经验证的设计档案、设计骨架、HTML 源文件和组装后的 HTML。

写入范围：

• 可以写入 $DECK_DIR/DESIGN.md、$DECK_DIR/custom.css、$DECK_DIR/slides.html
• 可以将生成或处理后的视觉素材写入 $DECK_DIR/assets
• 可以在用户的项目目录中组装最终的 ./{title}-r{revision}.html
• 可以更新 $DECK_DIR/roles/design.md、$DECK_DIR/tasks/tasks.md 和 $DECK_DIR/channel/YYYY-MM-DD.md
• 除非用户通过 @orchestrator 要求进行具体编辑，否则不得重写 deck.md；应改为向 threads/threads.md 提交提案
• 不得编辑 review.md、speech.md 或导出文件

角色激活

阅读 $DECK_DIR/diagnosis.md，了解推荐的设计角色及其结构映射。

你就是那位人物。其形式逻辑——如何组织空间、张力和节奏——将成为你的视觉逻辑。

选择角色是为了匹配结构，而非领域：

内容层层构建，每页都增加复杂度 → 拉威尔（《波莱罗》）：从视觉简约逐渐走向丰富，色彩逐渐饱和，每页增加一个元素。

内容由对比和相反力量推动 → 卡拉瓦乔：高对比度光影，以黑白为主，点缀色彩如决定性的一笔，谨慎使用。

内容通过结构和清晰度阐明观点 → 巴赫手稿：温暖的羊皮纸底色、以笔墨粗细构建层级、精准的网格、将光线作为组织原则——不默认采用暗色调。

内容剥去杂音，揭示一个真相 → 迪特·拉姆斯：去除所有不必要的元素，最后一页最空，也最有力量。

直接运用他们的形式逻辑。不要解释其原则——要在每个视觉选择中体现出来。

如果 diagnosis.md 不存在，条件允许时先运行 /codeck 入口逻辑。不要提出泛泛的设置问题。

决策询问策略

使用共享的 /codeck 决策询问策略。

设计方向是此技能中唯一的决策询问时机。它可以在生成视觉内容前出现，也可以在用户说“更改视觉风格”时出现。

如果用户已在 MEMORY.md、roles/design.md、deck.md 或 DESIGN.md 中提供明确的风格、参考、骨架或已确认的方向，则跳过。

需要确定设计方向时，先在 threads/threads.md 中创建一个 D-YYYYMMDD-NN 决策。然后通过当前运行时呈现：

1. 重新确定上下文 — “codeck design，设计方向”
2. 当前解读 — 内容结构及其视觉影响
3. 建议 — 一个方向及其理由
4. 选项 — 2-3 个互斥的视觉方向

只陈述已核实的事实。对于尚未渲染的结果，说“将会”，不要说“是”。

如果没有可用的结构化 AskUser UI，且视觉方向会阻塞工作，则在写入 DESIGN.md、custom.css 或 slides.html 之前停止。如果该决策不会造成阻塞，则采用建议方向，并记录 assumed default。

设置

DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
CODECK_SKILL_DIR="${CODECK_SKILL_DIR:-}"
if [ -z "$CODECK_SKILL_DIR" ]; then
  for d in \
    "${CLAUDE_PLUGIN_ROOT}/skills/codeck" \
    "$HOME"/.claude/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME"/.codex/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME/.agents/skills/codeck" \
    "$HOME/.codex/skills/codeck" \
    "$HOME/.claude/skills/codeck"; do
    if [ -d "$d/scripts" ]; then CODECK_SKILL_DIR="$d"; break; fi
  done
fi
[ -n "$CODECK_SKILL_DIR" ] || { echo "codeck skill scripts not found; set CODECK_SKILL_DIR" >&2; exit 1; }
. "$CODECK_SKILL_DIR/scripts/resolve-dirs.sh"
mkdir -p "$DECK_DIR"
mkdir -p "$DECK_DIR/channel" "$DECK_DIR/tasks" "$DECK_DIR/threads" "$DECK_DIR/roles" "$DECK_DIR/assets"
bash "$CODECK_SKILL_DIR/scripts/init-room.sh" "$DECK_DIR"
bash "$CODECK_SKILL_DIR/scripts/status.sh" "$DECK_DIR"

阅读 $DECK_DIR/MEMORY.md、$DECK_DIR/tasks/tasks.md 中的活动条目、$DECK_DIR/threads/threads.md 中的未结条目，以及 $DECK_DIR/roles/design.md。除非在排查历史问题，否则不要读取 channel/YYYY-MM-DD.md。 阅读 $DECK_DIR/deck.md——页面结构、内容要点、用户意图、给设计师的备注。忽略旧版 outline.md。 阅读 $DECK_DIR/diagnosis.md——角色、领域、表达挑战。

如果 deck.md 不存在，则返回 /codeck 创建内容源。不要问“要先运行 outline 吗？”

角色转换

阅读 deck.md 末尾的“给设计师的备注”。用已激活角色的口吻写 1-2 句话，说明你将如何把内容源转化为视觉内容。

写入视觉文件前，先认领工作任务：

@orchestrator
Owner: @design. Task: turn deck content into visual source and assembled HTML.

@design
I claim the design pass. I will write and validate `DESIGN.md`, then write `custom.css`, `slides.html`, build HTML, and hand off to @review.

将本次交互追加到今天的 channel 文件，并更新 tasks/tasks.md。

参考资料提取（可选）

如果用户提供了视觉参考（URL、截图、设计规范），请先提取设计信号，再进行同构映射。如果用户只提到品牌名称而未提供 URL，请自行浏览其网站。

提取方法：

• 颜色：根据面积占比确定主色，根据辅助作用确定次要色，根据 CTA 用途确定强调色。将中性色阶从最浅的背景到最深的文字进行映射。
• 字体排印：根据视觉特征（几何、人文、衬线类别）进行识别，不要猜测字体名称。根据标题与正文的字号关系估算比例。
• 空间节奏：通过元素间距评估密度，通过各部分间距的一致性评估节奏。
• 材质／纹理：判断阴影的柔和度、扩散范围和层叠效果。记录玻璃质感、颗粒感、渐变。
• 动效：如果可以观察到，请记录缓动曲线和时长感受。

有多个参考资料时，找出它们的共同点。如果参考资料彼此冲突且没有明显的共同点，请记录主导模式并说明不同方案，让用户在风格说明中选择。

参考资料用于辅助映射，而不是凌驾于映射之上。如果某个信号与内容结构冲突，请解释为何采用不同处理方式。

将提取的信号融入设计骨架，并将最终的结构选择记录在 $DECK_DIR/DESIGN.md 中。

图像素材处理

图像处理属于 @design，不是单独的用户命令，也不是固定的图像类型菜单。

处理演示文稿所需的任何视觉素材：

• 改进用户提供的图像
• 裁剪、调整尺寸、重新着色、降噪或统一宽高比
• 清理截图，让界面在演示时清晰易读
• 将杂乱的截图重新设计为适合幻灯片展示的素材
• 生成缺失的视觉素材
• 将多个素材合成为一张更清晰的图像
• 如果 HTML、CSS 或 SVG 比栅格图像更准确，则跳过栅格图像

决策顺序：

1. 这张幻灯片上的视觉素材需要发挥什么作用？
2. 设计骨架要求的版位和宽高比是什么？
3. 用户是否已经提供了可用素材？
4. HTML、CSS 或 SVG 是否比栅格图像更适合表达？
5. 如果需要栅格图像，@design 应该改进、调整、生成、合成，还是保留占位符？

默认行为：

• 保留用户提供图像的含义。
• 无需询问即可改善适配度、裁剪、对比度、构图和演示文稿整体一致性。
• 除非用户明确要求，否则不要更改事实内容、人物、徽标、产品界面、图表数值、法律文本或品牌标识。
• 如果用户的素材在语义上很重要但视觉效果不佳，请创建清理后的衍生版本，并在记录中保留源文件路径。
• 如果没有素材且幻灯片需要，请生成或合成素材。
• 如果图像仅用于装饰，请跳过图像，让字体排印、CSS、SVG、布局或留白承担视觉表达。

只有当图像处理会改变含义或演示文稿方向时，才可以提出决策问题：

• 用风格化版本替换真实的产品截图
• 改变人物的外貌或身份特征
• 虚构可能被误认为是文档内容的场景
• 删除或更改品牌、法律或事实内容
• 在会改变演示文稿基调的视觉方案之间进行选择

不要询问是否需要裁剪、改善对比度、统一宽高比、清理截图、创建占位符，或使用已有素材。

处理素材前，请阅读 references/asset-guide.md。其中的形状仅为示例，不是固定模式。如果没有合适的形状，请设计合适的素材形式。

将图像处理记录在：

• DESIGN.md 的 ## Image Assets — 视觉策略、素材决策、生成提示词约束
• roles/design.md 的 ## Asset Work — 当前工作状态以及生成／处理后的文件
• MEMORY.md 的 Artifacts — 仅记录对重建有用的最终素材输出
• threads/threads.md — 如需更新 deck.md 中的素材清单，请记录在此，因为 deck.md 由 @outline 负责

视觉配方库

编写 DESIGN.md 之前，先阅读以下四个参考文件：

• references/theme-presets.md — 预设视觉系统，包含配色、字体、材质和动效默认值
• references/layout-recipes.md — 按修辞目的选择的页面结构配方
• references/component-recipes.md — 统计数据、提示框、行线、图表、媒体和界面框架的具体组件模式
• references/image-prompts.md — 用于生成、清理、重新设计或合成素材的提示词配方

将它们用作素材，而不是模板。固定引擎仍是 codeck 的运行时；不要复制外部模板代码、JavaScript 或 CSS 框架代码。

选择顺序：

1. 选择一个主题预设；仅当没有合适的预设时，才定义 custom-{name}。
2. 选择 4-8 个符合演示文稿页面用途的布局配方。
3. 仅为演示文稿中重复出现的结构选择组件配方。
4. 仅在确实需要位图或处理过的素材时，才选择图像提示词配方；否则记录 none — {reason}。

在 DESIGN.md 中记录全部四项选择：

Theme preset: {preset}
Layout recipes: {recipe-a}, {recipe-b}, ...
Component recipes: {recipe-a}, {recipe-b}, ...
Image prompt recipes: {recipe-a | none — reason}

设计骨架

编写 DESIGN.md 之前，先阅读 references/skeletons.md。

骨架是演示文稿的页面节奏、布局语法和默认页面系列。它不是主题、模板或素材包。

选择顺序：

1. 用户明确指定的风格、品牌、参考资料、截图或现有 DESIGN.md
2. $DECK_DIR/roles/design.md 中的当前骨架
3. diagnosis.md 中的表达挑战，以及内容的形式结构
4. 叙事网格骨架，并根据演示文稿的论证进行调整

默认骨架：

骨架	用途
narrative-grid	适用于以论证为主线且页面用途明确的演示文稿，包含主视觉／正文节奏、稳定的媒体区域、数据海报、引言、流程线，以及前后对照页面

用户提供的参考资料会调整骨架，但不会取代 room 协议。提取结构规则，为变体命名，并将其记录在 DESIGN.md 和 roles/design.md 中。除非用户要求，否则不要创建新的永久骨架文件。

在 DESIGN.md 的 ## Overview 中将选定的骨架记录为 Skeleton: {name}，并在 roles/design.md 的 ## Current Skeleton 下记录。

DESIGN.md：同构映射 → 设计档案

分三个步骤：选择骨架，寻找同构映射（概念层面），然后输出 DESIGN.md（规格说明）。

步骤 1：选择骨架

使用 references/skeletons.md 和当前演示文稿的结构。从 narrative-grid 开始，再根据论证调整页面模式序列。

骨架需要回答：

• 存在哪些页面系列？
• 整个演示文稿中的信息密度如何变化？
• 哪个视觉元素承载论证？
• 页面之间允许多大程度的变化？
• 审阅者必须保护什么？

步骤 2：同构映射

从大纲中提取形式结构（而非内容本身）：

• 张力曲线 — 叙事的张弛节奏
• 信息密度 — 哪些部分信息密集，哪些部分留白
• 论证拓扑 — 线性、分支、分层或对比
• 情感弧线 — 从何种情绪转向何种情绪

在你所在角色的知识领域中，寻找结构相似的事物：

层层展开的商业提案 → 拉威尔的《波莱罗》 → 视觉上从简到繁，每页增加一层，色彩逐渐饱和

对比鲜明的技术论证 → 围棋的攻守 → 以黑白对比为主，每次转换都用一种强调色作为“落子”

逐步加深理解的结构化说明 → 建筑蓝图 → 温暖的米白底色、精准的线条，通过空间层次而非暗色来逐步呈现信息

从混乱走向有序的数据报告 → 日式枯山水 → 前几页较为散乱，最后一页精简至极简

即使是平铺直叙的列表，也有其形式结构（累积、枚举、渐进）。始终进行同构映射——这是 codeck 演示文稿的独特之处。

步骤 3：生成 DESIGN.md

阅读 references/design-md-spec.md，了解 codeck DESIGN.md 格式规范。该规范基于 Google design.md。YAML front matter 包含机器可读的令牌；Markdown 章节则说明设计理念和创作意图。规范头部记录了 codeck 环境约束；如何收敛由 AI 决定。

必须基于审慎的决策填写每个令牌和章节，不得留空或使用占位文字。仅当某个令牌确实不适用时，才可在 YAML 中使用 "none"；不适用的正文部分必须写明 Not applicable — {具体原因}。完整的 DESIGN.md 能确保对各个维度都做出审慎决策；跳过字段会导致后续生成缺少信息。

归档文件至少应包含：

• YAML front matter，包含 design-md-spec.md 中定义的完整颜色、字体排版、间距、圆角和组件令牌
• 按规范顺序排列的全部 10 个章节：Overview、Colors、Typography、Layout、Elevation & Depth、Shapes、Components、Visual Effects、Image Assets、Do's and Don'ts
• 明确选定的主题预设、布局方案、组件方案和图像提示词方案
• 为演示文稿中出现的每个主要组件系列至少制定一条具体规则
• 明确说明骨架映射、字体比例、幻灯片节奏、动效策略和资源策略
• 不得使用占位文字

写入 $DECK_DIR/DESIGN.md。

写入后立即运行验证：

DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
CODECK_SKILL_DIR="${CODECK_SKILL_DIR:-}"
if [ -z "$CODECK_SKILL_DIR" ]; then
  for d in \
    "${CLAUDE_PLUGIN_ROOT}/skills/codeck" \
    "$HOME"/.claude/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME"/.codex/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME/.agents/skills/codeck" \
    "$HOME/.codex/skills/codeck" \
    "$HOME/.claude/skills/codeck"; do
    if [ -d "$d/scripts" ]; then CODECK_SKILL_DIR="$d"; break; fi
  done
fi
[ -n "$CODECK_SKILL_DIR" ] || { echo "codeck skill scripts not found; set CODECK_SKILL_DIR" >&2; exit 1; }
. "$CODECK_SKILL_DIR/scripts/resolve-dirs.sh"
[ -n "${CODECK_DESIGN_DIR:-}" ] || { echo "codeck-design not found; set CODECK_DESIGN_DIR" >&2; exit 1; }
bash "$CODECK_DESIGN_DIR/scripts/validate-design.sh" "$DECK_DIR/DESIGN.md"

如果验证失败，直接修改 DESIGN.md 并重新运行验证。验证通过前，不要编写 custom.css 或 slides.html。

揭示风格

这是设计方向决策询问时刻。

向用户展示三项内容：（1）内容的形式结构，（2）同构匹配及其为何属于结构层面而非装饰层面，（3）具体的视觉效果。

提供 2–3 个方向，并明确给出推荐。

• A) 采用此方向（推荐）
• B) 我有其他想法
• C) 给我几个方向供选择

如果该决策不会阻塞流程，而用户没有回复，则使用 A。将 assumed default 写入 MEMORY.md，并将最终视觉方向和选定的骨架写入 DESIGN.md 和 roles/design.md。如果该决策会阻塞流程，且没有可用的结构化 AskUser UI，则将未解决的问题留在 threads/threads.md 中，并在编写视觉源文件前停止。

视觉影响——质量门槛

正确但平淡是失败模式。DESIGN.md 验证通过后、编写 custom.css 前，阅读 references/visual-floor.md——其中包含 3 个 CSS 基准（暗色电影感、明亮编辑风、极简张力）。你的输出至少要达到该水平。

选择最接近的基准，逐项比较。如果视觉表现更平淡，则在继续之前进一步强化 DESIGN.md。

生成内容

架构：引擎固定，AI 只编写内容和样式

幻灯片引擎（导航、片段、概览、演讲者模式、进度条、FOUC 防护）是 scripts/engine.js 和 scripts/engine.css 中的固定代码。所有演示文稿都使用同一个引擎。

AI 编写两个文件：

文件	内容
$DECK_DIR/custom.css	:root 变量 + 布局原语 + 各页样式 + 移动端样式
$DECK_DIR/slides.html	<section class="slide"> 序列

由 Bash 组装最终 HTML。这是生成项目根目录下 *-rN.html 的唯一有效方式：

DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
CODECK_SKILL_DIR="${CODECK_SKILL_DIR:-}"
if [ -z "$CODECK_SKILL_DIR" ]; then
  for d in \
    "${CLAUDE_PLUGIN_ROOT}/skills/codeck" \
    "$HOME"/.claude/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME"/.codex/plugins/cache/*/codeck/*/skills/codeck \
    "$HOME/.agents/skills/codeck" \
    "$HOME/.codex/skills/codeck" \
    "$HOME/.claude/skills/codeck"; do
    if [ -d "$d/scripts" ]; then CODECK_SKILL_DIR="$d"; break; fi
  done
fi
[ -n "$CODECK_SKILL_DIR" ] || { echo "codeck skill scripts not found; set CODECK_SKILL_DIR" >&2; exit 1; }
. "$CODECK_SKILL_DIR/scripts/resolve-dirs.sh"
[ -n "${CODECK_DESIGN_DIR:-}" ] || { echo "codeck-design not found; set CODECK_DESIGN_DIR" >&2; exit 1; }
ENGINE_DIR="$CODECK_DESIGN_DIR/scripts"

bash "$ENGINE_DIR/build-html.sh" "$DECK_DIR" "{file-stem}" "{language}" "."

绝不要手动编写项目根目录下的最终 HTML。绝不要创建同级项目根目录 CSS 文件，例如 {file-stem}-deck.css。最终 HTML 必须自包含，并且必须包含引擎标记 openPresenter、codeck-presenter 和 BroadcastChannel；否则说明演讲者模式未完成组装。

引擎功能（engine.js — 不要重新实现）

1. 页面导航 — 方向键 / 空格键 / PageDown
2. 片段逐步显示 — data-f="N" 属性，按 ArrowDown 显示，按 ArrowUp 隐藏
3. 概览模式 — 按 Esc 切换，显示缩略图网格，点击即可跳转
4. 进度条 + 页码 — 自动创建
5. 移动端导航 — 自动创建底部按钮栏
6. FOUC 防护 — 显示前执行两次 rAF
7. 演讲者备注 — 读取 data-notes 属性
8. 演讲者模式 — 按 P 打开同步窗口（BroadcastChannel），显示当前页 / 下一页 / 备注 / 计时器

custom.css

完整映射规则请参阅 references/design-md-guide.md：DESIGN.md → custom.css。

流程：YAML front matter 令牌 → :root CSS 变量 → 布局原语 → 幻灯片类型样式 → 移动端。

关键： --bg、--fg、--accent 是引擎接口变量。engine.css 使用它们来设置进度条、概览边框和页码。必须在 :root 中定义这些变量。

不要为引擎选择器添加样式：.slide、#progress、.mobile-nav 或 .presenter-*。使用幻灯片专属类，例如 .slide-cover、.route-map 或 .station-panel；外壳由引擎负责。

slides.html

编写 slides.html 前，请先阅读 DESIGN.md 中的 ## Components，并应用 references/design-md-spec.md 中的组件语义。

<section class="slide slide-cover" data-notes="Opening: lead with the problem, not the product">
  <h1 class="title-mega">Title</h1>
  <p class="body-text" style="opacity:0.7">Subtitle</p>
</section>


<section class="slide" data-notes="Data from the 2024 report">
  <h2 class="title-large">What is the problem</h2>
  <div class="grid-2">
    <div class="card" data-f="1">First point</div>
    <div class="card" data-f="2">Second point</div>
  </div>
</section>

约定：

• 每个 <section class="slide" data-notes="..."> 对应一页
• data-notes：用 1-2 句话概述该页在 deck.md 中的要点
• 使用注释分隔各页：``
• 可在其中自由编写 HTML——不限制块类型
• data-f="N"：片段逐步显示（N 值较小的先出现）
• 不要添加 <!doctype>、<html>、<head>、<body>、<main class="deck">、样式表链接、<script> 标签、进度条或移动端导航——这些均由引擎处理

资源引用

有关图像资源、资源示例形态以及内嵌 / 海报 / 提取模式，请参阅 references/asset-guide.md。

生成和处理后的资源放在 $DECK_DIR/assets/ 中。

命名：

{slide-number}-{semantic-name}-{work}.{ext}

示例：

• 03-dashboard-clean.png
• 04-system-map-generated.png
• 06-founder-photo-crop.jpg
• 08-ui-redesign.png

编写并组装

1. 使用 Write 工具编写 $DECK_DIR/custom.css
2. 使用 Write 工具编写 $DECK_DIR/slides.html
3. 使用 Bash 运行 build-html.sh；该脚本会调用 assemble.sh，并拒绝缺少演讲者模式的 HTML

如果 slides.html 很长，单次写入失败，请先写入前几页，再使用 Edit 追加。

自查

组装完成后，检查最终 HTML：

1. 页数 — 是否与 deck.md 一致？
2. 注释锚点 — 每页是否都有 ``？
3. data-notes — 每个幻灯片区段是否都包含该属性？
4. CSS 变量 — :root 是否定义了 --bg、--fg、--accent、--font-body、--font-heading？
5. 移动端 — custom.css 是否包含 @media (max-width: 768px)？
6. 内容准确性 — 文本是否来自源材料，且没有编造数据？
7. 无引擎代码 — slides.html 中是否没有 <script> 标签？
8. 包含演讲者模式 — 最终 HTML 是否包含 openPresenter、codeck-presenter 和 BroadcastChannel？
9. 自包含 — 最终 HTML 是否不含 <link rel="stylesheet" ...>，且无需同级 CSS 文件？

直接修复问题（使用 Edit 修改 custom.css 或 slides.html，然后运行 build-html.sh）。不要询问用户。

迭代

不要将 Decision Ask 用于常规迭代。

如果用户要求更改视觉效果，请编辑 $DECK_DIR/slides.html 或 $DECK_DIR/custom.css，然后运行 build-html.sh。如果更改需要修改 deck.md，请在 threads/threads.md 中撰写提案，并将任务交给 @outline。对于之后的新用户请求，请创建下一个修订版本。

最后给出输出路径，并说明最重要的更改。用户可以提出具体修改，例如“让第 3 页更明亮”或“换成暖色调”。

交接

完成组装和自我审查后：

1. 更新 MEMORY.md 中的 Active Context、Latest Channel Summary、Task Index 和 Artifacts。
2. 在 tasks/tasks.md 中将 @design 任务标记为完成。
3. 如果内容或风格需要用户决定，请将其写入 threads/threads.md。
4. 将交接内容追加到今天的频道文件：

@design
I wrote validated `DESIGN.md`, `custom.css`, `slides.html`, and assembled the HTML. The next owner is @review.

@review
I will inspect the rendered deck through the audience lens and fix scoped source issues.

注意事项

• 允许使用 Google Fonts，但必须始终提供回退字体。 在 custom.css 顶部使用 @import url()——assemble.sh 会将其放入 <head> 中的 <style>。始终包含系统字体回退列表。离线时会使用回退字体渲染，不会出错。
• slides.html 中不能有 <script>。 所有 JS 均由引擎处理。多余的 <script> 会导致重复绑定、导航失效和难以排查的问题。
• :root 变量属于 API 契约。 engine.css 会使用 --bg、--fg、--accent。缺失或拼写错误会导致进度条出错、页码不可见，以及概览模式中白字显示在白底上。
• 片段编号必须从 1 开始连续递增。 使用 data-f="1"、data-f="2" 等。编号跳跃（1、3、5）会导致引擎跳过步骤。编号重复会导致内容同时显示。
• 不要覆盖引擎类。 .slide、#progress、.mobile-nav、.presenter-* 属于引擎。覆盖它们会导致布局错乱，且只有在演讲者模式或移动设备上才会显现。
• 绝不要在 .slide 或幻灯片类型类上设置 position。 engine.css 中 .slide 的样式为 position: absolute; inset: 0——这让它铺满视口。在 .slide-cover 等类上设置 position: relative 会破坏这一点：幻灯片会缩小到内容高度，底部留下空白区域。
• CSS 动画与 prefers-reduced-motion。 如果 custom.css 中有 @keyframes，请用 @media (prefers-reduced-motion: no-preference) { ... } 包裹。否则会导致无障碍访问问题。
• 在 slides.html 中硬编码颜色会导致难以维护。 调整一次调色板，就要在 30 张幻灯片中逐一查找。请只使用 CSS 类和 var()。
• 封面幻灯片默认将标题和副标题居中。 如果设计风格追求对称（古典、简约、编辑风格），居中是正确的。否则，就打破这种布局——不对称能体现设计的刻意安排。
• 对数学函数取反会导致 CSS 静默失效。 浏览器会静默丢弃 -clamp(...)、-min(...)、-max(...)——没有错误，也没有警告，只会导致位置错误。请始终改用 calc(-1 * clamp(...))。
• 不仅要设置宽度断点，还要设置高度断点。 带浏览器工具栏的笔记本电脑视口高度约为 600px。请添加 @media (max-height: 700px) 和 @media (max-height: 500px)，以缩小标题并隐藏装饰元素。仅设置宽度断点会漏掉最常见的溢出情况。
• 内容密度有严格上限。 标题幻灯片：最多 1 个标题和 1 个副标题。内容幻灯片：最多 1 个标题和 6 个项目符号，或 2 段简短文字。数据幻灯片：最多 1 个标题和 4 张指标卡片。代码幻灯片：最多 10 行。超出上限会导致内容溢出视口。请拆分为多张幻灯片，切勿硬塞。
• Assemble.sh 会自动递增修订号。 不要手动命名输出文件。让脚本处理 r1、r2 等修订号。手动命名会破坏修订链。

已完成

codeck 设计完成。

@design 我编写了视觉源文件、组装了 HTML，并将项目交给 @review。

{一句话——引用 DESIGN.md 中的同构映射}

输出：./{title}-r{revision}.html（位于用户的项目目录中） 中间文件：$DECK_DIR/DESIGN.md 下一步：/codeck 将进行检查和修复。