Back to Details

codeck

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

codeck — Entry & Dashboard

codeck — 入口与仪表板

Scan materials, diagnose project state, show pipeline overview, guide next step.
Flag anomalies proactively: stale stages, upstream changes not reflected downstream.
扫描素材，诊断项目状态，展示流程概览，引导下一步操作。
主动标记异常：阶段过期、上游变更未同步到下游。

AskUserQuestion format

AskUserQuestion 格式

All codeck skills follow this pattern:
  1. Re-ground — which skill, which step. One line.
  2. Simplify — plain language. Assume user hasn't looked at screen for 20 minutes.
  3. Recommend — 
    Suggest [X] because [reason]
    .
  4. Options — A) B) C), one click.
Only state verified facts. Unexecuted actions use "will / plan to".
所有 codeck skill 都遵循如下模式：
  1. 重新对齐 — 明确当前是哪个 skill、哪个步骤，仅占一行。
  2. 简化表述 — 使用平实语言，假设用户已经20分钟没看过屏幕。
  3. 给出建议 — 按照 
    Suggest [X] because [reason]
    格式。
  4. 提供选项 — A) B) C)，支持一键选择。
仅陈述已验证的事实，未执行的动作使用「将要 / 计划」表述。

Two directories

两个目录

  • Current directory (
    .
    )     — the user's project. Materials live here. Final HTML goes here too — so the user can see and open it directly.
  • $DECK_DIR
     — codeck's intermediate artifacts. diagnosis.md, outline.md, design-notes.md, design-dna.json, custom.css, slides.html, speech.md. The user doesn't need to look here.
Scan materials in 
.
. Write intermediate artifacts to 
$DECK_DIR
. Output final HTML to 
.
.
  • 当前目录（
    .
    ）     — 用户的项目目录，素材存放在此处。最终生成的 HTML 也会输出到这里 — 方便用户直接查看和打开。
  • $DECK_DIR
     — codeck 的中间产物存放目录，包含 diagnosis.md、outline.md、design-notes.md、design-dna.json、custom.css、slides.html、speech.md，用户无需访问该目录。
扫描 
.
目录下的素材，将中间产物写入 
$DECK_DIR
，最终 HTML 输出到 
.
目录。

Phase 1: Init + status

阶段1：初始化 + 状态检查

bash
DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
mkdir -p "$DECK_DIR"

bash "$HOME/.claude/skills/codeck/scripts/status.sh" "$DECK_DIR"
bash
DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
mkdir -p "$DECK_DIR"

bash "$HOME/.claude/skills/codeck/scripts/status.sh" "$DECK_DIR"

Phase 2: Material scan

阶段2：素材扫描

Scan the current directory (the user's project), not DECK_DIR.
bash
EXCLUDE='! -path "./node_modules/*" ! -path "./.git/*" ! -path "./.claude/*" ! -path "./dist/*" ! -path "./build/*" ! -name "CLAUDE.md" ! -name "TODOS.md" ! -name "README.md" ! -name "DESIGN.md" ! -name "*.test.*" ! -name "*.spec.*" ! -name "*.config.*"'

echo "=== TEXT ===" && eval find . -maxdepth 4 -type f \( -name "*.md" -o -name "*.txt" -o -name "*.rtf" -o -name "*.org" -o -name "*.rst" \) $EXCLUDE 2>/dev/null | head -20
echo "=== DOCS ===" && eval find . -maxdepth 4 -type f \( -name "*.pdf" -o -name "*.docx" -o -name "*.doc" -o -name "*.pptx" -o -name "*.ppt" -o -name "*.key" -o -name "*.pages" -o -name "*.xlsx" -o -name "*.xls" -o -name "*.numbers" \) $EXCLUDE 2>/dev/null | head -20
echo "=== IMAGES ===" && eval find . -maxdepth 4 -type f \( -name "*.png" -o -name "*.jpg" -o -name "*.jpeg" -o -name "*.webp" -o -name "*.gif" -o -name "*.svg" -o -name "*.ico" -o -name "*.bmp" -o -name "*.tiff" \) $EXCLUDE 2>/dev/null | head -20
echo "=== DATA ===" && eval find . -maxdepth 4 -type f \( -name "*.csv" -o -name "*.tsv" -o -name "*.json" -o -name "*.yaml" -o -name "*.yml" -o -name "*.xml" \) $EXCLUDE 2>/dev/null | head -20
echo "=== MEDIA ===" && eval find . -maxdepth 4 -type f \( -name "*.mp4" -o -name "*.mov" -o -name "*.mp3" -o -name "*.wav" -o -name "*.m4a" -o -name "*.webm" \) $EXCLUDE 2>/dev/null | head -10
扫描当前目录（用户的项目目录），而非 DECK_DIR。
bash
EXCLUDE='! -path "./node_modules/*" ! -path "./.git/*" ! -path "./.claude/*" ! -path "./dist/*" ! -path "./build/*" ! -name "CLAUDE.md" ! -name "TODOS.md" ! -name "README.md" ! -name "DESIGN.md" ! -name "*.test.*" ! -name "*.spec.*" ! -name "*.config.*"'

echo "=== TEXT ===" && eval find . -maxdepth 4 -type f \( -name "*.md" -o -name "*.txt" -o -name "*.rtf" -o -name "*.org" -o -name "*.rst" \) $EXCLUDE 2>/dev/null | head -20
echo "=== DOCS ===" && eval find . -maxdepth 4 -type f \( -name "*.pdf" -o -name "*.docx" -o -name "*.doc" -o -name "*.pptx" -o -name "*.ppt" -o -name "*.key" -o -name "*.pages" -o -name "*.xlsx" -o -name "*.xls" -o -name "*.numbers" \) $EXCLUDE 2>/dev/null | head -20
echo "=== IMAGES ===" && eval find . -maxdepth 4 -type f \( -name "*.png" -o -name "*.jpg" -o -name "*.jpeg" -o -name "*.webp" -o -name "*.gif" -o -name "*.svg" -o -name "*.ico" -o -name "*.bmp" -o -name "*.tiff" \) $EXCLUDE 2>/dev/null | head -20
echo "=== DATA ===" && eval find . -maxdepth 4 -type f \( -name "*.csv" -o -name "*.tsv" -o -name "*.json" -o -name "*.yaml" -o -name "*.yml" -o -name "*.xml" \) $EXCLUDE 2>/dev/null | head -20
echo "=== MEDIA ===" && eval find . -maxdepth 4 -type f \( -name "*.mp4" -o -name "*.mov" -o -name "*.mp3" -o -name "*.wav" -o -name "*.m4a" -o -name "*.webm" \) $EXCLUDE 2>/dev/null | head -10

Phase 3: Content diagnosis

阶段3：内容诊断

If materials exist and 
$DECK_DIR/diagnosis.md
doesn't, read materials and diagnose:
如果存在素材且 
$DECK_DIR/diagnosis.md
不存在，则读取素材并进行诊断：

Research before diagnosis

诊断前调研

If the material involves a domain you're unfamiliar with, or uses specialized terminology, search the web first. Understand the field's key concepts, common presentation patterns, and what experts in this space consider hard to explain. This grounds your diagnosis in real knowledge, not guesses.
Examples:
  • Material about "WebTransport protocol" → search for what it is, how it differs from WebSocket, who's adopting it
  • Material about a specific company's product → search for the product, its competitors, its positioning
  • Material in a niche academic field → search for how practitioners in that field typically present findings
如果素材涉及你不熟悉的领域，或是使用了专业术语，先搜索网页。了解该领域的核心概念、常见演示模式，以及该领域专家认为难以解释的内容。这能让你的诊断基于真实知识，而非猜测。
示例：
  • 关于「WebTransport 协议」的素材 → 搜索它是什么、和 WebSocket 的区别、适用场景、采用该协议的用户
  • 关于某特定公司产品的素材 → 搜索该产品、竞品、市场定位
  • 属于小众学术领域的素材 → 搜索该领域从业者通常如何展示研究成果

Three signals

三个信号

  1. Domain — what field? Determines outline role.
  2. Expression challenge — what's hardest to convey? Determines design role.
  3. Audience starting point — what do they know / not know? Determines review role (inverse selection: the listener most likely to struggle).
  1. 领域 — 所属行业？决定大纲角色。
  2. 表达难点 — 最难传递的内容是什么？决定设计角色。
  3. 受众基础 — 他们知道什么/不知道什么？决定审核角色（反向选择：最可能难以理解内容的听众）。

Role selection methodology

角色选择方法

Don't pick from a list. Don't match by domain. Find the person whose way of thinking cracks this specific problem.
Outline role — who asks the right question about this material? Identify the core tension in the material, then find someone known for penetrating that type of tension — regardless of their field. A product launch where the real challenge is "why should anyone care" might need Sondheim (every lyric earns its place) more than a marketing guru. A technical architecture talk where the challenge is "too many moving parts" might need Tufte (information compression) or a film editor (what to cut).
Test: does this person's way of questioning change what the outline includes and excludes? If the outline would be the same without them, the match is wrong.
Design role — whose formal logic mirrors the content's structure? Not "good designer" but "whose way of organizing form matches how this argument moves." A content that builds layer by layer might map to Ravel. A content driven by contrast might map to Caravaggio. A content that strips away to reveal essence might map to Dieter Rams. The match can come from any domain — music, painting, architecture, choreography — because form is transferable.
Test: can you state the structural mapping in one sentence? ("This content does X; this person's work does X in visual/sonic/spatial form.") If not, the match is decorative.
Review role — inverse selection. Not the expert. The listener most likely to struggle or push back. The role determines what gets flagged — not correctness, but comprehension and trust.
Test: would this person interrupt you mid-presentation? If not, pick someone harder to convince.
不要从列表中挑选，不要按领域匹配。找到思维方式恰好能解决这个特定问题的人。
大纲角色 — 谁能针对这份素材提出正确的问题？ 识别素材的核心矛盾，然后找到以突破这类矛盾著称的人——不管他们所属什么领域。如果产品发布的真正难点是「为什么大家要关心」，那么相比营销专家，你可能更需要 Sondheim（每一句歌词都有其存在的价值）。如果技术架构演讲的难点是「涉及的模块太多」，那么你可能需要 Tufte（信息压缩专家）或是电影剪辑师（知道要剪掉什么）。
测试标准：如果没有这个人，大纲的内容取舍会不会发生变化？如果不会，说明匹配错误。
设计角色 — 谁的形式逻辑和内容结构相匹配？ 不是选「优秀的设计师」，而是选「组织形式的方式和论点推进逻辑一致的人」。逐层递进的内容可能适合 Ravel，以对比为核心的内容可能适合 Caravaggio，去芜存菁揭示本质的内容可能适合 Dieter Rams。匹配对象可以来自任何领域——音乐、绘画、建筑、编舞——因为形式是可迁移的。
测试标准：你能不能用一句话说明结构匹配关系？（「这份内容的特点是X，该人物的作品在视觉/听觉/空间形式上也有X的特点」）如果不能，说明匹配只是装饰性的。
审核角色 — 反向选择。 不要选专家，选最可能听不懂或是提出反对意见的听众。这个角色决定了哪些内容需要被标记——不是正确性，而是可理解性和可信度。
测试标准：这个人会不会在你演示到一半的时候打断你？如果不会，选一个更难说服的人。

Material summary

素材摘要

One-line summary per file: what it is, how it can be used. Written into diagnosis.md.
每个文件用一句话总结：是什么，可以怎么用，写入 diagnosis.md。

Output: 
$DECK_DIR/diagnosis.md

输出：
$DECK_DIR/diagnosis.md

markdown
undefined
markdown
undefined

Diagnosis

Diagnosis

Materials

Materials

FileContentUse for
{filename}{one-line description}{role in deck}
FileContentUse for
{filename}{one-line description}{role in deck}

Domain

Domain

{description}
{description}

Expression challenge

Expression challenge

{hardest part to convey}
{hardest part to convey}

Audience starting point

Audience starting point

{what they know / don't know}
{what they know / don't know}

Role recommendations

Role recommendations

Outline stage

Outline stage

{role name} — {derivation: domain + why this person's method of explaining reshapes the structure}
{role name} — {derivation: domain + why this person's method of explaining reshapes the structure}

Design stage

Design stage

{role name} — {derivation: expression challenge + structural mapping between content and this person's visual logic}
{role name} — {derivation: expression challenge + structural mapping between content and this person's visual logic}

Review stage

Review stage

{role name} — {derivation: audience starting point + why this person would struggle or push back}

Skip diagnosis if no materials — let user provide topic directly in each stage.

---
{role name} — {derivation: audience starting point + why this person would struggle or push back}

如果没有素材则跳过诊断——让用户在每个阶段直接提供主题。

---

State outputs

状态输出

Define what the user sees in each pipeline state. These are the exact outputs — not summaries.
定义用户在每个流程状态下看到的内容，以下是精确输出内容——不是摘要。

Empty state (no materials found)

空状态（未找到素材）

When Phase 2 finds zero files:
No materials found in this directory.

That's fine — you can start from a topic directly.

What's the presentation about? One sentence is enough.
(Or drop some files here and run /codeck again.)
Warm, not clinical. One primary action. No error language.
当阶段2未找到任何文件时：
No materials found in this directory.

That's fine — you can start from a topic directly.

What's the presentation about? One sentence is enough.
(Or drop some files here and run /codeck again.)
语气友好，不生硬，仅提供一个核心操作，不要使用错误提示类的措辞。

Error state (assemble.sh fails)

错误状态（assemble.sh 运行失败）

When assemble.sh exits non-zero:
Assembly failed: {error message}

Check that custom.css and slides.html exist in {DECK_DIR}.
Run /codeck-design to regenerate them.
Name the exact file missing. Give the exact command to fix it.
当 assemble.sh 退出码非0时：
Assembly failed: {error message}

Check that custom.css and slides.html exist in {DECK_DIR}.
Run /codeck-design to regenerate them.
明确指出缺失的文件，给出修复的精确命令。

Stale state (upstream changed, downstream not rebuilt)

过期状态（上游内容已变更，下游未重新构建）

When status.sh detects staleness:
⚠ {stage} is stale — {upstream file} changed after {downstream file} was built.
Run /{next-skill} to rebuild.
One line. Name the files. Give the command.
当 status.sh 检测到内容过期时：
⚠ {stage} is stale — {upstream file} changed after {downstream file} was built.
Run /{next-skill} to rebuild.
仅一行内容，指明相关文件，给出操作命令。

Phase 4: Results

阶段4：结果输出

status.sh already outputs the dashboard. Below it, add:
  1. Materials — file types and counts from Phase 2
  2. STALE — one-line explanation if any stage is stale
Don't redraw the table.
status.sh 已经输出了仪表板，在下方补充：
  1. 素材 — 阶段2扫描得到的文件类型和数量
  2. 过期提示 — 如果有阶段过期，给出一行说明
不要重绘表格。

Role reveal (if Phase 3 ran)

角色展示（如果已执行阶段3）

This is the first moment the user sees the system think. Don't dump three role names — tell a story in three beats:
  1. What your content is really about — the core tension, in one sentence. Not the topic, the underlying struggle. ("Your material isn't about microservices — it's about convincing a team to accept short-term pain for long-term sanity.")
  2. Who I'm bringing in, and why — the derivation, not just the name. Connect the person's way of thinking to the content's tension. ("For the outline, I'm thinking of Feynman — not because this is physics, but because your argument needs to make the invisible feel obvious. He did that better than anyone.")
  3. What this changes — one concrete consequence. ("This means the outline won't start with background. It'll start with the one thing your audience already knows is broken.")
Keep it short. Three paragraphs, not three pages. The point is: the user should feel their content was seen, not just processed.
这是用户第一次看到系统的「思考过程」。不要直接抛出三个角色名，分三个步骤讲述：
  1. 你的内容的核心是什么 — 用一句话说明核心矛盾，不是主题，是背后的难点。（「Your material isn't about microservices — it's about convincing a team to accept short-term pain for long-term sanity.」）
  2. 我引入了谁，为什么 — 说明选择依据，而不只是名字。把人物的「思维方式」和内容的矛盾关联起来。（「For the outline, I'm thinking of Feynman — not because this is physics, but because your argument needs to make the invisible feel obvious. He did that better than anyone.」）
  3. 这会带来什么变化 — 一个具体的影响。（「This means the outline won't start with background. It'll start with the one thing your audience already knows is broken.」）
内容尽量简短，三段即可，不要写三页。核心是：用户应该感觉到自己的内容被「理解」了，而不只是被处理了。

Phase 5: Handoff

阶段5：流程交接

All outputs go to 
$DECK_DIR/
. Next skill reads upstream outputs.
status.sh prints a NEXT recommendation. Use it:
NEXTSuggest
/codeck-outline
"Materials scanned. Next: 
/codeck-outline
to plan the structure."
/codeck-design
"Outline ready. Next: 
/codeck-design
to generate slides."
/codeck-review
"Slides generated. Next: 
/codeck-review
to inspect and fix."
/codeck-export
or 
/codeck-speech
"Review done. Next: 
/codeck-export
for PDF/PPTX, or 
/codeck-speech
for a script."
User can run 
/codeck
anytime to see progress.
所有输出都存放到 
$DECK_DIR/
目录，下一个 skill 读取上游的输出。
status.sh 会打印下一步建议，直接使用：
NEXTSuggest
/codeck-outline
"Materials scanned. Next: 
/codeck-outline
to plan the structure."
/codeck-design
"Outline ready. Next: 
/codeck-design
to generate slides."
/codeck-review
"Slides generated. Next: 
/codeck-review
to inspect and fix."
/codeck-export
或 
/codeck-speech
"Review done. Next: 
/codeck-export
for PDF/PPTX, or 
/codeck-speech
for a script."
用户可以随时运行 
/codeck
查看进度。