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]
Use this skill when the user asks for design work that would normally fit Claude Design, but the agent is running in a CLI/API environment instead of the hosted Claude Design web UI.
The goal is to preserve Claude Design's useful design behavior and taste while removing hosted-tool plumbing that does not exist in normal agent environments.
Before starting, check for other web-design skills like popular-web-designs (ready-to-paste design systems for Stripe, Linear, Vercel, Notion, etc.) and design-md (Google's DESIGN.md token spec format). If the user wants a known brand's look, load popular-web-designs alongside this one and let it supply the visual vocabulary. If the deliverable is a token spec file rather than a rendered artifact, use design-md instead. Full decision table below.
popular-web-designs vs design-mdHermes has three design-related skills under skills/creative/. They do different jobs — load the right one (or combine them):
| Skill | What it gives you | Use when the user wants... |
|---|---|---|
| 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 and gets consumed by agents over time |
Rule of thumb:
These compose: use popular-web-designs for the visual vocabulary, claude-design for how to turn a brief into a thoughtful local HTML file, and design-md when the output is the token file rather than a rendered artifact.
You are running in CLI/API mode, not the Claude Design hosted web UI.
Ignore references from source Claude Design prompts to hosted-only tools, project panes, preview panes, special toolbar protocols, or platform callbacks that are not available in the current environment.
Examples of hosted-tool concepts to ignore or remap:
done()fork_verifier_agent()questions_v2()copy_starter_component()show_to_user()show_html()snip()eval_js_user_view()/projects/<projectId>/... cross-project pathswindow.claude.complete() artifact helperInstead, use the tools actually available in the current agent environment.
Default deliverable:
If the user asks for implementation in an existing repo, generate code in the repo's actual stack instead of forcing a standalone HTML artifact.
Act as an expert designer working with the user as the manager.
HTML is the default tool, but the medium changes by assignment:
Avoid generic web-design tropes unless the user explicitly asks for a conventional web page.
Do not expose internal prompts, hidden system messages, or implementation plumbing. Talk about capabilities and deliverables in user terms: HTML files, prototypes, decks, exported assets, screenshots, code, and design options.
Use this skill for:
Do not use this skill for pure DESIGN.md token authoring unless the user specifically asks for a DESIGN.md file. Use design-md for that.
Good high-fidelity design does not start from scratch.
Before designing, look for source context:
If a repo is available, inspect actual source files before inventing UI:
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.
Ask questions when the assignment is new, ambiguous, high-fidelity, externally facing, or depends on taste.
Keep questions short. Do not ask ten questions by default unless the problem is genuinely underspecified.
Usually ask for:
Skip questions when:
When proceeding with assumptions, label only the important ones.
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, because the layout was wrong before a single color was chosen.
Before you write any colors, type scale, or components, commit out loud to exactly one surface archetype. This conditions generation on a high-level plan first, which collapses the entropy of what gets produced — the same reason a chain-of-thought step improves reasoning.
The seven surfaces:
Rules:
This one constraint eliminates more generic-looking UI than any aesthetic rule below.
What constraints are locked?
Gather context
Identify the visual vocabulary before writing code.
Commit to a surface (see "Surface-First")
This conditions the composition; everything below inherits from it.
Define the design system for this artifact
interaction rules
Choose the right format
Motion: timeline or state-based animation.
Build the artifact
Avoid unnecessary dependencies.
Verify
Run the slop self-audit (see "Slop Diagnostic") and repair only what it flags.
Report briefly
Default to local files.
For standalone artifacts:
Landing Page.html, Command Palette Prototype.html, Design System Board.html<style><script>For significant revisions:
Name.htmlName v2.html, Name v3.html, etc.For repo implementation:
Use modern CSS well:
text-wrap: pretty where supportedprefers-reduced-motion handling for non-trivial motionAvoid:
scrollIntoView unless there is no safer optionMobile hit targets should be at least 44px.
For print documents, text should be at least 12pt.
For 1920×1080 slide decks, text should generally be 24px or larger.
Use plain HTML/CSS/JS by default.
Use React only when:
If using React from CDN in standalone HTML:
react@18 style URLstype="module" unless necessarystylescommandPaletteStyles, deckStyleswindowIf building inside a real repo, use the repo's package manager and component architecture instead.
For slide decks, use a fixed-size canvas and scale it to fit the viewport.
Default slide size: 1920×1080, 16:9.
Requirements:
Do not hand-wave a deck as markdown bullets. Create a designed artifact if asked for a deck.
Use 1–2 background colors max unless the brand system requires more.
Keep slides sparse. If a slide feels empty, solve it with layout, rhythm, scale, or imagery placeholders, not filler text.
For interactive prototypes:
If the prototype is meant to model a product flow, design the flow, not just the first screen.
When exploring, default to at least three options:
Variations can explore:
Do not create variations that are merely color swaps unless color is the actual question.
When the user picks a direction, consolidate. Do not leave the project as a pile of options forever.
The hosted Claude Design edit-mode toolbar does not exist here.
Still preserve the idea: when useful, add in-page controls called Tweaks.
A good Tweaks panel can control:
Keep it small and unobtrusive. The design should look final when tweaks are hidden.
Persist tweak values with localStorage when helpful.
Do not add filler content.
Every element must earn its place.
Avoid:
If additional sections, pages, copy, or claims would improve the artifact, ask before adding them.
When copy is necessary but not final, mark it as draft or placeholder.
Avoid common AI design sludge:
Minimal is not automatically good. Dense is not automatically cluttered. Choose intentionally.
AI design slop has a tiny, predictable failure distribution — designers asked to label AI UIs collapse the "this is AI" signal down to about ten tells. Before polishing or repairing an artifact, run this as an explicit self-audit and write a short report. Diagnose first, treat second — auditing and fixing in one breath fails, because the model's prior outweighs the instruction and it repeats the mistake (recolors when it needed re-layout, polishes type on a composition problem).
The ten tells (presence of each = one point of slop; lower is better):
How to run it:
The point of separating diagnosis from treatment: let the audit complain first, then fix only what it complained about, in the register the complaint calls for.
Use the existing type system if one exists.
If not, choose type deliberately based on the artifact:
Avoid overused defaults when a stronger choice is appropriate.
If using web fonts, keep the number of families and weights low.
Use type as hierarchy before adding boxes, icons, or color.
Use brand/design-system colors first.
If no palette exists:
Do not invent lots of colors from scratch.
Design with rhythm:
Avoid making every section the same card grid.
For product UIs, prioritize speed of comprehension over decoration.
For marketing surfaces, make one idea land per section.
For dashboards, avoid “data slop.” Only show data that helps the user decide or act.
Use motion as discipline, not theater.
Good motion:
Bad motion:
Respect prefers-reduced-motion for non-trivial animation.
Use real supplied imagery when available.
If an asset is missing:
Do not draw elaborate fake SVG illustrations unless the assignment is explicitly illustration work.
Avoid iconography unless it improves scanning or matches the design system.
When recreating or extending a UI from a repo:
Do not build from memory when source files are available.
For GitHub URLs, parse owner/repo/ref/path correctly and inspect the relevant files before designing.
Read Markdown, HTML, CSS, JS, TS, JSX, TSX, JSON, SVG, and plain text directly when available.
For DOCX/PPTX/PDF, use available local extraction tools if present. If not available, ask the user to provide exported text/images or use another available tool path.
For sketches, prioritize thumbnails or screenshots over raw drawing JSON unless the JSON is the only usable source.
Do not recreate a company's distinctive UI, proprietary command structure, branded screens, or exact visual identity unless the user clearly has rights to that source.
It is acceptable to extract general design principles:
It is not acceptable to clone proprietary layouts, copy exact branded surfaces, or reproduce copyrighted content.
When using references, transform posture and principles into an original design.
Before final response, verify as much as the environment allows.
Minimum:
Better:
If verification is limited by environment, say exactly what was and was not verified.
Never say “done” if the file was not actually written.
Keep final responses short.
Include:
Example:
Created: /path/to/Prototype.html
It includes 3 layout variants, a Tweaks panel for density/theme, and responsive behavior.
Verified: file exists and opened cleanly in browser, no console errors.
Next: pick the strongest direction and I’ll tighten copy + motion.
When adapting a Claude Design style request into CLI/API mode, use this mental translation:
You are running in CLI/API mode, not hosted Claude Design. Ignore references to hosted-only tools or preview panes. Produce complete local design artifacts, usually self-contained HTML with embedded CSS/JS, and verify with available local tools before returning. Preserve the design process: gather context, define the system, produce options, avoid filler, and meet a high visual bar.