skills/ui-design/SKILL.md
Designs and builds UI: visual direction, Tailwind implementation, browser-comparable variants, screenshot-to-markup scaffolds, dark-mode and responsive retrofits, component extraction, and Tailwind cleanup. Use when asked to "build a landing page", "create a dashboard", "make this look premium", "pick a visual style", "design the UI", "show me 3 options", "create a brand kit", "turn this screenshot into markup", "add dark mode", "make this responsive", or "clean up the Tailwind". For product behavior use product-design; for UI audits use ui-audit; for motion use ui-animation; for copy use copywriting.
npx skillsauth add mblode/agent-skills ui-designInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Pick the visual direction, then implement it in code via the ui.sh design guideline system.
product-design); auditing existing UI quality (use ui-audit); deep typography audits (use typography-audit); motion design (use ui-animation); landing-page copy (use copywriting).Pick one mode from the user's wording; load only that mode's files:
| Mode | Dispatch when the user asks for | Load |
|------|--------------------------------|------|
| Direction | visual direction, palettes, fonts, tokens, "make this look premium", "pick a style", conversion strategy, a brand kit; deliverable is a spec, not code | the Direction section below |
| Build (default) | one design in code: "build a landing page", "create a dashboard", "add a pricing section" | design-guidelines.md, then the applicable rule files from its index |
| Options | variants to compare in the browser: "show me 3 hero layouts", "a few ideas for this section" | ideas.md plus the guidelines per variant |
| Scaffold | semantic, unstyled markup from a screenshot, Figma export, mockup, or wireframe: "turn this screenshot into markup" | markup-from-image.md only; scaffold stays unstyled |
| Dark mode | dark mode onto existing UI, or a dark variant of an image: "add dark mode", "make a dark version of this image" | add-dark-mode.md; for raster images also dark-mode-image.md (requires the imagegen skill, Codex) |
| Responsive | desktop UI across breakpoints: "make this responsive", "fix this on mobile" | make-responsive.md |
| Componentize | extracting components or cleaning up Tailwind classes: "componentize this page", "clean up the Tailwind" | componentize.md; for cleanup also canonicalize-tailwind.md |
Direction and Build chain: for a new surface with no direction, run Direction first (or propose one inline for small surfaces), then Build. If a direction already exists in the project, go straight to Build.
Output a decision set, not markup: a one-sentence visual thesis (mood, material, energy), palette as CSS variables, type pairing and scale, spacing grid, radius and depth strategy, the layout pattern for the primary surface, and for conversion pages the section sequence, CTA plan, and proof placement. Close with the track's litmus checks as the exit gate, then hand off to Build mode.
| Surface | Track | Optimises for | |---------|-------|---------------| | Dashboards, admin panels, data tables, settings pages, internal and dev tools | direction/product-ui.md | Information density, calm chrome, scanability, utility copy | | Landing pages, brand sites, promotional pages, portfolios, pricing pages | direction/marketing-ui.md | Visual impact, storytelling, one-CTA conversion flow |
Tie-breakers: a marketing site for a SaaS product is the marketing track; the app behind the login is product. Design them separately. Convert a stranger = marketing; let an operator work = product.
Load when the marketing track has a conversion goal (landing page, signup flow). Skip for pure brand/portfolio work and all product UI.
| File | Read when |
|------|-----------|
| direction/cro.md | Persuasion tactics, social proof, page length, or a CRO plan: Cialdini's principles, proof credibility hierarchy, conversion benchmarks |
| direction/testing.md | Optimising a page or planning experiments: test prioritisation, A/B vs multivariate, significance rules, heatmap insights, the canonical CTA statistics table |
| direction/modern.md | Personalisation and mobile-first conversion (page speed, accessible copy, and microcopy route out to optimise-seo and copywriting) |
For "create a brand kit", "generate a visual identity", or a brand direction board from a product idea, load direction/brand-kit-prompt.md; its Rendering section covers the imagegen handoff (Codex, gpt-image-2) and the text-only fallback for agents without it.
Rules:
design-guidelines.md is the single one-level index for guidelines/; load applicable rule files from there, do not maintain a second list here.Other modes follow their loaded file: Options ideas.md, Scaffold markup-from-image.md, Dark mode add-dark-mode.md, Responsive make-responsive.md, Componentize componentize.md.
Reference products below are calibration only; verify with this litmus checklist:
Reference calibration:
aesthetic-direction.md in Direction mode; skipping it defaults output toward generic Inter, white backgrounds, and purple gradients.colors.md in Build mode produces the stock Tailwind look: indigo accents and gray-* neutrals, both banned as defaults.ui-audit: page-level quality and accessibility audit of the built resulttypography-audit: rule-level audit of existing typography; route "fix the fonts" on shipped CSS thereui-animation: motion timing, easing, and reviewcopywriting: landing-page copy, message match, persuasion frameworksproduct-design: the product decision before the build (which interactions exist, action naming, reachable-state coverage); decide there, then build hereoptimise-seo: meta descriptions and page titlesdevelopment
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.