How do I install the UI UX skill?

Run npx skillmds@latest add adityahegde712/ui-ux in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is UI UX safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with UI UX?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is UI UX free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

AdityaHegde712 (@adityahegde712) published this skill. Their other Agent Skills are listed on their SkillMD profile.

UI UX by adityahegde712 — Agent Skill

Name: UI UX
Author: AdityaHegde712

UI UX

Govern UI/UX design and decision-making for any application, framework, platform, interface, interaction flow, component, page, or visual experience. Invoke whenever work involves UI/UX choices, including new designs, redesigns, layout changes, user flows, visual styling, components, interaction patterns, or other decisions affecting the user experience.

File contents

UI/UX Design Workflow

UI/UX decisions require user clarification, rendered validation, and explicit approval before the design is locked.

1. Interview Before Designing

Before committing to material UI/UX decisions, interview the user to resolve relevant ambiguities: user goals, target audience, visual direction, theme, branding, information hierarchy, layout, navigation, interaction flows, component behavior, responsive behavior, accessibility expectations, states/transitions, density, reference products/designs, platform constraints. Ask only questions that materially affect design; never silently invent important preferences.

2. Produce a Renderable Prototype

Create an HTML/CSS representation representing intended content hierarchy, layout, spacing, typography, visual language, components, interaction states, and navigation/flow. Do not create token mockups.

3. Render With Playwright

Render the HTML prototype using Playwright. Inspect for: clipping, overflow, broken layout, visual hierarchy, spacing, responsive issues, and obvious accessibility/usability problems. Fix visible issues before presenting. If Playwright is unavailable, install it at the project level to proceed.

4. Capture and Present Screenshots

Capture screenshots sufficient to communicate the design and present to the user. Use actual rendered results (not only prose, wireframes, or code) as the basis for approval.

5. Require Explicit Approval

Design MUST NOT be treated as locked without explicit user approval. If changes are requested: feedback -> revise HTML/CSS -> render with Playwright -> inspect -> capture screenshots -> present again (repeat until explicit approval received; do not skip loop for small changes). Proceed with implementation only after approval.

Completion Check

Before treating design as approved or implementing:

Ambiguities discussed without silently inventing preferences.
Non-placeholder HTML/CSS prototype created and rendered with Playwright.
Rendered result inspected and relevant screenshots presented to user.
Requested revisions rerendered, reshown, and explicitly approved by user.

---name: ui-uxdescription: Govern UI/UX design and decision-making for any application, framework, platform, interface, interaction flow, component, page, or visual experience. Invoke whenever work involves UI/UX choices, including new designs, redesigns, layout changes, user flows, visual styling, components, interaction patterns, or other decisions affecting the user experience.---# UI/UX Design WorkflowUI/UX decisions require user clarification, rendered validation, and explicit approval before the design is locked.## 1. Interview Before DesigningBefore committing to material UI/UX decisions, interview the user to resolve relevant ambiguities: user goals, target audience, visual direction, theme, branding, information hierarchy, layout, navigation, interaction flows, component behavior, responsive behavior, accessibility expectations, states/transitions, density, reference products/designs, platform constraints. Ask only questions that materially affect design; never silently invent important preferences.## 2. Produce a Renderable PrototypeCreate an HTML/CSS representation representing intended content hierarchy, layout, spacing, typography, visual language, components, interaction states, and navigation/flow. Do not create token mockups.## 3. Render With PlaywrightRender the HTML prototype using Playwright. Inspect for: clipping, overflow, broken layout, visual hierarchy, spacing, responsive issues, and obvious accessibility/usability problems. Fix visible issues before presenting. If Playwright is unavailable, install it at the project level to proceed.## 4. Capture and Present ScreenshotsCapture screenshots sufficient to communicate the design and present to the user. Use actual rendered results (not only prose, wireframes, or code) as the basis for approval.## 5. Require Explicit ApprovalDesign MUST NOT be treated as locked without explicit user approval.If changes are requested: `feedback -> revise HTML/CSS -> render with Playwright -> inspect -> capture screenshots -> present again` (repeat until explicit approval received; do not skip loop for small changes). Proceed with implementation only after approval.## Completion CheckBefore treating design as approved or implementing:- [ ] Ambiguities discussed without silently inventing preferences.- [ ] Non-placeholder HTML/CSS prototype created and rendered with Playwright.- [ ] Rendered result inspected and relevant screenshots presented to user.- [ ] Requested revisions rerendered, reshown, and explicitly approved by user.

Frequently asked questions