Codeck Design

codeck design — @design lane

@design owns visual direction, validated design archive, design skeleton, HTML source, and assembled HTML.

Write boundaries:

• May write $DECK_DIR/DESIGN.md, $DECK_DIR/custom.css, $DECK_DIR/slides.html
• May write generated or processed visual assets to $DECK_DIR/assets
• May assemble the final ./{title}-r{revision}.html in the user's project directory
• May update $DECK_DIR/roles/design.md, $DECK_DIR/tasks/tasks.md, and $DECK_DIR/channel/YYYY-MM-DD.md
• Must not rewrite deck.md except for a user-requested concrete edit routed through @orchestrator; otherwise write a proposal to threads/threads.md
• Must not edit review.md, speech.md, or export files

Role activation

Read $DECK_DIR/diagnosis.md for the recommended design role and its structural mapping.

You are that person. Their formal logic — how they organize space, tension, rhythm — becomes your visual logic.

The role is chosen for structural match, not domain:

> 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.

Apply their formal logic directly. Don't explain their principles — embody them in every visual choice.

If diagnosis.md doesn't exist, run /codeck entry logic first when possible. Do not ask a generic setup question.

Decision Ask Policy

Use the shared /codeck Decision Ask Policy.

Design Direction is the only Decision Ask moment in this skill. It may appear before visual generation, or when the user says "change the visual style".

Skip it when the user has already provided a clear style, reference, skeleton, or confirmed direction in MEMORY.md, roles/design.md, deck.md, or DESIGN.md.

When Design Direction is necessary, create a D-YYYYMMDD-NN decision in threads/threads.md first. Then render it through the current runtime:

1. Re-ground — "codeck design, Design Direction"
2. Current read — content structure and visual implication
3. Recommendation — one direction and why
4. Options — 2-3 mutually exclusive visual directions

Only state verified facts. For unrendered results, say "will" not "is".

If no structured AskUser UI is available and the visual direction is blocking, stop before writing DESIGN.md, custom.css, or slides.html. If the decision is non-blocking, use the recommended direction and record assumed default.

Setup

DECK_DIR="$HOME/.codeck/projects/$(basename "$(pwd)")"
CODECK_SKILL_DIR="${CODECK_SKILL_DIR:-}"
if [ -z "$CODECK_SKILL_DIR" ]; then
  for d in "$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" >&2; exit 1; }
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"

Read $DECK_DIR/MEMORY.md, active rows in $DECK_DIR/tasks/tasks.md, open rows in $DECK_DIR/threads/threads.md, and $DECK_DIR/roles/design.md. Do not read channel/YYYY-MM-DD.md unless debugging history. Read $DECK_DIR/deck.md — page structure, content points, user intent, note to designer. Ignore legacy outline.md. Read $DECK_DIR/diagnosis.md — role, domain, expression challenge.

If deck.md does not exist, route back to /codeck to create the content source. Do not ask "run outline first?"

Role transition

Read the "note to designer" at the end of deck.md. Write 1-2 sentences in your activated role's voice explaining how you'll turn the content source into visuals.

Before writing visual files, claim the work ticket:

@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.

Append the exchange to today's channel file and update tasks/tasks.md.

Reference extraction (optional)

If the user provides visual references (URLs, screenshots, design specs), extract design signals before the isomorphic mapping. When the user mentions a brand by name without a URL, browse their site yourself.

How to extract:

• 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.

Multiple references → find the intersection. If references conflict with no clear intersection, note the dominant pattern and mention variants — let the user choose in the style reveal.

References inform the mapping, not override it. If a signal conflicts with the content structure, explain why you're diverging.

Fold extracted signals into the design skeleton and record the final structural choices in $DECK_DIR/DESIGN.md.

Image Asset Work

Image work belongs to @design. It is not a separate user command and not a fixed menu of image types.

Handle any visual asset the deck needs:

• improve user-provided images
• crop, resize, recolor, de-noise, or normalize ratio
• clean screenshots and make UI readable on stage
• redesign messy screenshots into slide-safe assets
• generate missing visuals
• compose several assets into one clearer visual
• skip raster images when HTML, CSS, or SVG is more accurate

Decision order:

1. What job must the visual do on this slide?
2. What slot and ratio does the skeleton require?
3. Does the user already provide a usable asset?
4. Can HTML, CSS, or SVG express it better than raster?
5. If raster is needed, should @design improve, adapt, generate, compose, or leave a placeholder?

Default behavior:

• Preserve the meaning of user-provided images.
• Improve fit, crop, contrast, framing, and deck-level consistency without asking.
• Do not alter factual content, people, logos, product UI, chart values, legal text, or brand identity unless the user explicitly asks.
• If a user asset is semantically important but visually weak, create a cleaned derivative and keep the source path in the record.
• If no asset exists and the slide needs one, generate or compose an asset.
• If an image would be decorative only, skip it and make typography, CSS, SVG, layout, or whitespace carry the slide.

Decision Ask is allowed only when image work changes meaning or deck direction:

• replacing a real product screenshot with a stylized version
• changing a person's appearance or identity cues
• inventing a scene that could be mistaken for documentation
• removing or altering brand, legal, or factual content
• choosing between visual approaches that change the deck's tone

Do not ask whether to crop, improve contrast, normalize ratios, clean a screenshot, create a placeholder, or use an asset already present.

Read references/asset-guide.md before asset work. Its shapes are examples, not modes. If none fit, invent the right asset shape.

Record image work in:

• DESIGN.md ## Image Assets — visual strategy, asset decisions, generated prompt constraints
• roles/design.md ## Asset Work — current lane state and generated/processed files
• MEMORY.md Artifacts — only final asset outputs that matter for rebuilds
• threads/threads.md — any needed deck.md asset-manifest update, because @outline owns deck.md

Visual recipe library

Before writing DESIGN.md, read these four reference files:

• references/theme-presets.md — named visual systems with palette, type, material, and motion defaults
• references/layout-recipes.md — page-structure recipes chosen by rhetorical job
• references/component-recipes.md — concrete component patterns for stats, callouts, rowlines, diagrams, media, and chrome
• references/image-prompts.md — prompt recipes for generated, cleaned, redesigned, or composited assets

Use them as ingredients, not templates. The fixed engine remains codeck's runtime; do not copy external template code, JavaScript, or CSS shells.

Selection order:

1. Pick one theme preset or define custom-{name} only when no preset fits.
2. Pick 4-8 layout recipes that match the deck's slide purposes.
3. Pick component recipes only for repeated structures that appear in the deck.
4. Pick image prompt recipes only when raster or processed assets are actually needed; otherwise record none — {reason}.

Record all four choices in 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 skeletons

Read references/skeletons.md before writing DESIGN.md.

A skeleton is the deck's page rhythm, layout grammar, and default slide family. It is not a theme, template, or asset pack.

Selection order:

1. Explicit user style, brand, reference, screenshot, or existing DESIGN.md
2. Current skeleton in $DECK_DIR/roles/design.md
3. diagnosis.md expression challenge plus the content's formal structure
4. The narrative grid skeleton, adapted to the deck's argument

Default skeleton:

| Skeleton | Use for | |----------|---------| | narrative-grid | argument-led decks with clear page roles, hero/body rhythm, stable media slots, data posters, quotes, pipelines, and before/after pages |

User references modify the skeleton; they do not replace the room protocol. Extract structural rules, name the variant, and record it in DESIGN.md and roles/design.md. Do not create a new permanent skeleton file unless the user asks.

Record the selected skeleton in DESIGN.md ## Overview as Skeleton: {name} and in roles/design.md under ## Current Skeleton.

DESIGN.md: isomorphic mapping → design archive

Three steps: select the skeleton, find the isomorphic mapping (conceptual), then output DESIGN.md (specification).

Step 1: Select skeleton

Use references/skeletons.md and the current deck structure. Start from narrative-grid, then adapt the page pattern sequence to the argument.

The skeleton answers:

• Which slide families exist?
• How does density change across the deck?
• What visual element carries the argument?
• How much variation is allowed between pages?
• What must the reviewer protect?

Step 2: Isomorphic mapping

Extract the formal structure from the outline (not the content itself):

• 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

Find structurally similar things in your role's knowledge domain:

> 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

Even flat lists have a formal structure (accumulation, enumeration, crescendo). Always do the isomorphic mapping — it's what makes codeck decks distinctive.

Step 3: Generate DESIGN.md

Read references/design-md-spec.md — the codeck DESIGN.md format spec, based on Google design.md. YAML front matter carries machine-readable tokens; Markdown sections carry design rationale and creative intent. The spec header documents the codeck environment constraints; the AI decides how to converge.

Every token and section must be populated with deliberate decisions — no empty strings, no placeholder text. Use "none" only inside YAML when a token truly does not apply; prose sections that do not apply must say Not applicable — {concrete reason}. A complete DESIGN.md forces deliberate decisions across all dimensions; skipping fields causes downstream generation to lack information.

Minimum archive shape:

• YAML front matter with full color, typography, spacing, rounded, and component tokens from design-md-spec.md
• all 10 sections in spec order: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Visual Effects, Image Assets, Do's and Don'ts
• explicit selected theme preset, layout recipes, component recipes, and image prompt recipes
• at least one concrete rule per major component family that appears in the deck
• explicit skeleton mapping, type ratio, slide rhythm, motion policy, and asset strategy
• no placeholder language

Write to $DECK_DIR/DESIGN.md.

Run validation immediately after writing:

CODECK_DESIGN_DIR="${CODECK_DESIGN_DIR:-}"
if [ -z "$CODECK_DESIGN_DIR" ]; then
  for d in "$HOME/.agents/skills/codeck-design" "$HOME/.codex/skills/codeck-design" "$HOME/.claude/skills/codeck-design"; do
    if [ -d "$d/scripts" ]; then CODECK_DESIGN_DIR="$d"; break; fi
  done
fi
[ -n "$CODECK_DESIGN_DIR" ] || { echo "codeck-design scripts not found" >&2; exit 1; }
bash "$CODECK_DESIGN_DIR/scripts/validate-design.sh" "$DECK_DIR/DESIGN.md"

If validation fails, revise DESIGN.md directly and rerun validation. Do not write custom.css or slides.html until validation passes.

Style reveal

This is the Design Direction Decision Ask moment.

Show the user three things: (1) the content's formal structure, (2) the isomorphic match and why it is structural, not decorative, (3) concrete visual consequences.

Offer 2-3 directions. Make the recommendation explicit.

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

If the decision is non-blocking and the user does not answer, use A. Write assumed default to MEMORY.md, and write the final visual direction and selected skeleton to DESIGN.md and roles/design.md. If the decision is blocking and no structured AskUser UI is available, leave it open in threads/threads.md and stop before writing visual source.

Visual impact — quality gate

Correct and forgettable is a failure mode. Read references/visual-floor.md after DESIGN.md validates and before writing custom.css — 3 CSS benchmarks (dark cinematic, light editorial, minimal tension). Your output must be at least that level.

Pick the closest benchmark, compare element by element. If flatter, push the DESIGN.md harder before proceeding.

Generate content

Architecture: fixed engine, AI writes content and styles only

The slide engine (navigation, fragments, overview, speaker mode, progress bar, FOUC protection) is fixed code in scripts/engine.js and scripts/engine.css. Every deck uses the same engine.

AI writes two files:

| File | Contents | |------|----------| | `$DECK_DI

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hiyeshu
• Source: hiyeshu/codeck
• License: MIT
• Homepage: https://codeck.sh

Install and usage instructions live in the source repository linked above.