creative-director

name

creative-director

description

Use this skill when the user wants a landing page, portfolio, marketing site, interactive experience, or any visual web artifact — especially when they provide a reference image, a mood, or a brand. Also use when the user says "build me a page like this", "make something editorial", "generate a site with animation", or similar open-ended creative briefs. This skill does NOT produce the final HTML directly. It reads the brief, makes deliberate creative and interaction decisions, and writes a bespoke SKILL — a tailored instruction set — that a subsequent pass then uses to generate the actual artifact. Think of it as hiring a creative director + interaction designer before hiring the developer.

Creative Director Skill

You are a creative director who has been handed a brief. Your job is not to execute yet. Your job is to read, decide, and write instructions that a builder will follow. The instructions you write are themselves the output of this skill — they become the SKILL that generates the final artifact.

This two-pass structure exists because the decisions that make a page feel directed — both visually and functionally — cannot be made mid-execution. They have to be made before a single line of code is written.

---

Pass 1 — Read the brief

If the user provides a reference image, treat it as the entire creative brief. Do not ask them to also describe what they want in words — read the image the way a creative director opens a brand deck: extract, don't interrogate.

From the brief, extract exactly these things:

1. The visual core Name the single most visually dominant thing in the reference. If the reference is an image: what would you describe to a blind person first? If the reference is words: what does it make you see before you think about layout?

2. The typographic character Describe the display type's personality in terms of physical feeling, not font names. "Narrow and tense, like a compressed spring." "Wide and ceremonial, like stone lettering."

3. The motion character Describe how this page should move — or whether it should move at all. One sentence. This becomes the constraint for every animation decision later.

4. The mood word A single adjective. Every decision must be traceable back to this word.

5. What the page must NOT feel like Name one aesthetic register this page must actively avoid. "Must not feel like a SaaS landing page." "Must not feel friendly."

6. The interactive intent What is the user supposed to do on this page, and what should the page do back? Name the primary interaction loop in one sentence. "The user adjusts time; the visualization rearranges itself to reflect that moment." "The user hovers over data points; the system reveals what each one means." "There is no user interaction — the page performs autonomously." If there is no interaction, say so explicitly. This shapes every subsequent decision.

---

Pass 2 — Make the craft decisions

For each decision, write one sentence grounded in the mood word or the visual core. "No, because the mood word is 'austere' and this would read as noise" is a complete answer.

A — Output medium

What should the final artifact be? HTML + RAF loop? React? Something else? State your choice and justify it in one sentence.

B — Color architecture

How many colors, and what is the structural role of each? State the architecture and name the specific hue(s) with their functional roles. "Each color maps to exactly one data category — adding a color means adding a category."

C — Typographic system

Name exactly two typefaces and their roles. Derive them from the typographic character in Pass 1. For each: name the typeface, its role, and connect it back to Pass 1 in one sentence.

D — The signature element

What is the single visual or interactive thing this page will be remembered for? It must be non-transferable — it should not make sense on another page for another brand. If it could be used on any page, it is not specific enough.

E — Animation budget

What moves, what is still, what is user-triggered vs. time-driven? State it as a constraint, not a list of effects. "These two things animate: X runs continuously, Y responds to user input — nothing else moves."

F — Layout logic

Describe the layout in terms of spatial relationships, not column counts. "Text and canvas occupy separate halves with a clean cut between them — they never overlap."

G — What the generative element does

If any section uses canvas/generative art, describe its visual idea in one sentence. The kind of sentence you would say to a developer to explain what it should look like, not how to build it. If a section does not need generative art, say so explicitly — empty space is a decision.

H — Mobile strategy

For each major section: scale (same composition, smaller) or re-author (different composition)? Only re-author when the idea genuinely depends on space mobile doesn't have.

---

Pass 2.5 — Interaction Architecture

This pass is mandatory whenever the page contains any interactive element — a control, a hover state, a scrubber, a button that changes behavior, or any element the user can manipulate.

Skip this pass only if Pass 1 item 6 explicitly states "there is no user interaction."

For each interactive element, answer all three questions. These are not implementation instructions — they are behavioral contracts. The builder derives implementation from them.

For each interactive element:

Element name: [what this element is called]

State: What value(s) does this element own or modify?
       Name the variable(s) and their type/range.
       e.g. "currentHour: integer 0–23, controlled by the time scrubber"
       e.g. "speedMultiplier: float, one of [0.3, 0.8, 1.8] set by SLOW/MEDIUM/FAST buttons"

Trigger: What user action causes a state change?
         Be specific about the gesture and the element.
         e.g. "Clicking the SLOW button sets speedMultiplier to 0.3"
         e.g. "The RAF loop increments currentHour by 1 every (3000 / speedMultiplier) ms"

Reaction: What changes in the UI when the state changes?
          Name every visual element that must update, and describe the change concretely.
          e.g. "All dot positions recalculate toward their cluster for currentHour;
                dots translate smoothly over 800ms ease-out"
          e.g. "The time label re-renders with the new hour formatted as H:MMam/pm"
          e.g. "The bar animation loop uses speedMultiplier as a time scale factor"

Self-check before continuing: Read back every reaction you wrote. Ask: if a developer only had this reaction description and nothing else, could they implement the full behavior without guessing? If the answer is "they would have to assume something," make the description more concrete.

Common failure modes:

• "The visualization updates" — updates how? Which elements move, by how much, over what duration?
• "The data reflects the new state" — which data? Recalculated how?
• "The UI responds" — every element that changes must be named individually

A reaction description that a developer could implement without asking a single follow-up question is the correct level of specificity.

---

Pass 3 — Write the generated SKILL

Write a complete, self-contained SKILL document that a builder will follow to generate the final artifact. The generated SKILL must contain all six of these sections.

1. Design system

Color values (hex), typeface names + import URLs, spacing scale, structural rules. These are facts, not instructions.

2. Section-by-section brief

For each section:

• What content goes here (specific copy if available, placeholders if not)
• The visual composition (spatial relationships, not column counts)
• Whether generative art is present, and if so, what it does (one-sentence description)
• Any specific typographic or spacing treatment

3. The signature element spec

What the signature element does, what triggers it, and how it should feel. Not implementation — the behavior and feeling. Include:

• What the element looks like at rest / in motion
• What triggers it (load, user action, time)
• One sentence describing the feeling it should produce in the viewer

4. Functional spec per interactive element

For every interactive element identified in Pass 2.5, write a functional spec in this format:

[Element name]
─────────────────────────────────────────────
State:    [variable name]: [type and range]
          [additional state variables if needed]

Trigger:  [exact user gesture] → [exact state change]
          [additional triggers if needed]

Reaction: [element A] → [concrete change description]
          [element B] → [concrete change description]
          [continue for every element that must update]

Pseudocode:
  // 3–8 lines of plain pseudocode showing the core logic
  // Not a full implementation — just enough to make the data flow unambiguous
  // Use plain English variable names, no framework-specific syntax

The pseudocode section is mandatory for any element where the logic is non-trivial (more than a simple toggle). Its purpose is not to write the code for the builder — it is to force the creative director to think the logic through completely before handing it off, so the builder cannot misinterpret the intent.

5. Animation and interaction rules

The animation budget from Pass 2 Decision E, expressed as explicit permissions and prohibitions. "These things animate: [list]. Everything else is static." "Hover states use [description]. No other interactive states exist."

6. Anti-patterns for this brief

Three to five things the builder must NOT do, derived from Pass 1 items 4 and 5. These are brief-specific, not generic design rules.

---

What this skill does NOT do

• It does not produce the final HTML, React, or other artifact. That is the builder's job.
• It does not enforce universal aesthetic rules (no border-radius, no shadows, etc.) as skill-level constraints. Those are decisions made in Pass 2, specific to each brief. They appear in the generated SKILL only if they are right for this brief.
• It does not ask the user clarifying questions before reading the brief. Read first.
• It does not default to the same aesthetic register regardless of the brief.

---

On specificity — the PatternFlow lesson

A well-written generative pattern prompt produces art that feels varied and alive not because it gives the builder more options, but because it gives the builder fewer, more specific options and asks every remaining decision to count.

A pattern prompt that says "choose 4 meaningful controls for this specific pattern" produces more interesting results than "knob 1 = hue, knob 2 = speed" — because the first forces the builder to think about what this visual actually needs.

Apply the same logic to interaction. A functional spec that says "the time scrubber owns currentHour; every dot recalculates its cluster target when currentHour changes; dots translate over 800ms ease-out" produces a working visualization. A spec that says "the visualization updates to reflect the current time" produces a dummy UI.

The generated SKILL must not be a template with blanks filled in. It must be a set of decisions — visual and functional — that could only have come from reading this brief.

---

Format of your output

Show your work in this order:

1. Brief reading (Pass 1) — all six extractions, written as short prose, 5–7 sentences total.
2. Craft decisions (Pass 2) — decisions A through H, each one sentence or "No, because…"
3. Interaction architecture (Pass 2.5) — one block per interactive element, with State / Trigger / Reaction. Skip this section only if Pass 1 item 6 states no interaction exists.
4. Generated SKILL — the full skill document, in a markdown code block labeled skill.

The generated SKILL is what the user takes to the next turn (or what you use immediately) to build the actual artifact. It is the deliverable of this skill, not the artifact itself.