New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Design Exploration

by carson2222 in carson2222/skills

Generates several visual directions for a component or page, lets you compare them, then fully implements the one you pick.

Apache-2.0Auto-check passedFrontend & Design

Install Design Exploration

skills CLI
$ npx skills add carson2222/skills --skill design-exploration -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install carson2222/skills design-exploration --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/carson2222/skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/design-exploration .claude/skills/design-exploration && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
design-exploration
GitHub stars
113
Token cost
~3.3k tokens
SKILL.md length
1,815 words
Files
1
Skills in repo
3
Repo updated
First seen
Licence
Apache-2.0

At a glance

Generates several visual directions for a component or page, lets you compare them, then fully implements the one you pick.

  • Works in 2 steps: New project → Existing app
  • Redesigning or restyling a component or page
  • SKILL.md covers When to Trigger, Phase 1: Research, Phase 2: Generate Variants and Phase 3: Implementation, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

The skill builds a requested number of design variants (the default is 5), each taking a fundamentally different visual direction, presents them for comparison and then implements the winner. It decides on its own whether the project is new or existing: a new project has no design system, so the variants define one, while an existing app keeps every variant consistent with its patterns and tokens.

Research comes first: reading the target code, studying the design language in globals.css, the Tailwind config and the component library, noting what must not change, checking assets and looking for data that could be shown differently. For new projects it looks across disciplines such as editorial, print, architecture and packaging rather than relying on memorized style lists. If you supply exact fonts, colors and styling, it skips exploration and applies them.

When your agent uses it

  • Redesigning or restyling a component or page
  • Comparing several visual directions before committing
  • Bootstrapping a frontend that has no design system yet
  • Exploring dashboard or landing page layouts

Example prompts

  • “Redesign the pricing section and give me five different directions to compare.”
  • “Explore design options for the dashboard header while keeping our current tokens.”
  • “Create multiple visual directions for the landing hero.”

Workflow steps

2 steps, taken from the step headings in SKILL.md.

  1. New project
  2. Existing app

What it can do on your machine

Read from SKILL.md and the folder at commit c29af03. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Design Exploration loads about 3.3k tokens when it runs. Until then it costs about 99 tokens; SKILL.md has 1,815 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~99
When it runs · the whole SKILL.md, loaded when a task matches
~3.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from carson2222/skills at commit c29af03, republished under its Apache-2.0 licence (© carson2222). 1,815 words, ~3,322 tokens.

Download SKILL.mdSave it as .claude/skills/design-exploration/SKILL.md (or your agent's skills folder).
name
design-exploration
description
Generates multiple distinct design variants of a component or page, each with a completely different visual direction, then implements the chosen one. Use when the user asks to redesign, restyle, explore design options, create multiple visual directions, or compare design approaches for any UI element -- components, pages, sections, dashboards, landing pages, or full layouts.
license
Apache-2.0

Design Exploration

Generate N distinct design variants for a given component, page, or section. Each variant takes a fundamentally different visual direction. Present all for comparison, then fully implement the chosen one.

When to Trigger

1. New project

The user is bootstrapping a frontend from scratch. No existing design system -- the variants define it.

2. Existing app

The user has an established design language and wants multiple approaches for a new or existing component, section, or page. Every variant must stay consistent with the app's existing patterns and tokens.

Bypass: Detailed design spec provided

If the user provides exact fonts, colors, hex values, border radii, and specific styling instructions -- skip Phase 2 entirely. This is an implementation request, not an exploration request. Do not suggest alternatives or inject creative direction. Read each target file, preserve all logic, apply exactly the specified changes. Go directly to Phase 3.

Phase 1: Research

Before designing anything:

  1. Read the existing code -- understand every component, import, animation, and logic in the target files.
  2. Study the design language -- globals.css, tailwind config, component library, existing patterns (spacing, colors, typography, card styles).
  3. Identify constraints -- what must NOT change: data, logic, API calls, routing, state management.
  4. Understand the content model -- what data is displayed, edge cases (long text, many items, empty states).
  5. Check assets -- verify images, icons, and assets exist with correct formats (transparency, resolution, aspect ratio). If assets need preprocessing (background removal, format conversion), handle that before building variants on top of them.
  6. Look beyond the brief -- find data values available in the codebase but not currently displayed, existing assets that could be repurposed, values that could be visualized differently (charts, progress bars, indicators instead of plain text), opportunities for grouping or layering information.

Phase 2: Generate Variants

Create exactly the number requested (default: 5). Determine mode automatically based on project state -- do not ask.

Mode A: New Project

No existing design system to follow.

  1. Research broadly -- search for design approaches across disciplines: product design, editorial, print, architecture, fashion branding, game UI, packaging. Do not rely on memorized style lists.
  2. Analyze context -- product purpose, audience, intended mood. A trading app has different needs than a portfolio.
  3. If context is insufficient, ask -- what is the product, who is it for, what feeling should it evoke. Exception: if the user explicitly wants broad exploration, skip this.
  4. Select styles optimal for this project -- each must be a plausible direction for this exact product, not a showcase of range. Respect explicit style exclusions as hard constraints. Do NOT fall into deterministic patterns of always picking the same style families.
  5. Maximize diversity -- every variant must differ in spatial thinking, typographic voice, and emotional register. Not "same layout, different colors."
Mode B: Existing App

Established styles, tokens, components, and patterns exist.

  1. Study the design system first -- globals.css, tailwind config, theme tokens, color palette, typography, spacing, animation conventions, border radii, card styles.
  2. The app's style is the baseline -- all variants must be consistent with the existing system. You are exploring different layouts and compositions, not different design systems.
  3. Vary structure, not identity -- differ in layout, information hierarchy, component composition, animation approach, and density. Do NOT differ in font families, color palette, or border radius unless the user explicitly asks for a style refresh.
  4. Align with surrounding UI -- match sizing, spacing, and alignment of adjacent elements. If next to a button, match its height. If inside a card grid, follow the same padding and gap.
  5. Style change escape hatch -- if the user explicitly asks for a style change, break from the existing system. Treat it closer to Mode A but use the current app as context.
Required Differentiation

Each variant MUST differ across ALL of these axes:

AxisMode A (New)Mode B (Existing)
TypographyDifferent font pairing per variantUse app fonts; vary weight, size, hierarchy
ColorDifferent accent, background, contrast approachUse app palette; vary application and emphasis
LayoutGrid vs. list vs. asymmetric vs. card-based vs. dense vs. airyDifferent arrangement within app conventions
MoodDistinct personality per variant, discovered through researchDistinct compositional approach, shared personality
Border/radiusSharp vs. rounded vs. pill vs. mixedUse app's existing radius
MotionDifferent animation philosophyDifferent choices within app motion conventions
BackgroundSolid vs. gradient vs. texture vs. pattern vs. atmosphericUse app patterns; vary section treatments
Variant Rules
  • No AI slop -- no generic purple-on-white, no Inter/Roboto/Arial or system-font defaults, no cookie-cutter card grids, no Space Grotesk convergence across sessions. See Anti-convergence in Aesthetic Standards for the current cliché palettes to steer around.
  • No gimmick styles by default -- never select neo-brutalism, terminal/hacker, retro-CRT, or vaporwave unless the user explicitly requests it. Default to styles that could ship in production.
  • Simplicity is valid -- if the user asks for simple/clean/minimal, deliver exactly that. Clean typography, generous whitespace, conventional layout. No decorative elements, no effects.
  • Responsive required -- every variant must work on mobile. Use prefers-reduced-motion and touch-friendly interactions.
  • Cross-browser safe -- avoid bleeding-edge CSS that breaks in Safari or Firefox.
  • Mock data only -- use realistic mock data covering edge cases. Do NOT wire up real API calls or state management during exploration. That happens in Phase 3.
Variant Presentation

For each variant, provide:

  1. Name -- short and evocative (e.g., "Ember", "Signal", "Nocturne")
  2. Description -- 2-3 sentences on the aesthetic direction and why it fits
  3. Key choices -- fonts, accent color, layout approach, motion style
  4. Signature -- the one element this variant is remembered by
  5. What changed -- if the variant introduces new data, repurposes assets, restructures information, or deprioritizes existing data, state it explicitly
  6. Full implementation -- working code with mock data

Implement a simple switching mechanism so the user can cycle through variants in the browser (e.g., a small floating selector, query param, or keyboard shortcut). The user must be able to compare all variants side by side or toggle between them without touching code.

If All Variants Are Rejected
  1. Ask what went wrong -- style direction, layout, quality, or everything.
  2. Ask for a reference -- website, app, Dribbble shot, screenshot.
  3. Offer 1-2 targeted variants based on feedback, not another blind batch.
  4. If "just make it simple" -- drop exploration. One clean, conservative design.
Show full SKILL.md (782 more words)Show less

Phase 3: Implementation

Once the user picks a variant:

  1. Delete all other variants -- clean up completely:
    • Search for remaining variant references, conditionals, and selection logic
    • Check for orphaned files, unused imports, unused CSS classes
    • Run the build to verify no broken imports
    • The codebase should look like the selected variant was the only implementation
  2. Wire up real data -- replace all mock data with real API calls, state management, and logic.
  3. Preserve all existing functionality -- every import, handler, and logic piece from the original must survive. Only visual styling changes.
  4. Read before writing -- always read current file content before overwriting. Never work from memory.
  5. Verify animations -- use GPU-accelerated properties (transform, opacity) instead of layout-triggering ones (top, left, width, height). Use ease-out for entrances, ease-in-out for state changes. If an animation looks janky, simplify it.
  6. Test responsive -- verify at mobile, tablet, and desktop breakpoints.
  7. Verify no regressions -- run build/lint if available. Check all imports resolve.

Aesthetic Standards

These apply to every variant in every mode.

Ground it in the subject -- before styling, name the concrete subject, its audience, and the one job the screen does. The subject's own world -- its materials, instruments, artifacts, and vernacular -- is where distinctive choices come from. A variant rooted in the subject beats one chasing a generic "nice" look.

Hero is a thesis -- for pages and sections, open with the most characteristic thing in the subject's world, in whatever form fits: a headline, an image, an animation, a live demo. A big number with a small label, supporting stats, and a gradient accent is the template answer -- use it only when it is genuinely the strongest option.

Spend boldness in one place -- give each variant a single signature element it will be remembered by, then keep everything around it quiet and disciplined. Cut decoration that does not serve the brief. Restraint is itself a valid risk; not every variant needs atmosphere stacked on atmosphere.

Typography -- pair a distinctive display font with a refined body font (Mode A) or vary weight, size, and hierarchy within the app's fonts (Mode B). Make the type treatment a memorable part of the design, not a neutral delivery vehicle. Never default to system fonts or overused families.

Color -- commit to a dominant color with sharp accents. Timid, evenly-distributed palettes look undesigned. Use CSS variables for consistency.

Structure is information -- numbering, eyebrows, dividers, and labels must encode something true about the content, not decorate it. Numbered markers (01 / 02 / 03) belong only where the content is an actual sequence. Question each structural device before adding it.

Motion -- one well-orchestrated entrance sequence (staggered reveals, animation-delay) lands harder than scattered micro-interactions. But less is often more: excess animation reads as AI-generated. Prioritize page-load and scroll-triggered moments over hover effects, and animate only where it serves the subject.

Spatial composition -- vary layouts meaningfully: asymmetry, overlap, diagonal flow, grid-breaking elements, controlled density, or generous negative space. Avoid defaulting to centered card grids.

Background and depth -- reach for atmosphere (gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows) when it serves the direction, not by reflex. A disciplined solid background with precise spacing is a legitimate choice, not a failure.

Writing is design material -- copy can make a design feel as templated as the visuals. Write from the user's side of the screen, name things by what people control, use active voice, and keep an action's label consistent through the whole flow. Treat errors and empty states as direction, not mood.

Anti-convergence -- never converge on the same font, color scheme, or layout pattern across variants or across sessions; each generation should feel curated by a different creative director. Steer around the contemporary AI defaults that appear regardless of subject: (1) cream background (~#F4F1EA) with a high-contrast serif and terracotta accent; (2) near-black with a single acid-green or vermilion accent; (3) broadsheet layout with hairline rules, zero radius, and dense columns. Each is legitimate as a deliberate choice for the right brief, never the place you land on autopilot.

Critical Constraints

  • All data must be accounted for -- every value and metric from the original must appear in every variant. Display format may change (text to chart, number to progress bar), but nothing is silently dropped. If a variant deliberately omits or deprioritizes a data point, it MUST be called out in the variant description.
  • No placeholder content -- mock data during variants, real data in final implementation.
  • File completeness -- write the ENTIRE file. No "rest remains the same" comments.
  • Font imports -- update layout/entry file imports when changing fonts (next/font/google, @font-face, etc.).
  • Design tokens -- update CSS variables/theme tokens to match the chosen variant. Do not hardcode colors inline when the app uses a token system.

© carson2222, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in design-exploration of carson2222/skills.

Open the folder on GitHubat commit c29af03

Compare with similar skills

Design Exploration next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Design Exploration compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Design Exploration this skillcarson2222/skills113—~3.3kAutomated safety check: PassApache-2.0
UI/UX Design System AdvisorGalaxy-Dawn/claude-scholar5.7k1 repos~1.1kAutomated safety check: PassMIT
UI Designmblode/agent-skills144—~6.3kAutomated safety check: PassMIT
UI StylingOhh-889/skyroc79513 repos~2.5kAutomated safety check: PassMIT
Creative Tim UI Blockscreativetimofficial/ui12k—~2.1kAutomated safety check: NotesMIT
DaisyUI Component Librarysaadeghi/daisyui43k—~1.3kAutomated safety check: PassMIT

Similar skills

  • UI/UX Design System Advisor

    Galaxy-Dawn/claude-scholar

    Turns a vague UI request into a concrete design system with style, palette, typography and layout guidance from a search script, plus stack-specific implementation advice.

    5.7k GitHub starsUsed in 1 repo~1.1k tokens
    Frontend & DesignAuto-check passed

  • UI Design

    mblode/agent-skills

    Designs and builds React/Next/Tailwind UI, audits visual and interaction defects, and stress-tests components with worst-case data.

    144 GitHub stars~6.3k tokensUpdated today
    Frontend & DesignAuto-check passed

  • UI Styling

    Ohh-889/skyroc

    Create beautiful, accessible user interfaces with shadcn/ui components (built on Radix UI + Tailwind), Tailwind CSS utility-first styling, and canvas-based visual designs.

    795 GitHub starsUsed in 13 repos~2.5k tokens
    Frontend & DesignAuto-check passed

  • Creative Tim UI Blocks

    creativetimofficial/ui

    Helps install, generate and review Creative Tim UI blocks: shadcn/ui-based React and Tailwind sections that follow a restrained, production-minded design philosophy.

    12k GitHub stars~2.1k tokensUpdated 6 mo ago
    Frontend & DesignAuto-check: notes

  • DaisyUI Component Library

    saadeghi/daisyui

    Official daisyUI skill for Tailwind CSS projects, routing to install, usage, configuration, color and per-component guides before writing any HTML or JSX with its classes.

    43k GitHub stars~1.3k tokensUpdated today
    Frontend & DesignAuto-check passed

  • Ss Learn

    bitjaru/styleseed

    Capture a human-approved UI design lesson as a privacy-minimized local StyleSeed candidate, review it, and prepare an opt-in share package without transmitting project code, prompts, screenshots, or…

    974 GitHub stars~1.3k tokensUpdated today
    Frontend & DesignAuto-check passed

More from carson2222/skills

  • OpenCode History Browser

    carson2222/skills

    Read-only lookup of local OpenCode history, including sessions, messages, plans, prompt history and prior decisions, queried through sqlite3 only when earlier context would help.

    113 GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check passed

  • X Algorithm Post Writing

    carson2222/skills

    Writes and reviews X posts, threads and replies using what the open-sourced For You ranking system rewards, and explains why a post may have underperformed.

    113 GitHub stars~3.8k tokensUpdated 3 mo ago
    Auto-check passed

Works with

Categories

Questions about Design Exploration

What does Design Exploration do?

Generates several visual directions for a component or page, lets you compare them, then fully implements the one you pick. The skill builds a requested number of design variants (the default is 5), each taking a fundamentally different visual direction, presents them for comparison and then implements the winner. It decides on its own whether the project is new or existing: a new project has no design system, so the variants define one, while an existing app keeps every variant consistent with its patterns and tokens.

When should I use Design Exploration?

Design Exploration fits situations like: redesigning or restyling a component or page; comparing several visual directions before committing; bootstrapping a frontend that has no design system yet; exploring dashboard or landing page layouts.

How do I install Design Exploration in Claude Code?

Run `npx skills add carson2222/skills --skill design-exploration -a claude-code`. Or copy the skill folder (design-exploration in carson2222/skills) into .claude/skills/design-exploration in your project. Claude Code loads it when a task matches its description.

How do I install Design Exploration in Codex?

Run `npx skills add carson2222/skills --skill design-exploration -a codex`. Or copy the skill folder (design-exploration in carson2222/skills) into .agents/skills/design-exploration in your project. Codex loads it when a task matches its description.

Can I use Design Exploration in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add carson2222/skills --skill design-exploration -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/design-exploration, .gemini/skills/design-exploration, .github/skills/design-exploration and .opencode/skills/design-exploration in your project.

What does Design Exploration need to run?

SKILL.md names no scripts, command-line tools or credentials: Design Exploration is instructions for the agent only.

Does Design Exploration access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Design Exploration safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Design Exploration use?

Design Exploration is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Design Exploration use?

About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Design Exploration?

Skills that share tags, products or a category with Design Exploration: UI/UX Design System Advisor (Galaxy-Dawn/claude-scholar, 5.7k stars), UI Design (mblode/agent-skills, 144 stars), UI Styling (Ohh-889/skyroc, 795 stars) and Creative Tim UI Blocks (creativetimofficial/ui, 12k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Design Exploration?

carson2222 (a GitHub user) maintains it in carson2222/skills, which has 113 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on June 28, 2026.

Source: carson2222/skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.