Menu
Design one-off HTML artifacts (landing, deck, prototype)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Edits any writing so it sounds specific, human, and not AI-polished. Use when the user asks to remove AI writing tells, make text less generic/SaaS-y/corporate/LinkedIn, preserve personal voice, rewrite copy, review wording, or make writing more dry, direct, warm, blunt, or natural.
Reviews recent Pi conversation/session logs to find repeated friction, ambiguity loops, expensive reasoning, user corrections, and missing skills, MCP servers, scripts, or workflow guardrails. Use for daily or weekly retrospectives, "review our conversations", "what skills are missing", "tighten the loop", "thinking token spend", or "make the harness smarter".
Manage Google Workspace via the gws CLI — Drive, Gmail, Sheets, Docs, Slides, People, Chat, Meet, Forms, and cross-service workflows. Use when asked to send email, read/write spreadsheets, upload files to Drive, manage contacts, create presentations, send Chat messages, create docs, or any Google Workspace operation. Also triggers on "gws", "Google Drive", "Google Sheets", "Gmail", "Google Docs", "Google Slides", "Google Chat", "Google Meet", "Google Forms", "check my inbox", "upload to Drive", "read spreadsheet", "send an email", "create a doc", "send a chat message", "create a presentation".
Embody this digital identity. Read SOUL.md first, then STYLE.md, then examples/. Become the person—opinions, voice, worldview.
Design engineering principles for making interfaces feel polished. Use when building UI components, reviewing frontend code, implementing animations, hover states, shadows, borders, typography, micro-interactions, enter/exit animations, or any visual detail work. Triggers on UI polish, design details, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers, image outlines, box shadows.
Orchestrate cmux terminal panes — split terminals, run parallel processes, read output from other panes, and use the built-in browser. Use when working inside cmux and you need to run a dev server, watch tests, spawn sub-agents, or preview web pages.
| name | design-one-off-html |
| description | Design one-off HTML artifacts (landing, deck, prototype) |
| version | 1.0.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 pathsInstead, 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.
Understand the brief
Gather context
Define the design system for this artifact
Choose the right format
Build the artifact
Verify
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.
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.