Menu
Design one-off HTML artifacts (landing, deck, prototype).
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Gated Gmail skill scaffold for OpenClicky. Use when the user asks to list, search, read, summarize, or draft replies to Gmail messages through local Google OAuth.
Draft, rewrite, summarize, triage, and prepare replies or outreach emails. Use for Gmail/Outlook/Mail tasks, email thread summaries, outbound sequences, follow-ups, humanizing drafts, and Gmail sends that require upgraded send permission plus explicit approval.
Use OpenClicky's Composio-backed Google Workspace integration for Gmail read/search, Gmail drafts and approved sends, Calendar events, Drive, Docs, Sheets, unread mail, files in Google Drive, and day-planning tasks.
Drive native macOS apps and browser UI through OpenClicky's local computer-use MCP background lane, backed by Cua. Snapshot state, prefer AX element_index actions, use explicit pixel/foreground paths only when the current OpenClicky tool surface exposes them, and verify via re-snapshot. Use when the user asks you to operate, drive, automate, or perform a GUI task in a real macOS application on the host.
Use OpenClicky's local gog CLI as the primary Google Workspace route for Gmail read/search, optional Gmail send only when already connected and explicitly approved, Calendar, Drive, Docs, Sheets, Chat, Contacts, auth status, and account inspection. Prefer gog over browser automation for normal Google Workspace work.
Connect to Google Workspace through the local gogcli (`gog`) command for Gmail, Calendar, Drive, Docs, Sheets, Slides, Chat, Contacts, Tasks, Groups, Admin, Classroom, Forms, Apps Script, People, and Keep. Use when the user asks OpenClicky to use Google Workspace, Gmail, Calendar, Drive, Docs, Sheets, Slides, Chat, Contacts, Tasks, Workspace Admin, or to set up/check gogcli auth.
| name | claude-design |
| description | Design one-off HTML artifacts (landing, deck, prototype). |
| version | 1.0.0 |
| author | BadTechBandit |
| license | MIT |
| metadata | {"openclicky":{"tags":["design","html","prototype","ux","ui","creative","artifact","deck","motion","design-system"],"related_skills":["design-md","popular-web-designs","excalidraw","architecture-diagram"]}} |
../_shared/OpenClickySkillCompatibilityPolicy.md before acting.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-mdOpenClicky 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.
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.