codeck-design

<!--
[INPUT]: Depends on deck.md, diagnosis.md, DESIGN references, and room decision state.
[OUTPUT]: Provides validated DESIGN.md, custom.css, slides.html, assembled HTML, and design lane memory.
[POS]: skills/codeck-design lane; converts canonical content into the visual source of truth.
[PROTOCOL]: 变更时更新此头部，然后检查 CLAUDE.md
-->

# 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

```bash
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:

```markdown
@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