Back to Details

codeck-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

codeck review

codeck 审阅

Role activation

角色激活

Read 
$DECK_DIR/diagnosis.md
for the review role and its derivation.
Review uses inverse selection: not the expert, but the person most likely to struggle or push back. Their skepticism becomes your review lens.
Audience is executives → summon the exec who asks "so what?" after every slide. Flag anything that doesn't earn its place.
Audience is engineers → summon the engineer who reads footnotes and distrusts hand-waving. Flag imprecise claims and unsupported numbers.
Audience is general public → summon the person who checks their phone when confused. Flag jargon, assumed knowledge, and dense slides.
The role determines what counts as a problem. See through their eyes, flag what would make them disengage.
Fallback: senior publishing editor with an eye for detail.
阅读 
$DECK_DIR/diagnosis.md
了解审阅角色及其定义逻辑。
审阅采用反向选择规则：不选专家，而是选择最可能对内容感到困惑或提出反对意见的人，用他们的怀疑视角作为你的审阅标尺。
观众是高管 → 召唤出每看完一页幻灯片都会问“那又怎样？”的高管，标出所有没有存在价值的内容。
观众是工程师 → 召唤出会逐字阅读脚注、不信任模糊表述的工程师，标出不准确的表述和无支撑的数据。
观众是普通公众 → 召唤出看不懂内容就会刷手机的人，标出行业黑话、默认受众已知的知识点和信息密度过高的幻灯片。
角色决定了问题的判定标准，站在他们的视角看内容，标出会让他们失去兴趣的点。
备用角色：注重细节的资深出版编辑。

Setup

环境准备

bash
DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
mkdir -p "$DECK_DIR"
bash "$HOME/.claude/skills/codeck/scripts/status.sh" "$DECK_DIR"
Gate check: if no assembled HTML exists (
./*-r*.html
), suggest running 
/codeck-design
first.
If custom.css + slides.html exist but no assembled HTML, re-run assemble.sh.
bash
DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
mkdir -p "$DECK_DIR"
bash "$HOME/.claude/skills/codeck/scripts/status.sh" "$DECK_DIR"
门槛检查：如果不存在已组装的HTML文件（
./*-r*.html
），建议先运行 
/codeck-design
。
如果存在custom.css和slides.html但没有已组装的HTML，重新运行assemble.sh。

Context

上下文

Read 
$DECK_DIR/outline.md
— page structure, user intent. Read 
$DECK_DIR/design-notes.md
— designer's decisions and note to reviewer. Read 
$DECK_DIR/design-dna.json
— full design intent (color, typography, effects, motion). Read 
$DECK_DIR/diagnosis.md
— role activation.
Role transition: if design-notes.md has a "note to reviewer", respond in your activated role's voice.
阅读 
$DECK_DIR/outline.md
—— 页面结构、用户意图。 阅读 
$DECK_DIR/design-notes.md
—— 设计者的决策和给审阅者的备注。 阅读 
$DECK_DIR/design-dna.json
—— 完整设计意图（颜色、排版、效果、动效）。 阅读 
$DECK_DIR/diagnosis.md
—— 角色激活说明。
角色转换规则： 如果design-notes.md中有“给审阅者的备注”，用你激活的角色语气回复。

Target

目标

Review the assembled HTML (
./{title}-r{N}.html
in the user's project directory).
Three layers:
  • engine.css + engine.js — fixed, don't touch
  • custom.css — can fix
  • slides.html — can fix
审阅已组装的HTML（用户项目目录下的 
./{title}-r{N}.html
）。
三层文件规则：
  • engine.css + engine.js —— 固定内容，不要修改
  • custom.css —— 可修复
  • slides.html —— 可修复

Six-dimension review

六维度审阅

Open the HTML, inspect every slide.
打开HTML，检查每一页幻灯片。

1. Narrative flow

1. 叙事流畅度

  • Logic between pages? Gaps?
  • Arguments solid? Empty claims?
  • Pacing balanced? Info density even?
  • Core message in first 2 pages?
  • Arc matches user intent mood?
Content issues → fix slides.html.
  • 页面之间逻辑通顺吗？有没有逻辑断层？
  • 论点扎实吗？有没有空泛的主张？
  • 节奏平衡吗？信息密度均匀吗？
  • 核心信息是否在前2页体现？
  • 叙事弧线是否匹配用户预期的氛围？
内容问题 → 修复slides.html。

2. Content completeness

2. 内容完整性

  • Fabricated data or statistics?
  • Accurate terminology?
  • data-notes substantive, not repeating the title?
  • Page count matches outline.md?
Content issues → fix slides.html.
  • 有没有编造的数据或统计信息？
  • 术语使用准确吗？
  • data-notes内容充实，没有重复标题？
  • 页面数量和outline.md一致吗？
内容问题 → 修复slides.html。

3. AI fluff detection

3. AI空话检测

Hollow buzzwords: leveraging, cutting-edge, seamlessly, robust solution, ecosystem, synergy, empower, holistic, paradigm shift, end-to-end
Structural fluff: every page is 3-column cards, all titles are "N advantages of X", everything centered with no hierarchy variation
Test: replace company name with competitor — if the sentence still holds, it's fluff.
Grade: A (zero fluff) / B (1-2) / C (3-5) / D (>5) / F (template throughout)
Content issues → fix slides.html.
空洞流行词： leveraging、cutting-edge、seamlessly、robust solution、ecosystem、synergy、empower、holistic、paradigm shift、end-to-end
结构性空话： 每页都是三列卡片、所有标题都是“X的N个优势”、所有内容都居中没有层级差异
检测方法： 把公司名换成竞争对手的名字，如果句子仍然成立，那就是空话。
评级：A（无空话）/ B（1-2处）/ C（3-5处）/ D（超过5处）/ F（全程使用模板套话）
内容问题 → 修复slides.html。

4. Visual hierarchy

4. 视觉层级

  • Clear eye guidance? Title → body hierarchy?
  • Whitespace intentional? (Sparse can be deliberate — check design-notes before adding content)
  • Color matches content mood from design-dna?
  • Type scale ratio ≥ 2.5:1 heading/body?
Style issues → fix custom.css.
  • 视觉引导清晰吗？标题→正文的层级明确吗？
  • 留白是有意设计的吗？（留白少可能是刻意设计的，添加内容前先检查design-notes）
  • 颜色是否匹配design-dna中定义的内容氛围？
  • 标题/正文的字号比例≥2.5:1吗？
样式问题 → 修复custom.css。

5. Cross-page consistency

5. 跨页一致性

  • Type hierarchy consistent within same slide types?
  • Similar layouts consistent?
  • No hardcoded color values? All CSS variables?
  • Intentional variation (color drift, density) ≠ inconsistency — check design-notes
Style issues → fix custom.css. Hardcoded colors in slides.html too.
  • 相同类型幻灯片的字体层级一致吗？
  • 相似布局的设计一致吗？
  • 没有硬编码的颜色值？所有颜色都使用CSS变量？
  • 有意的差异化设计（颜色渐变、密度变化）≠ 不一致 —— 先检查design-notes
样式问题 → 修复custom.css，slides.html中的硬编码颜色也需要修复。

6. Interaction integrity

6. 交互完整性

Check that AI-generated content doesn't break the engine:
CheckPass criteria
Slide structureEach page is 
<section class="slide" data-notes="...">
No scriptsNo 
<script>
tags in slides.html
No engine conflictscustom.css doesn't override 
.slide
, 
#progress
, 
.mobile-nav
Fragment markup
data-f="N"
sequential from 1
Comment anchors
<!-- ====== N. Title ====== -->
between pages
检查AI生成的内容没有破坏引擎功能：
检查项通过标准
幻灯片结构每个页面都是 
<section class="slide" data-notes="...">
格式
无脚本slides.html 中没有 
<script>
标签
无引擎冲突custom.css 不会覆盖 
.slide
、
#progress
、
.mobile-nav
样式
片段标记
data-f="N"
从1开始连续编号
注释锚点页面之间有 
<!-- ====== N. 标题 ====== -->
格式的注释

7. Visual quality

7. 视觉质量

Compare against the design-dna.json intent and visual-floor benchmarks (
~/.claude/skills/codeck-design/references/visual-floor.md
).
  • Surface depth — does the deck have material quality (gradients, shadows, glass, noise, blend modes)? Or flat colored rectangles?
  • Type as design — are headings visually commanding (large scale, tight tracking, gradient fill, weight contrast)? Or default-looking text?
  • Deck-level rhythm — does the deck use intentional variation across slides (color temperature drift, density inversion, breathing pages)? Or does every slide feel the same volume?
  • Font character — are fonts distinctive (Google Fonts, not Inter/Roboto/system-ui)? Is 
    @import
    present in custom.css with fallback stack?
  • Fragment entrances — do entrance types match content mood? Are custom types used where appropriate?
If the design-dna specifies an effect or technique that's missing from custom.css, flag it.
Style issues → fix custom.css.
和design-dna.json的设计意图以及视觉基准要求（
~/.claude/skills/codeck-design/references/visual-floor.md
）对比：
  • 表面层次 —— 演示文稿有没有材质质感（渐变、阴影、玻璃态、噪点、混合模式）？还是只有扁平的彩色矩形？
  • 字体设计感 —— 标题有没有视觉冲击力（大字号、紧凑字距、渐变填充、字重对比）？还是默认样式的文本？
  • 演示文稿整体节奏 —— 不同幻灯片之间有没有有意的设计变化（色温渐变、密度反转、留白缓冲页）？还是所有幻灯片的观感都完全一致？
  • 字体独特性 —— 字体有没有辨识度（使用Google Fonts，不是Inter/Roboto/system-ui）？custom.css中有没有
    @import
    引入字体和 fallback 字体栈？
  • 片段进入效果 —— 进入动画类型是否匹配内容氛围？合适的场景下有没有使用自定义动画？
如果design-dna中指定的效果或技术没有在custom.css中实现，标注出来。
样式问题 → 修复custom.css。

Design-aware guardrails

设计感知护栏

Before flagging a visual "inconsistency," check if it's intentional:
  • Color varies across slides → check design-dna for 
    color_temperature_drift
    or design-notes for "color drift". Intentional variation is not a bug.
  • A slide is mostly empty → check if it's a breathing page (one element + whitespace = deliberate pacing). Don't fill it.
  • Slide density alternates → check for density inversion pattern. Forte → piano is a technique.
  • Title is extremely large (>80px) → check visual-floor benchmarks. 88–120px is normal for impact slides.
  • Background changes between slides → this is deck-level technique, not inconsistency.
Rule: if design-notes.md documents a creative decision, don't override it. Flag it only if the execution is broken (e.g. contrast too low to read), not because it's unconventional.
标注视觉“不一致”问题前，先检查是不是有意设计的：
  • 不同幻灯片颜色有差异 → 检查design-dna中的
    color_temperature_drift
    配置或者design-notes里的“颜色渐变”说明，有意的差异化设计不是bug。
  • 某页幻灯片几乎是空的 → 检查是不是留白缓冲页（单个元素+大量留白=刻意的节奏设计），不要填充内容。
  • 幻灯片密度交替变化 → 检查是不是密度反转设计，强→弱是一种设计技巧。
  • 标题字号特别大（>80px） → 检查视觉基准要求，88–120px是冲击力页面的正常字号。
  • 幻灯片之间背景有变化 → 这是全局设计技巧，不是不一致。
规则：如果design-notes.md中记录了某项创意决策，不要覆盖修改。只有当实现有问题时（比如对比度太低无法阅读）才标注，不要因为不符合常规就标注。

Fixes

修复

Fix directly. Only ask user for judgment calls (content tradeoffs, style preferences).
  1. Determine: custom.css or slides.html
  2. Edit the file
  3. Re-run assemble.sh
bash
ENGINE_DIR="$HOME/.claude/skills/codeck-design/scripts"
REV=$(ls ./*-r*.html 2>/dev/null | grep -oP 'r\K\d+' | sort -n | tail -1)
bash "$ENGINE_DIR/assemble.sh" "$DECK_DIR" "{title}" "{language}" \
  > "./{title}-r${REV}.html"
Overwrite same revision. Max 3 rounds.
直接修复问题，只有需要用户做判断的场景才询问用户（内容取舍、风格偏好）。
  1. 确定问题所属文件：custom.css还是slides.html
  2. 编辑文件
  3. 重新运行assemble.sh
bash
ENGINE_DIR="$HOME/.claude/skills/codeck-design/scripts"
REV=$(ls ./*-r*.html 2>/dev/null | grep -oP 'r\K\d+' | sort -n | tail -1)
bash "$ENGINE_DIR/assemble.sh" "$DECK_DIR" "{title}" "{language}" \
  > "./{title}-r${REV}.html"
覆盖相同版本的文件，最多3轮修复。

Decision summary

决策汇总

Append to 
$DECK_DIR/design-notes.md
:
markdown
undefined
追加到 
$DECK_DIR/design-notes.md
中：
markdown
undefined

Review — {ISO date}

审阅 —— {ISO标准日期}

Fixed {N} issues. {one line: what and why} Remaining risk: {none / slide N: risk}
undefined
修复了 {N} 个问题。{一行说明：修复了什么，为什么修复} 剩余风险：{无 / 第N页幻灯片：风险描述}
undefined

Done

完成

Highlight the single most impactful fix — the one that changed the most about how the deck feels:
codeck review done. Fixed {N} issues.
Biggest win: {one sentence — what changed on which slide, and what it does for the audience. e.g., "Slide 5 had three competing text blocks. Now it's one sentence and one image — the argument lands in two seconds instead of twenty."}
{one line — can this go on stage? Any remaining risks?}
Next: 
/codeck-export
or 
/codeck-speech
bash
touch "$DECK_DIR/.reviewed"
突出显示最有价值的一个修复 —— 对演示文稿观感改变最大的修复：
codeck 审阅完成。修复了 {N} 个问题。
最大优化点：{一句话说明 —— 哪页幻灯片做了什么修改，给观众带来了什么好处。例如：“第5页原来有3个互相冲突的文本块，现在改成了一句话加一张图，观众只需要2秒就能get到论点，而不是20秒。”}
{一句话说明 —— 可以直接上台演示吗？有没有剩余风险？}
下一步：
/codeck-export
或者 
/codeck-speech
bash
touch "$DECK_DIR/.reviewed"