Design Skill

Design Skill

Design Skill is the router for design-related HTML artifact work.

It decides:

• whether the task is design-related
• which artifact skill should be primary
• whether the task should use design-system-reference.md
• whether the task should use design-system-generation.md
• whether the task should use export.md
• how much clarification is needed before acting
• how to read the request quickly before routing (see "Before generating")
• how to apply built-in design quality defaults
• how to keep generated HTML structured for future edits

Design Skill should stay small.

Artifact-specific structure rules belong in artifact skill files. Business judgment for a scenario lives inside that scenario skill. Cross-cutting craft rules belong in horizontal-craft/. Reference selection belongs in design-system-reference.md. DESIGN.md import / extraction / persistence belongs in design-system-generation.md. Export / package / handoff belongs in export.md.

The default first-stage deliverable is a design artifact, usually HTML unless the selected artifact skill or export target requires a fixed-image, deck, package, or design-system spec. Export is invoked when the user asks to package, download, convert, or hand off the current artifact.

The flow (read this once; it governs everything below)

The whole skill is one flow. Most of it is internal and instant — it only pauses when a request is genuinely ambiguous. Do not turn any step into a form to fill or a file you must read first.

USER REQUEST
   │
   ▼
1. UNDERSTAND (internal, silent for obvious requests) — resolve three axes in parallel:
     • content  — subject, information, goal
     • scenario — form + intent  → which scenario skill   (see Routing)
     • style    — what kind of style cue, if any           (see Style Routing)
   Obvious on all three → proceed. Only ONE axis genuinely unclear → ask one focused question.
   For open-ended / creative requests, understanding also includes a creative read, not just these
   operational axes — complete the creative context + Design Read (see §Creative Context Completion).
   │
   ▼
1.5 CHECK TEMPLATES (do this by default, not only when asked)
   Scan `design-templates/INDEX.md` by carrier + scenario for a match to the request.
     • Clear match  → adopt it as the starting point; read that template's SKILL.md. Using a
                      matching template usually raises quality — prefer it over designing from scratch.
     • No good match → proceed with the scenario skill directly. Never force a template that doesn't fit.
   A template is a starting structure/skeleton, not a page to clone — keep the user's real content,
   apply the scenario skill + horizontal craft, do not copy the reference's exact layout fingerprint.
   │
   ▼
2. FILL STYLE BY PRIORITY (per dimension: color · type · layout · icons · spacing tokens)
   For each dimension, take it from the highest-priority source that covers it:
     1) user's immediate description   ← highest; dimensions it touches are locked
     2) design system (DESIGN.md)      ← fills dimensions the user didn't speak to
     3) template / seed                ← fills what's left (esp. layout scaffold)
     4) parallel constraints           ← fallback for any still-empty dimension
        (load only the ones you need: type / icons / color / a11y …)
   Sources combine — e.g. design-system tokens + a template's layout is normal.
   Style cue is a vague mood word, not a named system ("清新/简约/高级/科技感/复古/温暖/极简/
   赛博" etc.): do NOT just free-associate a look — match it to the library. Read
   `design-systems/style-skills` index (and brand `index.json`) and pick the entry whose `mood` /
   `formality` / `scheme` tags best fit the words, then use it as the base. The style tags are the
   bridge from a user's adjective to a concrete system (e.g. 清新简约 → 极简/克制 → `minimal`/`clean`;
   高级 → 奢华/克制 → `luxury`/`refined`; 科技感 → 技术感/未来 → `futuristic`/`hud`). Only design
   from scratch if nothing in the library fits the mood.
   No style cue at all + scene is restrained / not creativity-driven (tool, dashboard, admin,
   form, report, notice, generic SaaS/corporate page): do NOT design a style from scratch —
   actively pick a mature baseline from `design-systems/` (see Mature System Fallback) so the
   result is professional and consistent. (Expressive scenes that want a distinct look skip this
   and go bold per §Creative Context.)
   Conflict: if the user's description contradicts the design system on a dimension,
   the user wins on that dimension — AND say so in one line
   ("Built it <X> as you asked; note this differs from the attached design system —
    tell me if you'd rather keep the system's direction.")
   │
   ▼
3. BUILD using the scenario skill's judgment + the filled style.
   │
   ▼
4. QUALITY GATE — run quality-gate.md as a thin final checklist before delivering.