[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GA1HSZPMAAS5BCASDV1SX4":3,"skill-same:01M6GA1HSZPMAAS5BCASDV1SX4":91},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":69,"commitSha":70,"skillDirectory":71,"forksCount":72,"repositoryHtmlUrl":73,"repositoryHomepageUrl":6,"ownerHtmlUrl":74,"ownerBlogUrl":6,"ownerDescription":75,"updatedAt":76,"install":77,"resources":90},"01M6GA1HSZPMAAS5BCASDV1SX4","claude-design",null,"Design one-off HTML artifacts (landing, deck, prototype).","zapabob\u002FSkills","zapabob","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130830376?v=4","01M6DBMYZAGRTFQDSQYW3W764P","峯岸 亮","01M6DBMZ3GKDSJ01NZ9XTZD7JD",2,"MIT","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F82\u002F82b1036c4edbf744606e54bfddc214d5b2c4ca7cc253de1605fcbf8c42984ac6\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"claude design","design","excalidraw","design-md","artifact","motion","deck","html","design-system","landing","system","ui","ux","artifacts","diagram","windows","architecture","prototype","linux","macos","2026-11-10 10:12:30",false,"---\nname: claude-design\ndescription: Design one-off HTML artifacts (landing, deck, prototype).\nversion: 1.1.0\nauthor: BadTechBandit\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [design, html, prototype, ux, ui, creative, artifact, deck, motion, design-system]\n    related_skills: [design-md, excalidraw, architecture-diagram]\n---\n\n# Claude Design for CLI\u002FAPI Agents\n\nUse this skill when the user asks for design work that would normally fit Claude Design, but the agent is running in a CLI\u002FAPI environment instead of the hosted Claude Design web UI.\n\nThe 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.\n\n**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.\n\n## When To Use This Skill vs `popular-web-designs` vs `design-md`\n\nHermes has three design-related skills under `skills\u002Fcreative\u002F`. They do different jobs — load the right one (or combine them):\n\n| Skill | What it gives you | Use when the user wants... |\n|---|---|---|\n| **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 |\n| **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 \u002F Linear \u002F Vercel\", a page styled after a known brand, or a visual starting point pulled from a real product |\n| **design-md** | Google's DESIGN.md spec format — author\u002Fvalidate\u002Fdiff\u002Fexport design-token files, WCAG contrast checking, Tailwind\u002FDTCG export | a formal, persistent, machine-readable design-system *spec file* (tokens + rationale) that lives in a repo and gets consumed by agents over time |\n\nRule of thumb:\n\n- **Process + taste, one-off artifact** → claude-design\n- **Match a known brand's look** → popular-web-designs (and let claude-design drive the process)\n- **Author the tokens spec itself** → design-md\n\nThese 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.\n\n## Runtime Mode\n\nYou are running in **CLI\u002FAPI mode**, not the Claude Design hosted web UI.\n\nIgnore 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.\n\nExamples of hosted-tool concepts to ignore or remap:\n\n- `done()`\n- `fork_verifier_agent()`\n- `questions_v2()`\n- `copy_starter_component()`\n- `show_to_user()`\n- `show_html()`\n- `snip()`\n- `eval_js_user_view()`\n- hosted asset review panes\n- hosted edit-mode or Tweaks toolbar messaging\n- `\u002Fprojects\u002F\u003CprojectId>\u002F...` cross-project paths\n- built-in `window.claude.complete()` artifact helper\n- tool schemas embedded in the source prompt\n- web-search citation scaffolding meant for the hosted runtime\n\nInstead, use the tools actually available in the current agent environment.\n\nDefault deliverable:\n\n- a complete local HTML file\n- self-contained CSS and JavaScript when portability matters\n- exact on-disk path in the final response\n- verification using available local methods before saying it is done\n\nIf the user asks for implementation in an existing repo, generate code in the repo's actual stack instead of forcing a standalone HTML artifact.\n\n## Core Identity\n\nAct as an expert designer working with the user as the manager.\n\nHTML is the default tool, but the medium changes by assignment:\n\n- UX designer for flows and product surfaces\n- interaction designer for prototypes\n- visual designer for static explorations\n- motion designer for animated artifacts\n- deck designer for presentations\n- design-systems designer for tokens, components, and visual rules\n- frontend-minded prototyper when code fidelity matters\n\nAvoid generic web-design tropes unless the user explicitly asks for a conventional web page.\n\nDo 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.\n\n## When To Use\n\nUse this skill for:\n\n- landing pages\n- teaser pages\n- high-fidelity prototypes\n- interactive product mockups\n- visual option boards\n- component explorations\n- design-system previews\n- HTML slide decks\n- motion studies\n- onboarding flows\n- dashboard concepts\n- settings, command palettes, modals, cards, forms, empty states\n- redesigns based on screenshots, repos, brand docs, or UI kits\n\nDo 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.\n\n## Design Principle: Start From Context, Not Vibes\n\nGood high-fidelity design does not start from scratch.\n\nBefore designing, look for source context:\n\n1. brand docs\n2. existing product screenshots\n3. current repo components\n4. design tokens\n5. UI kits\n6. prior mockups\n7. reference models\n8. copy docs\n9. constraints from legal, product, or engineering\n\nIf a repo is available, inspect actual source files before inventing UI:\n\n- theme files\n- token files\n- global stylesheets\n- layout scaffolds\n- component files\n- route\u002Fpage files\n- form\u002Fbutton\u002Fcard\u002Fnavigation implementations\n\nThe file tree is only the menu. Read the files that define the visual vocabulary before designing.\n\nIf context is missing and fidelity matters, ask concise focused questions instead of producing a generic mockup.\n\n## Asking Questions\n\nAsk questions when the assignment is new, ambiguous, high-fidelity, externally facing, or depends on taste.\n\nKeep questions short. Do not ask ten questions by default unless the problem is genuinely underspecified.\n\nUsually ask for:\n\n- intended output format\n- audience\n- fidelity level\n- source materials available\n- brand\u002Fdesign system in play\n- number of variations wanted\n- whether to stay conservative or explore divergent ideas\n- which dimension matters most: layout, visual language, interaction, copy, motion, or systemization\n\nSkip questions when:\n\n- the user gave enough direction\n- this is a small tweak\n- the task is clearly a continuation\n- the missing detail has an obvious default\n\nWhen proceeding with assumptions, label only the important ones.\n\n## Surface-First: Commit to a Composition Before Touching Tokens\n\nThe 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.\n\nBefore 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.\n\nThe seven surfaces:\n\n1. **Monitor** — the user is watching state change (dashboards, status pages, observability). Density, glanceable hierarchy, no marketing framing.\n2. **Operate** — the user is taking action on things (consoles, admin panels, queues, inboxes). Action affordances and selection state dominate.\n3. **Compare** — the user is weighing options against each other (pricing, plans, spec tables, search results). Aligned columns, parity of structure, one differentiator emphasized.\n4. **Configure** — the user is setting things up (settings, forms, wizards, onboarding). Progressive disclosure, clear save\u002Fvalidation states, low decoration.\n5. **Decide \u002F Learn** — the user is being convinced or taught (landing pages, docs, marketing). One idea lands per section; this is the ONLY surface where a hero is usually correct.\n6. **Explore** — the user is browsing an open space (galleries, maps, search-and-filter, catalogs). Filters, result grids, and zoom\u002Fpeek are the composition.\n7. **Command \u002F Inspect** — the user is driving by keyboard or drilling into one object (command bars, inspectors, detail panes, property editors). Speed and focus over breadth.\n\nRules:\n\n- State the surface in one line before designing (e.g. \"This is a **Monitor** surface, so density and glanceability beat a hero\").\n- A dashboard is a Monitor surface, not a Decide surface — do not give it a centered hero and three feature cards.\n- If a screen genuinely spans two surfaces, name the **primary** one and treat the other as secondary; do not average them into mush.\n- The hero-plus-three-cards composition is correct for **Decide\u002FLearn only**. Reaching for it anywhere else is the #1 tell.\n\nThis one constraint eliminates more generic-looking UI than any aesthetic rule below.\n\n## Workflow\n\n1. **Understand the brief**\n   - What is being designed?\n   - Who is it for?\n   - What artifact should exist at the end?\n   - What constraints are locked?\n\n2. **Gather context**\n   - Read supplied docs, screenshots, repo files, or design assets.\n   - Identify the visual vocabulary before writing code.\n\n3. **Commit to a surface** (see \"Surface-First\")\n   - Name the one surface archetype before any visual tokens.\n   - This conditions the composition; everything below inherits from it.\n\n4. **Define the design system for this artifact**\n   - colors\n   - type\n   - spacing\n   - radii\n   - shadows or elevation\n   - motion posture\n   - component treatment\n   - interaction rules\n\n5. **Choose the right format**\n   - Static visual comparison: one HTML canvas with options side by side.\n   - Interaction\u002Fflow: clickable prototype.\n   - Presentation: fixed-size HTML deck with slide navigation.\n   - Component exploration: component lab with variants.\n   - Motion: timeline or state-based animation.\n\n6. **Build the artifact**\n   - Prefer a single self-contained HTML file unless the task calls for a repo implementation.\n   - Preserve prior versions for major revisions.\n   - Avoid unnecessary dependencies.\n\n7. **Verify**\n   - Confirm files exist.\n   - Run any available syntax\u002Fstatic checks.\n   - If browser tools are available, open the file and check console errors.\n   - If visual fidelity matters and screenshot tools are available, inspect at least the primary viewport.\n   - Run the slop self-audit (see \"Slop Diagnostic\") and repair only what it flags.\n\n8. **Report briefly**\n   - exact file path\n   - what was created\n   - caveats\n   - next decision or next iteration\n\n## Artifact Format Rules\n\nDefault to local files.\n\nFor standalone artifacts:\n\n- create a descriptive filename, e.g. `Landing Page.html`, `Command Palette Prototype.html`, `Design System Board.html`\n- embed CSS in `\u003Cstyle>`\n- embed JS in `\u003Cscript>`\n- keep the artifact openable directly in a browser\n- avoid remote dependencies unless they are explicitly useful and stable\n- include responsive behavior unless the format is intentionally fixed-size\n\nFor significant revisions:\n\n- preserve the previous version as `Name.html`\n- create `Name v2.html`, `Name v3.html`, etc.\n- or keep one file with in-page toggles if the assignment is variant exploration\n\nFor repo implementation:\n\n- follow the repo's actual stack\n- use existing components and tokens where possible\n- do not create a standalone artifact if the user asked for production code\n\n## HTML \u002F CSS \u002F JS Standards\n\nUse modern CSS well:\n\n- CSS variables for tokens\n- CSS grid for layout\n- container queries when helpful\n- `text-wrap: pretty` where supported\n- real focus states\n- real hover states\n- `prefers-reduced-motion` handling for non-trivial motion\n- responsive scaling\n- semantic HTML where practical\n\nAvoid:\n\n- huge monolithic files when a real repo structure is expected\n- fragile hard-coded viewport assumptions\n- inaccessible tiny hit targets\n- decorative JS that fights usability\n- `scrollIntoView` unless there is no safer option\n\nMobile hit targets should be at least 44px.\n\nFor print documents, text should be at least 12pt.\n\nFor 1920×1080 slide decks, text should generally be 24px or larger.\n\n## React Guidance for Standalone HTML\n\nUse plain HTML\u002FCSS\u002FJS by default.\n\nUse React only when:\n\n- the artifact needs meaningful state\n- variants\u002Ftoggles are easier as components\n- interaction complexity warrants it\n- the target implementation is React\u002FNext.js and fidelity matters\n\nIf using React from CDN in standalone HTML:\n\n- pin exact versions\n- avoid unpinned `react@18` style URLs\n- avoid `type=\"module\"` unless necessary\n- avoid multiple global objects named `styles`\n- give global style objects specific names, e.g. `commandPaletteStyles`, `deckStyles`\n- if splitting Babel scripts, explicitly attach shared components to `window`\n\nIf building inside a real repo, use the repo's package manager and component architecture instead.\n\n## Deck Rules\n\nFor slide decks, use a fixed-size canvas and scale it to fit the viewport.\n\nDefault slide size: 1920×1080, 16:9.\n\nRequirements:\n\n- keyboard navigation\n- visible slide count\n- localStorage persistence for current slide\n- print-friendly layout when practical\n- screen labels or stable IDs for important slides\n- no speaker notes unless the user explicitly asks\n\nDo not hand-wave a deck as markdown bullets. Create a designed artifact if asked for a deck.\n\nUse 1–2 background colors max unless the brand system requires more.\n\nKeep slides sparse. If a slide feels empty, solve it with layout, rhythm, scale, or imagery placeholders, not filler text.\n\n## Prototype Rules\n\nFor interactive prototypes:\n\n- make the primary path clickable\n- include key states: default, hover\u002Ffocus, loading, empty, error, success where relevant\n- expose variations with in-page controls when useful\n- keep controls out of the final composition unless they are intentionally part of the prototype\n- persist important state in localStorage when refresh continuity matters\n\nIf the prototype is meant to model a product flow, design the flow, not just the first screen.\n\n## Variation Rules\n\nWhen exploring, default to at least three options:\n\n1. **Conservative** — closest to existing patterns \u002F lowest risk\n2. **Strong-fit** — best interpretation of the brief\n3. **Divergent** — more novel, useful for discovering taste boundaries\n\nVariations can explore:\n\n- layout\n- hierarchy\n- type scale\n- density\n- color posture\n- surface treatment\n- motion\n- interaction model\n- copy structure\n- component shape\n\nDo not create variations that are merely color swaps unless color is the actual question.\n\nWhen the user picks a direction, consolidate. Do not leave the project as a pile of options forever.\n\n## Tweakable Designs in CLI\u002FAPI Mode\n\nThe hosted Claude Design edit-mode toolbar does not exist here.\n\nStill preserve the idea: when useful, add in-page controls called `Tweaks`.\n\nA good `Tweaks` panel can control:\n\n- theme mode\n- layout variant\n- density\n- accent color\n- type scale\n- motion on\u002Foff\n- copy variant\n- component variant\n\nKeep it small and unobtrusive. The design should look final when tweaks are hidden.\n\nPersist tweak values with localStorage when helpful.\n\n## Content Discipline\n\nDo not add filler content.\n\nEvery element must earn its place.\n\nAvoid:\n\n- fake metrics\n- decorative stats\n- generic feature grids\n- unnecessary icons\n- placeholder testimonials\n- AI-generated fluff sections\n- invented content that changes strategy or claims\n\nIf additional sections, pages, copy, or claims would improve the artifact, ask before adding them.\n\nWhen copy is necessary but not final, mark it as draft or placeholder.\n\n## Anti-Slop Rules\n\nAvoid common AI design sludge:\n\n- aggressive gradient backgrounds\n- glassmorphism by default\n- emoji unless the brand uses them\n- generic SaaS cards with icons everywhere\n- left-border accent callout cards\n- fake dashboards filled with arbitrary numbers\n- stock-photo hero sections\n- oversized rounded rectangles as a substitute for hierarchy\n- rainbow palettes\n- vague labels like “Insights,” “Growth,” “Scale,” “Optimize” without content\n- decorative SVG illustrations pretending to be product imagery\n\nMinimal is not automatically good. Dense is not automatically cluttered. Choose intentionally.\n\n## Slop Diagnostic: Score Before You Fix\n\nAI 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).\n\nThe ten tells (presence of each = one point of slop; lower is better):\n\n1. **Tech gradient** — blue\u002Fviolet\u002Findigo glossy gradient on everything.\n2. **Generic tech hue** — the default accent is indigo\u002Fviolet (not chosen for the brand, just the model's favorite).\n3. **Feature-tile grid** — icon + heading + sentence × 3, all equal weight, nothing prioritized.\n4. **Accent rail** — a colored left strip on cards: decoration pretending to be organization.\n5. **Unearned blur** — glassmorphism with no real depth\u002Felevation system behind it.\n6. **Monument stat** — oversized numbers filling space that should carry product story.\n7. **Icon topper** — a rounded-square icon centered above every heading (Tailwind-template filler).\n8. **Center stack** — everything centered because no real composition was committed to.\n9. **Default type** — Inter (or system-ui) used by default rather than chosen.\n10. **Wrong surface** — the composition doesn't match the surface (e.g. a hero on a Monitor surface). This is the root cause behind most of the others.\n\nHow to run it:\n\n- Score the artifact out of 10 (10 = maximum slop). State the score and list which tells fired, in one short report.\n- Treat the report as **context, not a to-do list** — it tells you *where* to spend repair effort, it does not dictate edits.\n- Then repair, matched to the diagnosis:\n  - tells 3, 8, 10 → **re-layout \u002F re-compose** (revisit the surface choice — do not recolor).\n  - tells 1, 2, 9 → **recolor \u002F re-typeset** (palette and type are genuinely the problem here).\n  - tells 4, 5, 6, 7 → **remove the decoration**; replace it with real hierarchy (scale, weight, spacing).\n- Re-score after repairing. Do not declare done while compositional tells (3, 8, 10) are still firing — those are causes, the rest are usually symptoms.\n\nThe 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.\n\n## Typography\n\nUse the existing type system if one exists.\n\nIf not, choose type deliberately based on the artifact:\n\n- editorial: serif or humanist headline with restrained sans body\n- software\u002Fproductivity: precise sans with strong numeric treatment\n- luxury\u002Fminimal: fewer weights, more spacing discipline\n- technical: mono accents only, not mono everywhere\n- deck: large, clear, high contrast\n\nAvoid overused defaults when a stronger choice is appropriate.\n\nIf using web fonts, keep the number of families and weights low.\n\nUse type as hierarchy before adding boxes, icons, or color.\n\n## Color\n\nUse brand\u002Fdesign-system colors first.\n\nIf no palette exists:\n\n- define a small system\n- include neutrals, surface, ink, muted text, border, accent, danger\u002Fsuccess if needed\n- use one primary accent unless the assignment calls for a broader palette\n- prefer oklch for harmonious invented palettes when browser support is acceptable\n- check contrast for important text and controls\n\nDo not invent lots of colors from scratch.\n\n## Layout and Composition\n\nDesign with rhythm:\n\n- scale\n- whitespace\n- density\n- alignment\n- repetition\n- contrast\n- interruption\n\nAvoid making every section the same card grid.\n\nFor product UIs, prioritize speed of comprehension over decoration.\n\nFor marketing surfaces, make one idea land per section.\n\nFor dashboards, avoid “data slop.” Only show data that helps the user decide or act.\n\n## Motion\n\nUse motion as discipline, not theater.\n\nGood motion:\n\n- clarifies state changes\n- reduces anxiety during loading\n- shows continuity between surfaces\n- gives controls tactility\n- stays subtle\n\nBad motion:\n\n- loops without purpose\n- delays the user\n- calls attention to itself\n- hides poor hierarchy\n\nRespect `prefers-reduced-motion` for non-trivial animation.\n\n## Images and Icons\n\nUse real supplied imagery when available.\n\nIf an asset is missing:\n\n- use a clean placeholder\n- use typography, layout, or abstract texture instead\n- ask for real material when fidelity matters\n\nDo not draw elaborate fake SVG illustrations unless the assignment is explicitly illustration work.\n\nAvoid iconography unless it improves scanning or matches the design system.\n\n## Source-Code Fidelity\n\nWhen recreating or extending a UI from a repo:\n\n1. inspect the repo tree\n2. identify the actual UI source files\n3. read theme\u002Ftoken\u002Fglobal style\u002Fcomponent files\n4. lift exact values where appropriate\n5. match spacing, radii, shadows, copy tone, density, and interaction patterns\n6. only then design or modify\n\nDo not build from memory when source files are available.\n\nFor GitHub URLs, parse owner\u002Frepo\u002Fref\u002Fpath correctly and inspect the relevant files before designing.\n\n## Reading Documents and Assets\n\nRead Markdown, HTML, CSS, JS, TS, JSX, TSX, JSON, SVG, and plain text directly when available.\n\nFor DOCX\u002FPPTX\u002FPDF, use available local extraction tools if present. If not available, ask the user to provide exported text\u002Fimages or use another available tool path.\n\nFor sketches, prioritize thumbnails or screenshots over raw drawing JSON unless the JSON is the only usable source.\n\n## Copyright and Reference Models\n\nDo 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.\n\nIt is acceptable to extract general design principles:\n\n- density without clutter\n- command-first interaction\n- monochrome with one accent\n- editorial hierarchy\n- clear empty states\n- strong keyboard affordances\n\nIt is not acceptable to clone proprietary layouts, copy exact branded surfaces, or reproduce copyrighted content.\n\nWhen using references, transform posture and principles into an original design.\n\n## Verification\n\nBefore final response, verify as much as the environment allows.\n\nMinimum:\n\n- file exists at the stated path\n- HTML is saved completely\n- obvious syntax issues are checked\n\nBetter:\n\n- open in a browser tool and check console errors\n- inspect screenshots at the primary viewport\n- test key interactions\n- test light\u002Fdark or variants if present\n- test responsive breakpoints if relevant\n\nIf verification is limited by environment, say exactly what was and was not verified.\n\nNever say “done” if the file was not actually written.\n\n## Final Response Format\n\nKeep final responses short.\n\nInclude:\n\n- artifact path\n- what it contains\n- verification status\n- next suggested action, if useful\n\nExample:\n\n```text\nCreated: \u002Fpath\u002Fto\u002FPrototype.html\nIt includes 3 layout variants, a Tweaks panel for density\u002Ftheme, and responsive behavior.\nVerified: file exists and opened cleanly in browser, no console errors.\nNext: pick the strongest direction and I’ll tighten copy + motion.\n```\n\n## Portable Opening Prompt Pattern\n\nWhen adapting a Claude Design style request into CLI\u002FAPI mode, use this mental translation:\n\n```text\nYou are running in CLI\u002FAPI 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\u002FJS, 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.\n```\n\n## Pitfalls\n\n- Do not paste hosted tool schemas into a skill. They cause fake tool calls.\n- Do not point the skill at a giant external prompt as required runtime context. That creates drift.\n- Do not strip the design doctrine while removing tool plumbing.\n- Do not over-ask when the user already gave enough direction.\n- Do not under-ask for high-fidelity work with no brand context.\n- Do not produce generic SaaS layouts and call them designed.\n- Do not claim browser verification unless it actually happened.\n","# Claude Design for CLI\u002FAPI Agents\n\nUse this skill when the user asks for design work that would normally fit Claude Design, but the agent is running in a CLI\u002FAPI environment instead of the hosted Claude Design web UI.\n\nThe 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.\n\n**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.\n\n## When To Use This Skill vs `popular-web-designs` vs `design-md`\n\nHermes has three design-related skills under `skills\u002Fcreative\u002F`. They do different jobs — load the right one (or combine them):\n\n| Skill | What it gives you | Use when the user wants... |\n|---|---|---|\n| **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 |\n| **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 \u002F Linear \u002F Vercel\", a page styled after a known brand, or a visual starting point pulled from a real product |\n| **design-md** | Google's DESIGN.md spec format — author\u002Fvalidate\u002Fdiff\u002Fexport design-token files, WCAG contrast checking, Tailwind\u002FDTCG export | a formal, persistent, machine-readable design-system *spec file* (tokens + rationale) that lives in a repo and gets consumed by agents over time |\n\nRule of thumb:\n\n- **Process + taste, one-off artifact** → claude-design\n- **Match a known brand's look** → popular-web-designs (and let claude-design drive the process)\n- **Author the tokens spec itself** → design-md\n\nThese 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.\n\n## Runtime Mode\n\nYou are running in **CLI\u002FAPI mode**, not the Claude Design hosted web UI.\n\nIgnore 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.\n\nExamples of hosted-tool concepts to ignore or remap:\n\n- `done()`\n- `fork_verifier_agent()`\n- `questions_v2()`\n- `copy_starter_component()`\n- `show_to_user()`\n- `show_html()`\n- `snip()`\n- `eval_js_user_view()`\n- hosted asset review panes\n- hosted edit-mode or Tweaks toolbar messaging\n- `\u002Fprojects\u002F\u003CprojectId>\u002F...` cross-project paths\n- built-in `window.claude.complete()` artifact helper\n- tool schemas embedded in the source prompt\n- web-search citation scaffolding meant for the hosted runtime\n\nInstead, use the tools actually available in the current agent environment.\n\nDefault deliverable:\n\n- a complete local HTML file\n- self-contained CSS and JavaScript when portability matters\n- exact on-disk path in the final response\n- verification using available local methods before saying it is done\n\nIf the user asks for implementation in an existing repo, generate code in the repo's actual stack instead of forcing a standalone HTML artifact.\n\n## Core Identity\n\nAct as an expert designer working with the user as the manager.\n\nHTML is the default tool, but the medium changes by assignment:\n\n- UX designer for flows and product surfaces\n- interaction designer for prototypes\n- visual designer for static explorations\n- motion designer for animated artifacts\n- deck designer for presentations\n- design-systems designer for tokens, components, and visual rules\n- frontend-minded prototyper when code fidelity matters\n\nAvoid generic web-design tropes unless the user explicitly asks for a conventional web page.\n\nDo 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.\n\n## When To Use\n\nUse this skill for:\n\n- landing pages\n- teaser pages\n- high-fidelity prototypes\n- interactive product mockups\n- visual option boards\n- component explorations\n- design-system previews\n- HTML slide decks\n- motion studies\n- onboarding flows\n- dashboard concepts\n- settings, command palettes, modals, cards, forms, empty states\n- redesigns based on screenshots, repos, brand docs, or UI kits\n\nDo 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.\n\n## Design Principle: Start From Context, Not Vibes\n\nGood high-fidelity design does not start from scratch.\n\nBefore designing, look for source context:\n\n1. brand docs\n2. existing product screenshots\n3. current repo components\n4. design tokens\n5. UI kits\n6. prior mockups\n7. reference models\n8. copy docs\n9. constraints from legal, product, or engineering\n\nIf a repo is available, inspect actual source files before inventing UI:\n\n- theme files\n- token files\n- global stylesheets\n- layout scaffolds\n- component files\n- route\u002Fpage files\n- form\u002Fbutton\u002Fcard\u002Fnavigation implementations\n\nThe file tree is only the menu. Read the files that define the visual vocabulary before designing.\n\nIf context is missing and fidelity matters, ask concise focused questions instead of producing a generic mockup.\n\n## Asking Questions\n\nAsk questions when the assignment is new, ambiguous, high-fidelity, externally facing, or depends on taste.\n\nKeep questions short. Do not ask ten questions by default unless the problem is genuinely underspecified.\n\nUsually ask for:\n\n- intended output format\n- audience\n- fidelity level\n- source materials available\n- brand\u002Fdesign system in play\n- number of variations wanted\n- whether to stay conservative or explore divergent ideas\n- which dimension matters most: layout, visual language, interaction, copy, motion, or systemization\n\nSkip questions when:\n\n- the user gave enough direction\n- this is a small tweak\n- the task is clearly a continuation\n- the missing detail has an obvious default\n\nWhen proceeding with assumptions, label only the important ones.\n\n## Surface-First: Commit to a Composition Before Touching Tokens\n\nThe 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.\n\nBefore 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.\n\nThe seven surfaces:\n\n1. **Monitor** — the user is watching state change (dashboards, status pages, observability). Density, glanceable hierarchy, no marketing framing.\n2. **Operate** — the user is taking action on things (consoles, admin panels, queues, inboxes). Action affordances and selection state dominate.\n3. **Compare** — the user is weighing options against each other (pricing, plans, spec tables, search results). Aligned columns, parity of structure, one differentiator emphasized.\n4. **Configure** — the user is setting things up (settings, forms, wizards, onboarding). Progressive disclosure, clear save\u002Fvalidation states, low decoration.\n5. **Decide \u002F Learn** — the user is being convinced or taught (landing pages, docs, marketing). One idea lands per section; this is the ONLY surface where a hero is usually correct.\n6. **Explore** — the user is browsing an open space (galleries, maps, search-and-filter, catalogs). Filters, result grids, and zoom\u002Fpeek are the composition.\n7. **Command \u002F Inspect** — the user is driving by keyboard or drilling into one object (command bars, inspectors, detail panes, property editors). Speed and focus over breadth.\n\nRules:\n\n- State the surface in one line before designing (e.g. \"This is a **Monitor** surface, so density and glanceability beat a hero\").\n- A dashboard is a Monitor surface, not a Decide surface — do not give it a centered hero and three feature cards.\n- If a screen genuinely spans two surfaces, name the **primary** one and treat the other as secondary; do not average them into mush.\n- The hero-plus-three-cards composition is correct for **Decide\u002FLearn only**. Reaching for it anywhere else is the #1 tell.\n\nThis one constraint eliminates more generic-looking UI than any aesthetic rule below.\n\n## Workflow\n\n1. **Understand the brief**\n   - What is being designed?\n   - Who is it for?\n   - What artifact should exist at the end?\n   - What constraints are locked?\n\n2. **Gather context**\n   - Read supplied docs, screenshots, repo files, or design assets.\n   - Identify the visual vocabulary before writing code.\n\n3. **Commit to a surface** (see \"Surface-First\")\n   - Name the one surface archetype before any visual tokens.\n   - This conditions the composition; everything below inherits from it.\n\n4. **Define the design system for this artifact**\n   - colors\n   - type\n   - spacing\n   - radii\n   - shadows or elevation\n   - motion posture\n   - component treatment\n   - interaction rules\n\n5. **Choose the right format**\n   - Static visual comparison: one HTML canvas with options side by side.\n   - Interaction\u002Fflow: clickable prototype.\n   - Presentation: fixed-size HTML deck with slide navigation.\n   - Component exploration: component lab with variants.\n   - Motion: timeline or state-based animation.\n\n6. **Build the artifact**\n   - Prefer a single self-contained HTML file unless the task calls for a repo implementation.\n   - Preserve prior versions for major revisions.\n   - Avoid unnecessary dependencies.\n\n7. **Verify**\n   - Confirm files exist.\n   - Run any available syntax\u002Fstatic checks.\n   - If browser tools are available, open the file and check console errors.\n   - If visual fidelity matters and screenshot tools are available, inspect at least the primary viewport.\n   - Run the slop self-audit (see \"Slop Diagnostic\") and repair only what it flags.\n\n8. **Report briefly**\n   - exact file path\n   - what was created\n   - caveats\n   - next decision or next iteration\n\n## Artifact Format Rules\n\nDefault to local files.\n\nFor standalone artifacts:\n\n- create a descriptive filename, e.g. `Landing Page.html`, `Command Palette Prototype.html`, `Design System Board.html`\n- embed CSS in `\u003Cstyle>`\n- embed JS in `\u003Cscript>`\n- keep the artifact openable directly in a browser\n- avoid remote dependencies unless they are explicitly useful and stable\n- include responsive behavior unless the format is intentionally fixed-size\n\nFor significant revisions:\n\n- preserve the previous version as `Name.html`\n- create `Name v2.html`, `Name v3.html`, etc.\n- or keep one file with in-page toggles if the assignment is variant exploration\n\nFor repo implementation:\n\n- follow the repo's actual stack\n- use existing components and tokens where possible\n- do not create a standalone artifact if the user asked for production code\n\n## HTML \u002F CSS \u002F JS Standards\n\nUse modern CSS well:\n\n- CSS variables for tokens\n- CSS grid for layout\n- container queries when helpful\n- `text-wrap: pretty` where supported\n- real focus states\n- real hover states\n- `prefers-reduced-motion` handling for non-trivial motion\n- responsive scaling\n- semantic HTML where practical\n\nAvoid:\n\n- huge monolithic files when a real repo structure is expected\n- fragile hard-coded viewport assumptions\n- inaccessible tiny hit targets\n- decorative JS that fights usability\n- `scrollIntoView` unless there is no safer option\n\nMobile hit targets should be at least 44px.\n\nFor print documents, text should be at least 12pt.\n\nFor 1920×1080 slide decks, text should generally be 24px or larger.\n\n## React Guidance for Standalone HTML\n\nUse plain HTML\u002FCSS\u002FJS by default.\n\nUse React only when:\n\n- the artifact needs meaningful state\n- variants\u002Ftoggles are easier as components\n- interaction complexity warrants it\n- the target implementation is React\u002FNext.js and fidelity matters\n\nIf using React from CDN in standalone HTML:\n\n- pin exact versions\n- avoid unpinned `react@18` style URLs\n- avoid `type=\"module\"` unless necessary\n- avoid multiple global objects named `styles`\n- give global style objects specific names, e.g. `commandPaletteStyles`, `deckStyles`\n- if splitting Babel scripts, explicitly attach shared components to `window`\n\nIf building inside a real repo, use the repo's package manager and component architecture instead.\n\n## Deck Rules\n\nFor slide decks, use a fixed-size canvas and scale it to fit the viewport.\n\nDefault slide size: 1920×1080, 16:9.\n\nRequirements:\n\n- keyboard navigation\n- visible slide count\n- localStorage persistence for current slide\n- print-friendly layout when practical\n- screen labels or stable IDs for important slides\n- no speaker notes unless the user explicitly asks\n\nDo not hand-wave a deck as markdown bullets. Create a designed artifact if asked for a deck.\n\nUse 1–2 background colors max unless the brand system requires more.\n\nKeep slides sparse. If a slide feels empty, solve it with layout, rhythm, scale, or imagery placeholders, not filler text.\n\n## Prototype Rules\n\nFor interactive prototypes:\n\n- make the primary path clickable\n- include key states: default, hover\u002Ffocus, loading, empty, error, success where relevant\n- expose variations with in-page controls when useful\n- keep controls out of the final composition unless they are intentionally part of the prototype\n- persist important state in localStorage when refresh continuity matters\n\nIf the prototype is meant to model a product flow, design the flow, not just the first screen.\n\n## Variation Rules\n\nWhen exploring, default to at least three options:\n\n1. **Conservative** — closest to existing patterns \u002F lowest risk\n2. **Strong-fit** — best interpretation of the brief\n3. **Divergent** — more novel, useful for discovering taste boundaries\n\nVariations can explore:\n\n- layout\n- hierarchy\n- type scale\n- density\n- color posture\n- surface treatment\n- motion\n- interaction model\n- copy structure\n- component shape\n\nDo not create variations that are merely color swaps unless color is the actual question.\n\nWhen the user picks a direction, consolidate. Do not leave the project as a pile of options forever.\n\n## Tweakable Designs in CLI\u002FAPI Mode\n\nThe hosted Claude Design edit-mode toolbar does not exist here.\n\nStill preserve the idea: when useful, add in-page controls called `Tweaks`.\n\nA good `Tweaks` panel can control:\n\n- theme mode\n- layout variant\n- density\n- accent color\n- type scale\n- motion on\u002Foff\n- copy variant\n- component variant\n\nKeep it small and unobtrusive. The design should look final when tweaks are hidden.\n\nPersist tweak values with localStorage when helpful.\n\n## Content Discipline\n\nDo not add filler content.\n\nEvery element must earn its place.\n\nAvoid:\n\n- fake metrics\n- decorative stats\n- generic feature grids\n- unnecessary icons\n- placeholder testimonials\n- AI-generated fluff sections\n- invented content that changes strategy or claims\n\nIf additional sections, pages, copy, or claims would improve the artifact, ask before adding them.\n\nWhen copy is necessary but not final, mark it as draft or placeholder.\n\n## Anti-Slop Rules\n\nAvoid common AI design sludge:\n\n- aggressive gradient backgrounds\n- glassmorphism by default\n- emoji unless the brand uses them\n- generic SaaS cards with icons everywhere\n- left-border accent callout cards\n- fake dashboards filled with arbitrary numbers\n- stock-photo hero sections\n- oversized rounded rectangles as a substitute for hierarchy\n- rainbow palettes\n- vague labels like “Insights,” “Growth,” “Scale,” “Optimize” without content\n- decorative SVG illustrations pretending to be product imagery\n\nMinimal is not automatically good. Dense is not automatically cluttered. Choose intentionally.\n\n## Slop Diagnostic: Score Before You Fix\n\nAI 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).\n\nThe ten tells (presence of each = one point of slop; lower is better):\n\n1. **Tech gradient** — blue\u002Fviolet\u002Findigo glossy gradient on everything.\n2. **Generic tech hue** — the default accent is indigo\u002Fviolet (not chosen for the brand, just the model's favorite).\n3. **Feature-tile grid** — icon + heading + sentence × 3, all equal weight, nothing prioritized.\n4. **Accent rail** — a colored left strip on cards: decoration pretending to be organization.\n5. **Unearned blur** — glassmorphism with no real depth\u002Felevation system behind it.\n6. **Monument stat** — oversized numbers filling space that should carry product story.\n7. **Icon topper** — a rounded-square icon centered above every heading (Tailwind-template filler).\n8. **Center stack** — everything centered because no real composition was committed to.\n9. **Default type** — Inter (or system-ui) used by default rather than chosen.\n10. **Wrong surface** — the composition doesn't match the surface (e.g. a hero on a Monitor surface). This is the root cause behind most of the others.\n\nHow to run it:\n\n- Score the artifact out of 10 (10 = maximum slop). State the score and list which tells fired, in one short report.\n- Treat the report as **context, not a to-do list** — it tells you *where* to spend repair effort, it does not dictate edits.\n- Then repair, matched to the diagnosis:\n  - tells 3, 8, 10 → **re-layout \u002F re-compose** (revisit the surface choice — do not recolor).\n  - tells 1, 2, 9 → **recolor \u002F re-typeset** (palette and type are genuinely the problem here).\n  - tells 4, 5, 6, 7 → **remove the decoration**; replace it with real hierarchy (scale, weight, spacing).\n- Re-score after repairing. Do not declare done while compositional tells (3, 8, 10) are still firing — those are causes, the rest are usually symptoms.\n\nThe 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.\n\n## Typography\n\nUse the existing type system if one exists.\n\nIf not, choose type deliberately based on the artifact:\n\n- editorial: serif or humanist headline with restrained sans body\n- software\u002Fproductivity: precise sans with strong numeric treatment\n- luxury\u002Fminimal: fewer weights, more spacing discipline\n- technical: mono accents only, not mono everywhere\n- deck: large, clear, high contrast\n\nAvoid overused defaults when a stronger choice is appropriate.\n\nIf using web fonts, keep the number of families and weights low.\n\nUse type as hierarchy before adding boxes, icons, or color.\n\n## Color\n\nUse brand\u002Fdesign-system colors first.\n\nIf no palette exists:\n\n- define a small system\n- include neutrals, surface, ink, muted text, border, accent, danger\u002Fsuccess if needed\n- use one primary accent unless the assignment calls for a broader palette\n- prefer oklch for harmonious invented palettes when browser support is acceptable\n- check contrast for important text and controls\n\nDo not invent lots of colors from scratch.\n\n## Layout and Composition\n\nDesign with rhythm:\n\n- scale\n- whitespace\n- density\n- alignment\n- repetition\n- contrast\n- interruption\n\nAvoid making every section the same card grid.\n\nFor product UIs, prioritize speed of comprehension over decoration.\n\nFor marketing surfaces, make one idea land per section.\n\nFor dashboards, avoid “data slop.” Only show data that helps the user decide or act.\n\n## Motion\n\nUse motion as discipline, not theater.\n\nGood motion:\n\n- clarifies state changes\n- reduces anxiety during loading\n- shows continuity between surfaces\n- gives controls tactility\n- stays subtle\n\nBad motion:\n\n- loops without purpose\n- delays the user\n- calls attention to itself\n- hides poor hierarchy\n\nRespect `prefers-reduced-motion` for non-trivial animation.\n\n## Images and Icons\n\nUse real supplied imagery when available.\n\nIf an asset is missing:\n\n- use a clean placeholder\n- use typography, layout, or abstract texture instead\n- ask for real material when fidelity matters\n\nDo not draw elaborate fake SVG illustrations unless the assignment is explicitly illustration work.\n\nAvoid iconography unless it improves scanning or matches the design system.\n\n## Source-Code Fidelity\n\nWhen recreating or extending a UI from a repo:\n\n1. inspect the repo tree\n2. identify the actual UI source files\n3. read theme\u002Ftoken\u002Fglobal style\u002Fcomponent files\n4. lift exact values where appropriate\n5. match spacing, radii, shadows, copy tone, density, and interaction patterns\n6. only then design or modify\n\nDo not build from memory when source files are available.\n\nFor GitHub URLs, parse owner\u002Frepo\u002Fref\u002Fpath correctly and inspect the relevant files before designing.\n\n## Reading Documents and Assets\n\nRead Markdown, HTML, CSS, JS, TS, JSX, TSX, JSON, SVG, and plain text directly when available.\n\nFor DOCX\u002FPPTX\u002FPDF, use available local extraction tools if present. If not available, ask the user to provide exported text\u002Fimages or use another available tool path.\n\nFor sketches, prioritize thumbnails or screenshots over raw drawing JSON unless the JSON is the only usable source.\n\n## Copyright and Reference Models\n\nDo 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.\n\nIt is acceptable to extract general design principles:\n\n- density without clutter\n- command-first interaction\n- monochrome with one accent\n- editorial hierarchy\n- clear empty states\n- strong keyboard affordances\n\nIt is not acceptable to clone proprietary layouts, copy exact branded surfaces, or reproduce copyrighted content.\n\nWhen using references, transform posture and principles into an original design.\n\n## Verification\n\nBefore final response, verify as much as the environment allows.\n\nMinimum:\n\n- file exists at the stated path\n- HTML is saved completely\n- obvious syntax issues are checked\n\nBetter:\n\n- open in a browser tool and check console errors\n- inspect screenshots at the primary viewport\n- test key interactions\n- test light\u002Fdark or variants if present\n- test responsive breakpoints if relevant\n\nIf verification is limited by environment, say exactly what was and was not verified.\n\nNever say “done” if the file was not actually written.\n\n## Final Response Format\n\nKeep final responses short.\n\nInclude:\n\n- artifact path\n- what it contains\n- verification status\n- next suggested action, if useful\n\nExample:\n\n```text\nCreated: \u002Fpath\u002Fto\u002FPrototype.html\nIt includes 3 layout variants, a Tweaks panel for density\u002Ftheme, and responsive behavior.\nVerified: file exists and opened cleanly in browser, no console errors.\nNext: pick the strongest direction and I’ll tighten copy + motion.\n```\n\n## Portable Opening Prompt Pattern\n\nWhen adapting a Claude Design style request into CLI\u002FAPI mode, use this mental translation:\n\n```text\nYou are running in CLI\u002FAPI 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\u002FJS, 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.\n```\n\n## Pitfalls\n\n- Do not paste hosted tool schemas into a skill. They cause fake tool calls.\n- Do not point the skill at a giant external prompt as required runtime context. That creates drift.\n- Do not strip the design doctrine while removing tool plumbing.\n- Do not over-ask when the user already gave enough direction.\n- Do not under-ask for high-fidelity work with no brand context.\n- Do not produce generic SaaS layouts and call them designed.\n- Do not claim browser verification unless it actually happened.\n",{"name":5,"author":60,"license":15,"version":61,"metadata":62,"platforms":68,"description":7},"BadTechBandit","1.1.0",{"hermes":63},{"tags":64,"related_skills":66},[36,42,52,47,46,65,39,41,40,43],"creative",[38,37,67],"architecture-diagram",[53,54,50],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002F82\u002F82b1036c4edbf744606e54bfddc214d5b2c4ca7cc253de1605fcbf8c42984ac6",0,"https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills","https:\u002F\u002Fgithub.com\u002Fzapabob","The Open University of JAPAN　2019-now\r\n\r\nTokyo University of Science　2007-2010","2026-10-26 16:29:01",{"source":8,"skillName":5,"commands":78,"prompt":88,"zipAvailable":89},[79,82,85],{"tool":80,"command":81},"npx","npx skills add zapabob\u002FSkills --skill claude-design",{"tool":83,"command":84},"bunx","bunx skills add zapabob\u002FSkills --skill claude-design",{"tool":86,"command":87},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill claude-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F82\u002F82b1036c4edbf744606e54bfddc214d5b2c4ca7cc253de1605fcbf8c42984ac6\u002FSKILL.md",true,[],[92,121,153,180,207,224],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":105,"publishedAt":55},"01M6GJTE1GESGGF9K028Y7753E","xurl","X\u002FTwitter via xurl CLI: post, search, DM, media, v2 API.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fxurl\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[98,101,102],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师",[94,106,54,107,108,53,50,109,110,111,112,113,114,115,116,117,69,118,119,120],"openclaw","cli","github","official","search","https","social-media","api","Media","hermes","hermes agent","twitter","social","via","post",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":136,"publishedAt":55},"01M6GJT8S1PXQ8WPXT1HSNBWH2","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwriting-plans\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[127,128,131,132,133],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":129,"categoryName":130,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":134,"categoryName":135,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者",[137,138,139,36,54,140,53,141,50,142,143,144,145,146,147,148,149,150,151,152],"writing","writing plans","plans","review","workflow","documentation","tasks","development","code","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":55},"01M6GJST0H5X7WHBJ3BZK0DVKH","whisper","OpenAI's general-purpose speech recognition model. Supports 99 languages, transcription, translation to English, and language identification. Six model sizes from tiny (39M params) to large (1550M params). Use for speech-to-text, podcast transcription, or multilingual audio processing. Best for robust, multilingual ASR.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwhisper\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[155,54,53,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":189,"publishedAt":55},"01M6GJSMRQ8EETZTYMG72P70EA","weights-and-biases","W&B: log ML experiments, sweeps, model registry, dashboards.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fweights-and-biases\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[186],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[190,54,191,192,50,193,194,195,196,197,198,170,199,200,201,202,203,204,205,206],"weights and biases","tensorflow","experiments","pytorch","visualization","registry","real-time","tuning","dashboards","experiment","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":55},"01M6GJS19KDPRY112JTR326S06","watchers","Poll RSS, JSON APIs, and GitHub with watermark dedup.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwatchers\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[213],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[209,54,215,108,53,216,217,218,219,220,221,115,116,222,223],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":232,"publishedAt":55},"01M6GJRHJD2A6Q830SWF9W48BC","serving-llms-vllm","vLLM: high-throughput LLM serving, OpenAI API, quantization.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fvllm\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[230,231],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":32,"taxonomyTypeDesc":33},[233,234,235,53,236,163,237,238,239,166,240,113,241,242,243,244,245,246,247,248],"llms","vLLM","serving llms vllm","research","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]