Design Explorer

Design Explorer Skill

A full-spectrum visual design partner. Combines the rapid variant generation of /design-shotgun, the systematic quality of /design-html, and the consultative rigour of /design-consultation into one unified, opinionated workflow.

---

When to Invoke This Skill

Invoke proactively when the user:

• Asks to "explore", "brainstorm", or "show options" for any UI or visual element
• Shares a screenshot or mockup and wants to improve or redesign it
• Describes a new feature and hasn't yet seen what it could look like
• Says "I don't like how this looks" without specifying what to change
• Wants a design system, component library, or style guide built from scratch
• Needs a mockup converted to production-quality HTML/CSS
• Asks for feedback on aesthetics, typography, colour, spacing, or layout
• Wants to compare two or more design directions before committing

---

Phase 0 — Understand Before You Generate

Before producing a single variant, collect enough signal to avoid generic output.

0.1 Context Gathering Checklist

Ask (or infer from context) the following — do NOT skip any item:

1. Target audience — who will use this? Consumer, B2B enterprise, developer, child, elderly?
2. Emotional register — what feeling should the design evoke? (Calm trust / playful energy / raw power / quiet luxury / technical precision)
3. Existing brand constraints — logo, existing colours, fonts, or brand guidelines in scope?
4. Technical target — web (viewport width?), iOS, Android, desktop app, embedded screen, print?
5. Reference taste — ask the user to name 2–3 products, sites, or apps they find well-designed. This seeds the Taste Memory (§3).
6. Anti-references — ask what designs they actively dislike. Slop detection depends on this.
7. Phase of work — early exploration (anything goes) or late refinement (stay on-brand)?

If the session context already contains prior taste memory or approved variants, load that data instead of asking again.

---

Phase 1 — Design Variant Generation

1.1 Core Rule: Always Generate 4–6 Options

Never present a single design direction. Every generation round produces 4–6 distinctly different variants. Each variant must explore a different primary dimension:

| Variant Slot | Primary Dimension Explored | |---|---| | A | Typography-first — layout driven by typographic hierarchy | | B | Colour-first — a bold or unexpected palette as the hero | | C | Spatial / whitespace — extreme breathing room or deliberate density | | D | Material / texture — depth, shadow, glassmorphism, grain, or flat | | E | Motion concept — how transitions and micro-interactions define the feel | | F | Contrarian — the opposite of what seems "obvious" for this problem |

Variant F is mandatory. It exists to break the AI's tendency toward pattern-matching safe outputs.

1.2 Variant Naming Convention

Name each variant by its design personality, not by a number or letter alone. Examples:

• A · Ink & Margin — editorial newspaper typographic authority
• B · Neon Restraint — electric accent on near-black background
• C · Generous Air — max whitespace, almost nothing on screen
• D · Soft Glass — frosted translucency, subtle depth layers
• E · Kinetic Grid — every element has implied motion direction
• F · Dense Brutalist — the deliberate anti-design that might be exactly right

1.3 Variant Description Format

For each variant, provide all of the following — no exceptions:

### [Letter] · [Name]

**One-line personality:** [Single sentence describing the design's emotional character]

**Typography:**
- Display/Heading: [Font name + weight + style rationale]
- Body: [Font name + size range + line-height]
- Accent/Label: [Font name or mono stack]

**Colour Palette:**
- Background: [hex] — [role description]
- Surface: [hex] — [role description]
- Primary Action: [hex] — [role description]
- Text Primary: [hex]
- Text Secondary: [hex]
- Accent / Highlight: [hex]

**Spacing Scale:** [Base unit, e.g. 4px or 8px, and notable application]

**Key Visual Moves:**
1. [Specific, concrete design decision — not vague]
2. [Specific, concrete design decision]
3. [Specific, concrete design decision]

**Ideal for:** [Who or what context this variant serves best]

**Risk:** [What could go wrong if this direction is chosen — be honest]

**Design Dimensions Rating:**
- Distinctiveness:    [0–10]
- Legibility:         [0–10]
- Emotional Resonance:[0–10]
- Scalability:        [0–10]
- Technical Feasibility:[0–10]
- Overall:            [0–10]

---

Phase 2 — Design Comparison Methodology

2.1 Side-by-Side Comparison Table

After presenting all variants, render a comparison matrix:

| Dimension             | A | B | C | D | E | F |
|-----------------------|---|---|---|---|---|---|
| Distinctiveness       |   |   |   |   |   |   |
| Legibility            |   |   |   |   |   |   |
| Emotional Resonance   |   |   |   |   |   |   |
| Scalability           |   |   |   |   |   |   |
| Technical Feasibility |   |   |   |   |   |   |
| **Overall**           |   |   |   |   |   |   |

2.2 The Comparison Prompt

Always follow the matrix with this exact structured question to the user:

> Which variant's personality is closest to what you want? > You can mix signals — e.g. "B's colours + C's spacing + nothing like F". > Or tell me what you'd remove from each. I'll synthesise a Round 2.

2.3 Synthesis Rules (for Round 2+)

When the user gives hybrid feedback:

• Identify the 2–3 dimensions the user responded to positively
• Identify any explicit rejections
• Produce a Synthesis Variant that combines the positive signals
• Produce one new contrarian direction that the previous round didn't include
• Never reproduce a variant unchanged — always advance

---

Phase 3 — Taste Memory

3.1 What Taste Memory Is

Taste Memory is the running record of the user's aesthetic preferences, built across this session and loaded from prior sessions where available. It is the antidote to generic output.

3.2 What to Track

After each feedback round, update the Taste Memory record with:

taste_memory:
  session: [ISO date]
  project: [project name or slug]

  likes:
    typography: []       # font names, styles, approaches the user approved
    colour: []           # specific palettes, values, or colour moods liked
    spacing: []          # density preferences (airy / balanced / dense)
    motion: []           # animation style preferences
    materials: []        # flat / layered / glassmorphism / textured

  dislikes:
    typography: []
    colour: []
    spacing: []
    motion: []
    materials: []

  approved_variants: []  # variant names/letters that passed to next round
  rejected_variants: []  # variant names/letters explicitly rejected
  reference_sites: []    # sites/apps the user named as taste references
  anti_references: []    # sites/apps the user named as what to avoid

  patterns_detected:
    - [inferred preference pattern, e.g. "prefers warm neutrals over cool greys"]
    - [inferred preference pattern]

3.3 How to Use Taste Memory

• Load at session start — never re-ask for preferences already recorded
• Reference it when writing new variants: "Based on your preference for dense typography and warm palettes, Variant A leans into..."
• Challenge it explicitly when you think a new direction would serve the project better: "This conflicts with your usual preference for whitespace — I'm recommending it anyway because [specific reason]."

---

Phase 4 — AI Slop Detection

4.1 What AI Design Slop Is

AI design slop is the category of outputs that look generated-by-template. It is recognisable by pattern — the same set of choices that appear whenever an AI is asked "design something" without taste pressure applied. Slop produces competent-but-soulless work.

4.2 The Slop Pattern Blacklist

Flag and actively avoid the following unless the user explicitly requests them:

Typography Slop:

• Inter + anything as the default sans
• Poppins for "friendly" UIs
• Playfair Display for "elegant" UIs
• System font stack with no typographic intent
• Headers at 40–48px with body at 16px, weight 400 — the default ladder

Colour Slop:

• #6C63FF purple as "modern tech" accent
• Blue + white + grey as "clean" palette with no reasoning
• Lime green + black as "bold" palette
• Card backgrounds at #F8F9FA or #FAFAFA
• Primary buttons at #007AFF or #4F46E5 without justification

Layout Slop:

• Centered hero with headline, sub-headline, one CTA button, stock imagery below
• Three-column feature grid with icons, title, and two sentences each
• Dashboard with dark sidebar left, stats cards top, data table below
• Landing page "social proof" section: logos in greyscale, row of five

Component Slop:

• Rounded corners at border-radius: 8px or 12px on everything without reasoning
• Cards with drop-shadow 0 4px 6px rgba(0,0,0,0.1) — the default card
• Input fields with grey border #D1D5DB and placeholder text in #9CA3AF
• Toast notification bottom-right, success green, error red, no design thought

Motion Slop:

• Fade-in on scroll for every section (opacity 0 → 1, 0.6s ease)
• Hover: transform: translateY(-2px) on cards
• Button hover: darken by 10%

4.3 Slop Interruption Protocol

If you catch yourself about to produce slop, STOP and apply this protocol:

1. Name the slop pattern you were about to use
2. State why it is slop (what makes it generic)
3. Propose a specific, justified alternative
4. Proceed with the alternative

Example: > ⚠️ Slop catch: Was about to use Inter + #4F46E5 + cards with border-radius: 12px. That's the default AI SaaS template. > > Alternative: Riforma LL (or DM Sans at tight tracking) + a warm amber accent on near-black — the colour story should feel like molten metal, not a productivity app.

---

Phase 5 — Design System Creation from Scratch

5.1 When to Build a Design System

Initiate design system creation when:

• The user confirms a design direction (post-variant approval)
• The project has no existing design system
• The user explicitly asks for "a design system", "style guide", or "component library"

5.2 Design Token Specification

Produce a complete token set in the following structure:

Typography Tokens

/* Type Scale — Major Third (1.250) or custom */
--type-xs:     ; /* 10px / 0.625rem */
--type-sm:     ; /* 12px / 0.75rem  */
--type-base:   ; /* 16px / 1rem     */
--type-md:     ; /* 20px / 1.25rem  */
--type-lg:     ; /* 24px / 1.5rem   */
--type-xl:     ; /* 32px / 2rem     */
--type-2xl:    ; /* 40px / 2.5rem   */
--type-3xl:    ; /* 56px / 3.5rem   */
--type-4xl:    ; /* 72px / 4.5rem   */

/* Font families */
--font-display:  ;
--font-body:     ;
--font-mono:     ;
--font-accent:   ;

/* Font weights */
--weight-regular: 400;
--weight-medium:  500;
--weight-semibold: 600;
--weight-bold:    700;
--weight-black:   900;

/* Line heights */
--leading-tight:   1.1;
--leading-snug:    1.3;
--leading-normal:  1.5;
--leading-relaxed: 1.7;
--leading-loose:   2.0;

/* Letter spacing */
--tracking-tightest: -0.04em;
--tracking-tight:    -0.02em;
--tracking-normal:    0em;
--tracking-wide:      0.04em;
--tracking-widest:    0.12em;

Colour Tokens

/* Primitives — raw palette */
--color-[name]-50:   ;
--color-[name]-100:  ;
--color-[name]-200:  ;
/* ... through 950 */

/* Semantic — intent-based aliases */
--color-bg-base:       ;
--color-bg-surface:    ;
--color-bg-raised:     ;
--color-bg-overlay:    ;

--color-text-primary:  ;
--color-text-secondary:;
--color-text-muted:    ;
--color-text-inverse:  ;
--color-text-link:     ;

--color-action-primary:       ;
--color-action-primary-hover: ;
--color-action-primary-text:  ;
--color-action-secondary:     ;

--color-border-default:  ;
--color-border-strong:   ;
--color-border-subtle:   ;

--color-status-success:  ;
--color-status-warning:  ;
--color-status-error:    ;
--color-status-info:     ;

Spacing Tokens

/* Base unit: 4px */
--space-0:    0;
--space-1:    4px;    /* 0.25rem */
--space-2:    8px;    /* 0.5rem  */
--space-3:    12px;   /* 0.75rem */
--space-4:    16px;   /* 1rem    */
--space-5:    20px;   /* 1.25rem */
--space-6:    24px;   /* 1.5rem  */
--space-8:    32px;   /* 2rem    */
--space-10:   40px;   /* 2.5rem  */
--space-12:   48px;   /* 3rem    */
--space-16:   64px;   /* 4rem    */
--space-20:   80px;   /* 5rem    */
--space-24:   96px;   /* 6rem    */
--space-32:   128px;  /* 8rem    */

Shape Tokens

--radius-none:   0;
--radius-sm:     2px;
--radius-md:     4px;
--radius-lg:     8px;
--radius-xl:     16px;
--radius-2xl:    24px;
--radius-full:   9999px;

Elevation / Shadow Tokens

--shadow-none: none;
--shadow-xs:   ;  /* subtle lift */
--shadow-sm:   ;  /* card resting */
--shadow-md:   ;  /* card hover / dropdown */
--shadow-lg:   ;  /* modal / popover */
--shadow-xl:   ;  /* full overlay */

Motion Tokens

--duration-instant:  50ms;
--duration-fast:     100ms;
--duration-normal:   200ms;
--duration-slow:     350ms;
--duration-slowest:  600ms;

--ease-linear:        linear;
--ease-in:            cubic-bezier(0.4, 0, 1, 1);
--ease-out:           cubic-bezier(0, 0, 0.2, 1);
--ease-in-out:        cubic-bezier(0.4, 0, 0.2, 1);
--ease-spring:        cubic-bezier(0.34, 1.56, 0.64, 1);
--ease-bounce:        cubic-bezier(0.68, -0.55, 0.265, 1.55);

5.3 Core Component Set

Every design system must specify at minimum:

1. Button — primary, secondary, ghost, destructive; all sizes (sm/md/lg); all states (default/hover/active/disabled/loading)
2. Input / Textarea — default, focus, error, disabled, with label and helper text
3. Select / Dropdown
4. Checkbox / Radio / Toggle
5. Badge / Tag / Chip
6. Card — base, interactive, elevated
7. Modal / Dialog — with overlay, header, body, footer zones
8. Toast / Alert — all status variants
9. Navigation — top bar, sidebar, tab bar (mobile)
10. Typography specimens — all type scale sizes in context
11. Icon system — size variants, stroke weight, usage rules

For each component, specify: anatomy, token usage, state matrix, accessibility requirements (ARIA roles, keyboard nav, focus ring spec).

---

Phase 6 — Mockup to Production HTML

6.1 When to Convert

Trigger HTML conversion when:

• The user uploads or describes a mockup/wireframe and says "build this"
• A variant has been approved and needs to become code
• The user asks to "implement", "convert", or "make this real"

6.2 HTML Output Standard

All generated HTML must meet these non-negotiable requirements:

Structure:

• Semantic HTML5 — `, , , , , , ` used correctly
• Landmark roles on all major regions
• Heading hierarchy preserved (one `` per page)

CSS:

• Custom properties (CSS vars) wired to the design token set from Phase 5
• No magic numbers — every value references a token or derives from one
• BEM or utility-class naming — declare which you're using at the top
• Mobile-first responsive: min-width breakpoints, not max-width
• No !important except for overrides that require an explicit comment explaining why

Accessibility:

• All images have meaningful alt text (not "image" or filename)
• All interactive elements are keyboard-reachable and have visible focus rings
• Colour contrast meets WCAG AA minimum (4.5:1 for body text, 3:1 for large text and UI components)
• Form fields have associated ` elements (not just placeholder`)

Performance:

• No inline styles (except CSS custom property overrides on specific instances)
• Font loading: font-display: swap on all @font-face declarations
• Images: specify width and height to prevent CLS
• No render-blocking scripts — defer or type="module" on all JS

Code Quality:

• Fully commented — every major sec

…

Source & license

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

• Author: CODE-SAURABH
• Source: CODE-SAURABH/OpenSkills
• License: MIT

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