메뉴
Design one-off HTML artifacts (landing, deck, prototype).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | claude-design |
| 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 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.
When the user gives you a long-form tutorial (markdown / doc / lecture notes) and asks you to "make it a website", "make it interactive", "make it suitable for beginners", or similar — this is an educational artifact, not a marketing surface. The deliverable is a self-contained SPA (single-page app, vanilla JS or React) that turns reading into doing.
This variant has its own reference: references/teaching-site.md — read it before starting. It lists the architecture pattern, the seven component archetypes, the JS pitfalls that bite everyone the first time, and the verification checklist.
For a known-good starter scaffold you can copy and modify, see templates/teaching-site/ (index.html / styles.css / js/app.js — drop in your data/glossary.js, data/content.js, and js/components.js).
| Marketing artifact | Educational artifact |
|---|---|
| One-screen hero + scroll narrative | Sidebar TOC + 21+ section scroll body |
| Decorative imagery | Code blocks with syntax highlighting |
| "Sign up" CTA | "Mark complete" progress + glossary tooltips |
| One-time persuasion | Re-visitable, searchable, resumable across sessions |
| Brand visual identity | Domain visual identity (e.g. Emacs purple, Vim green) |
| Mobile-first marketing responsiveness | Reading-first density + responsive collapse to mobile |
The general anti-slop list still applies, plus:
<kbd> chips — this is what beginners actually need.A teaching site worth shipping has all of:
If the user only wants a "single-page pretty version of the markdown", clarify scope before delivering — that is a much smaller artifact.
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.
Diagnose and fix the dual-channel memory problem in Hermes Agent — when `memory.provider: holographic` (or any external provider) is configured but the agent keeps writing only to `memories/MEMORY.md`, bypassing it. Covers why agents default to the markdown file, the four root causes of routing failure, and three remediation options (SOUL.md rules / disable MEMORY.md / mirror via code). Triggers on 'memory 不生效', 'holographic 没在用', 'agent 都写到 MEMORY.md', '双 memory 系统', 'memory tool vs fact_store', 'on_memory_write', 'memory drift', 'Mirrors 不到', or any 'why is my agent ignoring the configured memory provider' question.
Use when the user works inside ~/Projects/Config/Guix-configs and mentions '改 dotfiles', 'blue home', 'guix system reconfigure', 'shepherd service', 'stow 死链', 'blue stow', 'AGENTS.md 翻新', 'fcitx', 'IME 没输入法', 'Electron 没输入法', 'wireplumber', '二轨 dotfiles', '恢复被删除的 dotfiles', or related. Ten sub-protocols — dotfiles deploy verification, worker delegation, multi-line edit safety, Guix service debugging, GNU Stow mutable config, restoring deleted dotfiles, ISO 移植, 需求澄清, 模块归属陷阱.
跨 agent KB 健康度维护。**触发信号**：每周/长会话后例行维护 / 卡片 >50 张 / 检索质量明显下降 / 用户触发 `/agenote-curate` / 发现重复卡片或矛盾结论 / 新增了对话抽取源。**当上述任一信号出现时立即调用本 skill** 做健康检查+去重+归档+权重重分配+reconcile 多源 memory。基础用法见 `agenote-base`；会话中单次经验记录见 `agenote-review`。
Maintain the personal Guix channel at ~/Projects/Config/jeans (Just Enough AI-geNerated Slops). Use when the user asks to "fix the CI build failure issue", "升级 X 包", "add a package", "check upstream updates", "跑 maak upgrade", "修复 auto-update 流水线的 issue
How to author a Hermes Agent skill the right way. Covers the two non-negotiable structural principles every skill must follow — **self-contained** (all runnable artifacts ship inside the skill directory so backup = usable) and **progressive disclosure** (SKILL.md is a thin router; details live under `references/`, `templates/`, `scripts/`) — the directory layout, file-type rules, decision trees for what goes in SKILL.md vs. a support file, **which of the 12 existing categories a new skill belongs to (never top-level `<skill-name>/`)**, and a checklist before declaring a skill done. Trigger when: writing a new skill, refactoring an existing skill's structure, wondering 'should this go in SKILL.md or references()' / 'which category directory should this skill live into', preparing a skill for backup/share, noticing a self-contained violation, or auditing existing skills. Also trigger when the user complains something is 'too verbose' or 'in the wrong place' — those are progressive-disclosure violations.
When the user says '校对文档 / 检查文档是否还有效 / sync doc with code / 扩写 README / 改写文档 / 把这个 PLAN/plan/任务书做成文档 / 文档并入主文档', or when a `refs/*.md` document may be drifting from the tool/CLI/源码 it describes, or when a PLAN file needs to become a user-facing reference doc. Covers three entry points — check, rewrite, plan-to-doc — backed by a `scripts/doc-check.py` checker that catches silent drift between a doc and its source-of-truth (CLI flags, MCP tool names, file paths). Trigger when the user names a doc path and asks whether it's still accurate, when adding a new CLI/MCP/API surface that old docs don't mention, or when a PLAN/任务书/thread needs to graduate into a stable reference.