Better Design — скилл

---
name: better-design
description: "Design, improve, and validate UI/UX for apps, websites, native interfaces, and games: an art direction derived from the product (dealt from materials and a structure drawn against recent builds when the user gives no visual cue, never the model's top-two habit; an Apple-like house style on request), a coherent visual system kept in the project's DESIGN.md, measured layout geometry, page anatomy by the visitor's job, an AI-slop catalog (template pages, eyebrows, tracked-caps labels, calibrated looks, narration and redundant helper text), a living motion language with an interaction kit, an opt-in pool of signature effects, accessibility, drop zones for every upload, and real states including skeletons. Use for interface creation, redesigns, focused UI changes, motion polish, design plans, and UX audits; not for backend-only tasks."
license: MIT
metadata:
  version: "1.8.0"
---

# Better Design

Make the requested task clear and actionable: the user can see where they are,
understands an action before activating it, receives a result, and can recover from an error.
Evaluate coherence, expressiveness, and accessibility separately. Do not promise perfect UX.

## 1. Establish scope and visual grounding

- Choose a mode: creation, focused improvement, audit, or plan. Keep audits read-only;
  do not implement changes in a plan. Do not add features the user did not request.
- Establish the platform from the request and project. Only when context is absent, use
  responsive web, semantic HTML, and WCAG 2.2 AA as the initial target.
- Define the actual device and viewport matrix before composing or changing a responsive
  surface. For a website, include mobile, tablet, desktop, and ultrawide layouts that the
  product supports; for a mobile game, include small and typical phones plus tablets. Design
  constraints and layout behavior must adapt to those surfaces rather than merely shrinking
  a desktop composition. For browser work, include browser zoom in the matrix because 75%,
  100%, and 150% can expose different clipping, density, reflow, and interaction failures.
- Before any UI work, look for the project's DESIGN.md (root, `docs/`, `design/`, or the path
  named in agent instructions) and read it completely. It is the single source of interface
  values: fonts, type scale, color roles, spacing, radii, component sizes, icons, and motion.
  Take every value in new or changed code from it by role or token name; never eyeball,
  round, or introduce a near-duplicate. Rules are in [design-md.md](references/design-md.md).
- Inspect the existing screen in the current runtime or through confirmed current captures,
  then inspect nearby components, tokens, styles, and project rules. The absence of DESIGN.md
  does not mean there is no design system: the code tokens are then the system.
  Preserve unrelated work in progress.
- Distinguish an implementation defect from a redesign request. Address the cause first:
  unclear ordering, an unpredictable action, poor feedback, data loss, or lost content.
- Make decisions in this order: explicit task and constraints → DESIGN.md and the existing system →
  platform conventions → domain tasks → this skill's configurable baseline.
  Functionality and applicable accessibility requirements apply at every level.
- **No visual direction is not a style.** When the user names no visual style and the
  project has no DESIGN.md, brand, code tokens, or live UI to inherit, do not fall back to a
  fixed look: deal a direction with [direction-deal.md](references/direction-deal.md)
  (`scripts/deal_direction.mjs`). It deals three starting materials from
  [materials.md](references/materials.md) and a page structure, cleared against recent