design-director

name

design-director

description

Use when a product's visual design must be built or rebuilt end-to-end — choosing a design direction or style, setting up a brand identity or design system, or any multi-step UI build where design quality matters. Also use when design feedback keeps not landing ("make it prettier", "still can't see it") or the design drifts between edits. Triggers: design direction, brand identity, redesign, design system, landing page design, 디자인 방향, 브랜드 디자인, 리디자인, 디자인 시스템, 예쁘게 만들어줘. Not for single-element tweaks or tactical polish (use impeccable) or backend-only work.

Design Director

Directs a design build from direction choice to converged, gate-checked UI. The goal is a beautiful, finished UI: gates guarantee the quality floor, the human feedback loop raises the ceiling. Style is a user-chosen input variable; the process and quality axes are invariant. Stack-agnostic.

Entry points

Situation	Enter at
New build, no direction chosen	Phase 0
Existing design + improvement request	Reverse-extract the contract from code → Phase 4
Micro task (one element, one tweak)	Contract check + verify only — or hand to impeccable
Redesign	Phase 0 (old contract = comparison baseline)

Division of labor: single-element tweaks and tactical polish go straight to impeccable. Multi-step builds that need a direction: this skill directs, delegating steps to impeccable / frontend-design where noted.

Iron rules

1. Never one-shot a direction. Every new build starts at Phase 0: genuinely different candidates, a real reference each, the user picks. "The brief is clear enough" is not an exemption — a brief names a style; it does not choose a direction.
2. After Phase 1, every color and font comes from the contract. Need something outside it? Amend the contract first (logged), then implement.
3. Every candidate direction carries one real reference — an actual product/site/artifact. A style name alone is not a reference.
4. No done-claims from code alone. You cannot judge your own visual output without rendering it: screenshot + numeric check before reporting any visual change.
5. The same feedback twice means the fix was below perception threshold. Add a mechanism; do not re-tune the same parameter.
6. Never re-apply anything the user reverted. Re-proposing requires explicitly asking first.

Pipeline

Phase 0 — Diverge

1. Generate 5 direction sketches with probability estimates; inspect the low-probability tail first (the median is the trap).
2. Shortlist 2–4 genuinely different directions — different worlds, not shades of one idea.
3. Anchor each with 1 real reference (user-provided > real product in the domain).
4. AskUserQuestion: one option per direction, mark a recommendation, describe each (3 adjectives + palette seed + reference).
5. User picks. Do not deep-mine references for rejected candidates.

Deliverable: candidates doc + recorded user choice.

Phase 1 — Contract

Load references/contract-template.md. Fix: 3 adjectives · palette (closed set) · type pair · motion vocabulary · anti-list. World lexicon (~10 domain objects/actions) if the style is narrative or immersive; 2–3 light motifs suffice for minimal/product UI. Extract from the chosen reference both ways: qualitative by eye, quantitative from its actual CSS values (no eyeballed hex). After extraction the contract is master, not the reference.

Deliverable: DESIGN-CONTRACT.md in the project + code token file mapped 1:1.

Phase 2 — Skeleton

IA, page roles, scene list → low-fidelity structure check → real-density data (dozens of real items, never 3 dummies).

Deliverable: structure map + lo-fi screenshot.

Phase 3 — Surface (the core phase for the primary goal)

High fidelity, strictly inside the contract. If the frontend-design skill is installed, delegate surface craft to it; otherwise apply the craft rules in references/principles.md. De-template pass: any section shaped like a stock template (icon+title+text card grid, centered hero + two buttons) is re-typeset as a physical form from the world lexicon.

Deliverable: implementation + per-scene screenshots.

Phase 4 — Perception loop (the iteration unit)

For every feedback round: ① Translate the sensory words via references/translation-log.md — diagnose, never implement the words literally → ② if directions fork, AskUserQuestion 2–4 options + recommendation → ③ implement inside the contract (amend first if needed) → ④ verify: eyes + numbers → ⑤ compare side-by-side with the reference → ⑥ commit (one design decision = one commit).

Loop rules: repeated request → mechanism, not parameter (rule 5). "Keep the current design while…" → isolate the change in a separate layer. Verification scope proportional to change radius — full gates only at Phase 5 and major milestones. translation-log is append-only.

Phase 5 — Converge

Run all floor gates from references/quality-gates.md — one failure = not done. Critique pass (delegable, e.g. impeccable critique): triage detector findings into false-positive/brand-intent vs real defect; act only on real defects. reduced-motion = freeze at the final composition (not animations-off blankness). Performance: measure before optimizing. Nothing user-reverted comes back. Close-out: append this project's new sensory-word→technique cases to translation-log.

Deliverable: gate report (4-axis pass table) + appended translation-log entries.

Floor gates (summary — full checklist in references/quality-gates.md)

Axis	Check
Aesthetic craft (primary)	type scale · spacing rhythm · palette harmony · hierarchy · whitespace + full screenshot walk
Direction fidelity	0 out-of-palette colors · 0 non-contract fonts · 0 anti-list hits
Distinctiveness	0 slop-pattern hits (with intent triage)
UX floor	contrast ≥4.5:1 · tap targets · reduced-motion state · keyboard/JS-off · measured bytes

Progressive disclosure

Load reference files only at their phase: P1 → contract-template · P4 → translation-log · P5 → quality-gates · pitfall suspected or P3 without frontend-design → principles. From styles/, load only the playbook matching the chosen direction (e.g. styles/cinematic-scrolltelling.md).

Optional enhancements — never dependencies

The default path completes every phase alone. Use these only when their condition holds; if absent or failing, continue on the default path:

Phase	Default (self-contained)	Optional upgrade — condition
P0 visual compare	AskUserQuestion with descriptions	design-shotgun — many variants on a visual board
P0 reference capture	WebFetch + headless screenshot	browser-automation MCP — dynamic/login pages
P1 quantitative extraction	fetch reference CSS directly	Figma MCP — source is a Figma file
P3 surface craft	craft rules in principles.md	frontend-design skill — if installed
P3 API syntax	own knowledge + web search	context7 — recent-API uncertainty
P4–P5 verification	CDP scripts (recipes in principles.md)	browser-automation MCP — CDP blocked
P5 ceiling critique	screenshot walk + checklist	impeccable critique — dual-agent isolation

Red flags — stop and re-enter the pipeline

• "The brief is clear, I'll start building" → you skipped Phase 0.
• "This hex is close enough to the palette" → contract violation; conform or amend.
• "I'll nudge the value a bit more" after repeated feedback → mechanism, not parameter.
• "It should look right now" without a screenshot → rule 4.
• "The detector flagged it, so remove it" → triage intent first (Phase 5).
• Reaching for the house default (dark theme + single warm accent + default font stack) without a chosen direction → that is the mode-collapse median, not a decision.