---
name: flawless-ui-ux
description: Create, redesign, refine, or review web interfaces with contextual art direction, task-specific workflows, and AI slop prevention.
---

# Flawless UI/UX

Help the visitor understand and complete the requested task. Use the existing project context, preserve sound decisions, and improve clarity, behavior, and visual coherence. Scale investigation and guidance to what the work actually needs.

## Select the procedure

Read the request and inspect its target. Identify the visitor's task, existing visual decisions, supplied content, and what must remain. Select one primary procedure and read it before making the decisions it governs; reuse guidance already current in the session.

| Procedure | Select when and preserve |
|---|---|
| [Create](references/workflows/create.md) | A missing surface is needed. Build its complete task path; inherit the surrounding system when one exists. |
| [Redesign](references/workflows/redesign.md) | Visual replacement is authorized. Replace permitted decisions while preserving facts and required behavior. |
| [Refine](references/workflows/refine.md) | An existing target needs improvement. Preserve identity, content, behavior, and everything outside the intervention. |
| [Review](references/workflows/review.md) | Findings are requested without implementation. Inspect and report with project files unchanged. |

Default an ambiguous existing-interface improvement to refinement. Adding a field does not require a new visual identity. Review with authorized fixes uses the appropriate editing procedure with diagnosis before changes. Planning-only work stops at a solution outline, without edits or claims of completed verification. Separate mixed targets by their own boundaries.

Inspect existing sources before asking about missing information. Ask when an unresolved fact changes product truth, scope, or consequential behavior; continue independent work while awaiting the answer. Backend-only work and repository administration do not need this skill.

## Match the work behind the screen

Select a primary task guide when it changes the decisions needed. A screen name is not a specification: billing settings and a public pricing page support different work. Narrow refinements and reviews can use subject guidance alone.

| Work | Relevant guidance |
|---|---|
| Find, understand, compare, or act on records; dashboards, queues, tables, inboxes | [Data interfaces](references/tasks/data-interfaces.md) |
| Collect information or change state; settings, registration, onboarding, checkout, subscriptions | [Forms and journeys](references/tasks/forms-and-journeys.md) |
| Explain an offer and support an informed next action | [Content: persuasion](references/tasks/content-interfaces.md#persuasion) |
| Explain or reference information over sustained reading | [Content: reading](references/tasks/content-interfaces.md#reading) |
| Discover a collection or explore work and its detail views | [Content: exploration](references/tasks/content-interfaces.md#exploration) |

Pair these with the applicable purpose in [Surfaces](references/surfaces.md): persuasion, task execution, reading, or exploration. Use a secondary task section only for the region that needs it. A dashboard's edit dialog needs form guidance locally; its help panel does not turn the dashboard into a marketing page. Unfamiliar surfaces can use the primary procedure and relevant subject guidance without forcing a category.

## Load subject detail by need

References are relative to this skill directory. Read only the subject sections needed for the current decisions, reusing guidance while it remains applicable.

| Need | Reference |
|---|---|
| Establish a brief, inspect existing constraints, or resolve an asset gap | [Context](references/context.md) |
| Choose or replace a visual direction | [Direction](references/direction.md), using relevant [design studies](references/design-studies.md) to make structural choices and quality targets concrete |
| Prevent generic defaults or investigate visual and content patterns | Relevant sections of [AI slop prevention](references/anti-slop.md), during direction and affected review |
| Adjust visual execution | Relevant sections of [Craft](references/craft.md): [hierarchy](references/craft.md#hierarchy), [typography](references/craft.md#typography), [layout](references/craft.md#layout-and-spacing), [color](references/craft.md#color), [imagery](references/craft.md#imagery), [responsive composition](references/craft.md#responsive-composition) |
| Change controls, wording, accessibility, states, or motion | The relevant sections of [Interaction](references/interaction.md), including [accessibility acceptance](references/interaction.md#accessibility-acceptance) for affected content and controls |
| Critique an interface or verify a change | [Review](references/review.md) |

Use short working notes for the task basis, solution, and acceptance cases; keep them in the conversation or existing project records unless durable documentation is requested or needs maintenance. The procedures are decision guidance, not mandatory reports or approval ceremonies.

## Keep decisions honest

- Explicit user choices take precedence over the skill's aesthetic preferences. Preserve established identity during refinement.
- Tie visual choices to content, brand, task, or experience. A familiar font, gradient, card, or layout is a reason to examine its purpose, not an automatic defect.
- Use prevention guidance when a relevant concern needs investigation; it is not an exhaustive checklist for every edit. Preserve intentional brand choices and useful substance. Appearance does not prove AI authorship.
- A familiar, well-executed solution can be the finished result. Expressiveness, novelty, and minimalism are choices governed by the brief, not quality requirements. Prefer descriptive headings and concrete copy over recurring slogans.
- Do not confuse avoiding recurring patterns with making good decisions. Choose composition, type, density, and imagery for the actual audience and task; adapt starter and library defaults where they conflict. Validate the result against that basis using [Review](references/review.md#check-design-fit-and-access), rather than accepting either novelty or familiarity as proof of quality.
- Do not invent testimonials, customers, awards, business metrics, or other proof. Identify sample content that needs confirmation; never present a decorative control as a working integration.
- Keep controls understandable, content accessible, and responsive behavior appropriate to the task. Do not expand a focused request into an unrelated audit.
- Report only checks and observations actually performed. A screenshot cannot establish keyboard behavior or full accessibility compliance.

Use host tools and permissions. Do not assume a browser, image generator, paid service, model, or component library exists. Correct task and access failures first, then comprehension and finish; repeat affected checks after changes. Stop when material in-scope issues are resolved or a specific limitation prevents progress. If a requested check cannot run, identify it as outstanding. Useful static work can be delivered with rendered and interaction behavior explicitly unverified.

Complete the requested visual treatment as well as the task path; resolving functional failures does not finish an authorized design intervention. Deliver the result with material decisions, relevant verification, and remaining limitations. Keep the report proportional; use the finding structure in [Review](references/review.md#communicate-findings) when a critique is the deliverable.