$DECK_DIR/diagnosis.md

Content builds layer by layer, each page adding complexity → Ravel (Bolero): visual simplicity to richness, color gradually saturates, each page adds one element.

Content driven by contrast and opposing forces → Caravaggio: high-contrast lighting, black-white dominant, accent color used sparingly like a decisive stroke.

Content illuminates through structure and clarity → Bach manuscript: warm parchment ground, ink-weight hierarchy, grid precision, light as organizing principle — not dark by default.

Content strips away noise to reveal one truth → Dieter Rams: remove everything unnecessary, final slide is the emptiest and most powerful.

diagnosis.md

/codeck

1. Re-ground — "codeck design, {current step}"
2. Simplify — plain language
3. Recommend — suggestion + reason
4. Options — choices

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

$DECK_DIR/outline.md

$DECK_DIR/diagnosis.md

• A) Run

  /codeck-outline

  first
• B) Skip — I'll describe what I want

• Color: primary by area dominance, secondary by supporting role, accent by CTA usage. Map neutral scale from lightest background to darkest text.
• Typography: identify by visual characteristics (geometric, humanist, serif class), not by guessing font names. Estimate scale ratio from heading/body size relationship.
• Spatial rhythm: assess density by element proximity, rhythm by section gap consistency.
• Material/texture: classify shadow softness, spread, layering. Note glass, grain, gradients.
• Motion: if observable, note easing curves and duration feel.

$DECK_DIR/design-notes.md

## References

• Tension curve — narrative tension-release rhythm
• Information density — where it's dense, where it breathes
• Argument topology — linear, branching, layered, contrastive
• Emotional arc — what emotion to what emotion

A layered business proposal → Ravel's Bolero → visually simple to complex, each page adds a layer, color gradually saturates

A contrastive technical argument → Go (围棋) attack and defense → black-white contrast dominant, each turn uses one accent color as a "move"

A structured explanation that builds understanding → architectural blueprint → warm off-white ground, precise lines, information revealed through spatial hierarchy, not through darkness

A data report moving from chaos to order → Japanese karesansui → early pages scattered, final page stripped to minimal

• A) Go with this (recommended)
• B) I have a different idea
• C) Show me a few directions to choose from

1. Page navigation — arrow keys / space / PageDown
2. Fragment stepping —

   data-f="N"

   attribute, ArrowDown to reveal, ArrowUp to hide
3. Overview mode — Esc toggle, thumbnail grid, click to jump
4. Progress bar + page number — auto-created
5. Mobile navigation — auto-created bottom button bar
6. FOUC protection — double rAF before display
7. Speaker notes — reads

   data-notes

   attribute
8. Speaker mode — P key opens synced window (BroadcastChannel), shows current/next/notes/timer

<!-- ====== 1. Cover ====== -->
<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>

<!-- ====== 2. Problem ====== -->
<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>

• Each

  <section class="slide" data-notes="...">

  is one page

• data-notes

  : 1-2 sentence summary of that page's key point from outline.md
• Separate pages with comments:

  <!-- ====== N. Title ====== -->

• Free HTML inside — no block type restrictions

• data-f="N"

  : fragment stepping (lower N appears first)
• No

  <script>

  tags, progress bar, or mobile nav — engine handles all of it

1. Write

   $DECK_DIR/custom.css

   with Write tool
2. Write

   $DECK_DIR/slides.html

   with Write tool
3. Run assemble.sh with Bash

1. Page count — matches outline.md?
2. Comment anchors — every page has

   <!-- ====== N. Title ====== -->

   ?
3. data-notes — every slide section has the attribute?
4. CSS variables —

   :root

   defines

   --bg

   ,

   --fg

   ,

   --accent

   ,

   --font-body

   ,

   --font-heading

   ?
5. Mobile — custom.css has

   @media (max-width: 768px)

   ?
6. Content accuracy — text comes from source material, no fabricated data?
7. No engine code — no

   <script>

   tags in slides.html?

• {Decision and reason}
• ...

{1-2 sentences in the role's voice: design intent and the one thing worth watching}

undefined

codeck design — HTML generated. Anything to adjust?

You can say "change slide 3 title to xxx" or "switch to a warm palette".

• A) I want changes
• B) Looks good, next step

$DECK_DIR/slides.html

$DECK_DIR/custom.css

• Google Fonts allowed, but always with fallback. Use

  @import url()

  at the top of custom.css — assemble.sh places it inside

  <style>

  in

  <head>

  . Always include a system font fallback stack. Offline = fallback renders, no breakage.
• No

  <script>

  in slides.html. Engine handles all JS. A stray

  <script>

  causes double-binding, broken navigation, and mystery bugs.

• :root

  variables are an API contract.

  --bg

  ,

  --fg

  ,

  --accent

  are consumed by engine.css. Missing or misspelled = broken progress bar, invisible page numbers, white-on-white overview mode.
• Fragment numbers must be sequential starting from 1.

  data-f="1"

  ,

  data-f="2"

  , etc. Gaps (1, 3, 5) cause the engine to skip steps. Duplicates cause simultaneous reveals.
• Don't override engine classes.

  .slide

  ,

  #progress

  ,

  .mobile-nav

  ,

  .presenter-*

  belong to the engine. Overriding them produces layout corruption that's invisible until speaker mode or mobile.
• Never set

  position

  on

  .slide

  or slide-type classes.

  .slide

  is

  position: absolute; inset: 0

  in engine.css — that's what makes it fill the viewport.

  position: relative

  on

  .slide-cover

  etc. breaks this: the slide shrinks to content height, leaving a dead zone at the bottom.
• CSS animations +

  prefers-reduced-motion

  . If custom.css has

  @keyframes

  , wrap them:

  @media (prefers-reduced-motion: no-preference) { ... }

  . Skip this = accessibility failure.
• Hard-coded colors in slides.html = unmaintainable. One palette change and you're hunting through 30 slides. Use CSS classes and

  var()

  exclusively.
• Cover slide defaults to centered title + subtitle. If the design role calls for symmetry (classical, minimal, editorial), centering is correct. Otherwise, break it — asymmetry signals intentional design.
• CSS negation of math functions silently fails.

  -clamp(...)

  ,

  -min(...)

  ,

  -max(...)

  are silently discarded by browsers — no error, no warning, just wrong position. Always write

  calc(-1 * clamp(...))

  instead.
• Height breakpoints, not just width. Laptops with browser chrome show ~600px viewport height. Add

  @media (max-height: 700px)

  and

  @media (max-height: 500px)

  to reduce title sizes and hide decorative elements. Width-only breakpoints miss the most common overflow scenario.
• Content density has hard limits. Title slide: 1 heading + 1 subtitle max. Content slide: 1 heading + 6 bullets or 2 short paragraphs max. Data slide: 1 heading + 4 metric cards max. Code slide: 10 lines max. Exceeding these = viewport overflow. Split into multiple slides, never cram.
• Assemble.sh auto-increments revision. Don't manually name output files. Let the script handle

  r1

  ,

  r2

  , etc. Manual names break the revision chain.

codeck design complete.

{One sentence — cite the design-dna isomorphic mapping}

Output:

./{title}-r{revision}.html

(in user's project directory) Intermediates:

$DECK_DIR/design-dna.json

+

$DECK_DIR/design-notes.md

Next:

/codeck-review