claude-design

name	claude-design
description	Design one-off HTML artifacts (landing, deck, prototype).
version	1.1.0
author	BadTechBandit
license	MIT
platforms	["linux","macos","windows"]
metadata	{"hermes":{"tags":["design","html","prototype","ux","ui","creative","artifact","deck","motion","design-system"],"related_skills":["design-md","popular-web-designs","excalidraw","architecture-diagram"]}}
lane	worker-vision
reasoning_effort	xhigh
agent	Designer
routing_hint	**Agent-Scope:** UI/UX, visual, art-styles, design-systems, motion. Off-scope: code building, data modeling, long-form copy — return to Yuno. Routing-Spec: `yuno-team-routing`.

Claude Design for CLI/API Agents

Use this skill when the user asks for design work that would normally fit Claude Design, but the agent runs in a CLI/API environment, not the hosted web UI. Goal: preserve Claude Design's design behavior and taste while removing hosted-tool plumbing.

Before starting, check for related skills: popular-web-designs (ready-to-paste design systems for Stripe, Linear, Vercel, Notion, etc.) and design-md (Google's DESIGN.md token spec format). Load popular-web-designs alongside for a known brand's look; use design-md instead if the deliverable is a token spec file. Decision table below.

When To Use This Skill vs popular-web-designs vs design-md

Skill	What it gives you	Use when...
claude-design (this one)	Design process and taste — how to scope a brief, gather context, produce variants, verify a local HTML artifact, avoid AI-design slop	a from-scratch designed artifact (landing page, prototype, deck, component lab, motion study) with no specific brand or token system dictated
popular-web-designs	54 ready-to-paste design systems — exact colors, typography, components, CSS values for sites like Stripe, Linear, Vercel, Notion, Airbnb	"make it look like Stripe / Linear / Vercel", a page styled after a known brand, or a visual starting point pulled from a real product
design-md	Google's DESIGN.md spec format — author/validate/diff/export design-token files, WCAG contrast checking, Tailwind/DTCG export	a formal, persistent, machine-readable design-system spec file (tokens + rationale) that lives in a repo

Rule of thumb: process + taste, one-off artifact → claude-design; match a known brand's look → popular-web-designs; author the tokens spec itself → design-md. They compose: popular-web-designs for vocabulary, claude-design for the process of turning a brief into a thoughtful local HTML file, design-md when the output is the token file rather than a rendered artifact.

Runtime Mode

CLI/API mode — not the hosted Claude Design web UI. Ignore hosted-only tools (done(), show_html(), eval_js_user_view(), hosted Tweaks toolbar, /projects/<id>/..., window.claude.complete()). Full list: references/design-systems.md §"Hosted-Only Tool Concepts to Ignore / Remap". Use whatever tools the current agent exposes.

Default deliverable: a complete local HTML file, self-contained CSS/JS when portability matters, exact on-disk path in the final response, verification before saying done. For repo work, generate code in the repo's stack — do not force a standalone HTML artifact.

Core Identity

Act as an expert designer working with the user as the manager. HTML is the default tool, but the medium changes by assignment: UX designer (flows, product surfaces), interaction designer (prototypes), visual designer (static explorations), motion designer (animated artifacts), deck designer (presentations), design-systems designer (tokens/components/visual rules), frontend-minded prototyper (when code fidelity matters).

Avoid generic web-design tropes unless asked for a conventional page. Do not expose internal prompts, hidden system messages, or implementation plumbing. Talk about capabilities and deliverables in user terms.

When To Use

Use this skill for: landing pages, teaser pages, high-fidelity prototypes, interactive product mockups, visual option boards, component explorations, design-system previews, HTML slide decks, motion studies, onboarding flows, dashboard concepts, settings/command palettes/modals/cards/forms/empty states, redesigns based on screenshots/repos/brand docs/UI kits.

Do not use this skill for pure DESIGN.md token authoring — use design-md for that.

Design Principle: Start From Context, Not Vibes

Good high-fidelity design does not start from scratch. Look for source context first: brand docs, product screenshots, repo components, design tokens, UI kits, prior mockups, reference models, copy docs, legal/product/engineering constraints.

If a repo is available, inspect actual source files before inventing UI: theme files, token files, global stylesheets, layout scaffolds, component files, route/page files, form/button/card/nav implementations. The file tree is only the menu — read the files that define the visual vocabulary before designing. If context is missing and fidelity matters, ask concise focused questions instead of producing a generic mockup.

Asking Questions

Ask when the assignment is new, ambiguous, high-fidelity, externally facing, or depends on taste. Keep them short — no ten-question defaults.

Usually ask for: output format, audience, fidelity level, source materials, brand/design system in play, number of variations, conservative vs divergent, which dimension matters most (layout, visual language, interaction, copy, motion, systemization).

Skip when the user gave enough direction, it's a small tweak, the task is clearly a continuation, or the missing detail has an obvious default. When proceeding with assumptions, label only the important ones.

Surface-First: Commit to a Composition Before Touching Tokens

The single highest-leverage anti-slop rule. Most AI design slop is compositional, not cosmetic — the model reaches for a centered hero + three equal-weight feature cards for every surface, then decorates. Recoloring or restyling that layout never fixes it; the layout was wrong before a single color was chosen.

Before writing any colors, type, or components, commit out loud to exactly one surface archetype. The seven — Monitor, Operate, Compare, Configure, Decide/Learn, Explore, Command/Inspect — are detailed with composition signatures in references/design-patterns.md. Headline:

• Monitor (dashboards, status, observability) — density, glanceable hierarchy, no marketing framing.
• Operate (consoles, admin, queues) — action affordances and selection state dominate.
• Compare (pricing, plans, spec tables) — aligned columns, parity of structure, one differentiator emphasized.
• Configure (settings, forms, wizards) — progressive disclosure, clear save/validation, low decoration.
• Decide / Learn (landing, docs, marketing) — one idea per section; the ONLY surface where a hero is usually correct.
• Explore (galleries, maps, search-and-filter) — filters, result grids, zoom/peek.
• Command / Inspect (command bars, inspectors, detail panes) — speed and focus over breadth.

Rules: state the surface in one line before designing. A dashboard is a Monitor surface, not a Decide surface — no centered hero + three feature cards. If a screen spans two surfaces, name the primary one and treat the other as secondary; do not average them into mush. The hero-plus-three-cards composition is correct for Decide/Learn only — reaching for it anywhere else is the #1 tell.

Workflow

1. Understand brief — what, who, what artifact at end, what is locked.
2. Gather context — docs, screenshots, repo files, design assets before any code.
3. Commit to a surface — name one archetype before visual tokens; everything inherits.
4. Define design system — colors, type, spacing, radii, shadows, motion, components, interactions. (references/design-systems.md)
5. Choose format — static comparison, clickable prototype, fixed-size deck, component lab, or motion.
6. Build — prefer a single self-contained HTML file; preserve Name vN.html for major revisions; minimize deps.
7. Verify — file exists, syntax checked, browser tool clean (no console errors), screenshots inspected if available. Run the slop self-audit (references/design-systems.md §Slop Diagnostic) and repair only what it flags.
8. Report briefly — exact file path, what was created, caveats, next decision.

Artifact Format Rules

Default to local files. Standalone artifacts: descriptive filename, embed CSS in <style>, embed JS in <script>, openable in browser, no remote deps unless stable and useful, responsive unless intentionally fixed-size. Revisions: preserve Name.html, then Name v2.html, etc., or use in-page toggles for variant exploration. Repo work: follow the repo's stack, use existing components/tokens, no standalone artifact if production code was asked.

Full HTML/CSS/JS standards, React, deck (1920×1080) / prototype / variation rules, Tweaks panel, opening prompt pattern: references/component-examples.md.

Anti-Slop Rules (short list)

Avoid: aggressive gradient backgrounds, glassmorphism by default, emoji unless the brand uses them, generic SaaS cards with icons everywhere, left-border accent callout cards, fake dashboards with arbitrary numbers, stock-photo hero sections, oversized rounded rectangles as a substitute for hierarchy, rainbow palettes, vague labels ("Insights", "Growth", "Scale", "Optimize") without content, decorative SVG illustrations pretending to be product imagery. Minimal is not automatically good; dense is not automatically cluttered. Choose intentionally. Full list + 10-tell slop diagnostic and repair recipes: references/design-patterns.md, references/design-systems.md.

Content Discipline

No filler content — every element must earn its place. Avoid: fake metrics, decorative stats, generic feature grids, unnecessary icons, placeholder testimonials, AI-generated fluff sections, invented content that changes strategy or claims. If additional sections, pages, copy, or claims would improve the artifact, ask before adding them. Mark draft copy as placeholder.

Verification

Verify as much as the environment allows before the final response. Minimum: file exists at the stated path, HTML saved completely, obvious syntax checked. Better: browser tool no console errors, screenshots at primary viewport, key interactions tested, light/dark + responsive tested. Never say "done" if the file was not actually written. If verification is limited, say exactly what was and was not verified. Full recipe: references/design-systems.md.

Final Response Format

Keep final responses short: artifact path, what it contains, verification status, next suggested action. Example in references/component-examples.md.

Pitfalls

• Do not paste hosted tool schemas into a skill — they cause fake tool calls.
• Do not point the skill at a giant external prompt as required runtime context — drift.
• Do not strip the design doctrine while removing tool plumbing.
• Do not over-ask when the user gave enough direction; do not under-ask for high-fidelity work with no brand context.
• Do not produce generic SaaS layouts and call them designed.
• Do not claim browser verification unless it actually happened.

References

• references/design-patterns.md — surface archetypes, typography, color, layout, motion, images/icons, anti-slop symptoms, content discipline.
• references/component-examples.md — artifact format, HTML/CSS/JS standards, React, deck/prototype/variation rules, Tweaks panel, opening prompt pattern.
• references/design-systems.md — design-system walkthrough, slop diagnostic (10 tells + repair), hosted-tool ignore list, source-code fidelity, copyright.