ui-design

Files (120)

• SKILL.md
• add-dark-mode.md
• canonicalize-tailwind.md
• componentize.md
• dark-mode-image.md
• design-guidelines.md
• aesthetic-direction.md · direction/
• brand-kit-prompt.md · direction/
• cro.md · direction/
• design-in-code.md · direction/
• marketing-ui.md · direction/
• modern.md · direction/
• product-ui.md · direction/
• testing.md · direction/
• evals.json · evals/
• clean-settings.tsx · evals/fixtures/
• delete-version-modal.tsx · evals/fixtures/
• invite-member-form.tsx · evals/fixtures/
• northwind-generated-landing.tsx · evals/fixtures/
• pricing-page.tsx · evals/fixtures/
• real-proof-landing.tsx · evals/fixtures/
• merge-routing.json · evals/
• refine-ai-ui.json · evals/
• assets-api.md · guidelines/
• buttons.md · guidelines/
• colors.md · guidelines/
• components.md · guidelines/
• copywriting.md · guidelines/
• dark-mode.md · guidelines/
• dashboards.md · guidelines/
• font-recommendations.md · guidelines/
• footers.md · guidelines/
• form-controls.md · guidelines/
• general.md · guidelines/
• heading-groups.md · guidelines/
• icons.md · guidelines/
• images.md · guidelines/
• landing-pages.md · guidelines/
• materials.md · guidelines/
• navigation.md · guidelines/
• placeholder-content.md · guidelines/
• pricing-cards.md · guidelines/
• prose-content.md · guidelines/
• responsive-design.md · guidelines/
• section-layout.md · guidelines/
• shadows.md · guidelines/
• surfaces.md · guidelines/
• tables.md · guidelines/
• team-sections.md · guidelines/
• testimonials.md · guidelines/
• typography.md · guidelines/
• ideas.md
• make-responsive.md
• markup-from-image.md
• break-catalog.md · references/
• craft-checklist.md · references/
• defer-to-other-tools.md · references/
• design-system-extract.md · references/
• feature-playbooks.md · references/
• output-adapters.md · references/
• …and 60 more

SKILL.md (first lines)

# UI Design

Owns everything that touches the built artifact: pick the visual direction, implement it in code, and audit what shipped.

- **IS:** choosing visual direction (palettes, type scales, tokens, layout systems, CRO strategy, brand boards), building UI in code, and auditing built React or Next frontends for user-facing defects with `file:line` evidence, applied fixes, and a ship verdict.
- **IS NOT:** deciding what an interface should do before it exists (use `product-design`); non-UI correctness and code quality (use `tidy`); agentic-app review (use `ax-audit`); deep typography or motion passes (use `typography-audit`, `ui-animation`); measuring the rendered page in a browser (use `ui-verification`); the wording of a string (use `ghostwriter`).

## Contents

- [Existing brand and specs](#existing-brand-and-specs)
- [Modes](#modes)
- [Direction mode](#direction-mode)
- [Extract mode](#extract-mode)
- [Build mode](#build-mode)
- [Audit mode](#audit-mode)
- [Break mode](#break-mode)
- [Other modes](#other-modes)
- [Quality Bar](#quality-bar)
- [Verify](#verify)
- [Gotchas](#gotchas)
- [Related skills](#related-skills)

## Existing brand and specs

For brand positioning, identity changes, or a system spanning campaigns and physical applications, that is out of scope; name the open brand question and apply the identity the company already has. Direction mode applies that identity to UI; it does not reopen an approved brand.

Before choosing styles, read the project's existing `design.md`, `design-system.md`, or brand guide when present. Check its scope and source against the implemented theme; report drift instead of creating a second competing specification. A spec started from a client's assets records only what they supplied and marks each gap "Not supplied"; never fill gaps with your own defaults unless the client approves.

## Modes

Resolve one mode before acting, and load only that mode's files.

| Mode | Dispatch when the user asks for | Load |
|------|--------------------------------|------|
| **Direction** | visual direction, palettes, fonts, tokens, a brand kit, "pick a style"; deliverable is a spec, not code | the Direction section below |
| **Extract** | recording what an existing codebase already decided: "what design system does this use", "document our tokens", "inventory our components and scales" | [references/design-system-extract.md](./references/design-system-extract.md) only |
| **Build** | the target does not exist yet: "build a landing page", "create a dashboard", "add a pricing section" | [direction/aesthetic-direction.md](./direction/aesthetic-direction.md), [design-guidelines.md](./design-guidelines.md), then the applicable files from its index |
| **Audit** | the target exists and no change was named: "audit this component", "check my UI", "is this accessible", "design QA this page", "is this ready to ship". **Deslop scope** on "remove AI slop", "looks vibe coded", "simplify this UI" | [references/feature-playbooks.md](./references/feature-playbooks.md) and `rules/` only |
| **Break** | adversarial stress-testing with worst-case data: "stress-test this", "break this UI", "find the worst case", "what happens with a huge/empty/weird value" | [references/break-catalog.md](./references/break-catalog.md) only |
| **Options** | variants to compare in the browser: "show me 3 hero layouts" | [ideas.md](./ideas.md) plus the guidelines per variant |
| **Scaffold** | semantic, unstyled markup from a screenshot, Figma export, mockup, or wireframe | [markup-from-image.md](./markup-from-image.md) only; the scaffold stays unstyled |
| **Retrofit** | one dimension added to existing UI: "add dark mode", "make this responsive", "fix this on mobile" | [add-dark-mode.md](./add-dark-mode.md), [make-responsive.md](./make-responsive.md); for raster images also [dark-mode-image.md](./dark-mode-image.md) (requires the `imagegen` skill, Codex) |
| **Componentize** | extracting components or cleaning up classes: "componentize this page", "clean up the Tailwind" | [componentize.md](./componentize.md); for cleanup also [canonicalize-tailwind.md](./canonicalize-tailwind.md) |

**No mode named?** Build if the target does not exist. Audit if it does and no change was requested. Resolving "look at this page" or "can you improve this checkout" to Build silently skips the rule run, which is the most expensive mistake this table prevents.

**Named chrome fixes still audit.** "Feel native on mobile" runs existing `mobile-*` rules (viewport, hover-only actions) and `ui-animation` for press and hover gating. It does not go to Retrofit or Build. Retrofit's "fix this on mobile" is layout.

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. Extract chains ahead of both on an existing codebase: a direction chosen without knowing what the project already uses is a second design system, not a direction.

## Direction mode

A decision skill. It does ONE thing: choose the visual system. It writes no markup; the build is Build mode's job.

Output a decision set: 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 against the Quality Bar, then hand off to Build.

### Pick a track

| Surface | Track | Optimises for |
|---------|-------|---------------|
| Dashboards, admin panels, data tables, settings pages, internal and dev tools | [direction/product-ui.md](./direction/product-ui.md) | Information density, calm chrome, scanability, utility copy |
| Landing pages, brand sites, promotional pages, portfolios, pricing pages | [direction/marketing-ui.md](./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.

### Shared foundations (load with either track)

- [direction/aesthetic-direction.md](./direction/aesthetic-direction.md): AI-slop signals, restraint philosophy, reference products, polish details. Direction mode reads it after the track pick; Build and the Deslop scope load it first, with no track pick.
- [direction/design-in-code.md](./direction/design-in-code.md): low-fi ASCII wireframing and the copy-what-works workflow. Read before building a new surface from scratch.

### Marketing references (conversion pages only)

Load when the marketing track has a conversion goal. Skip for pure brand/portfolio work and all product UI.

| File | Read when |
|------|-----------|
| [direction/cro.md](./direction/cro.md) | Persuasion tactics, social proof, page length, or a CRO plan |
| [direction/testing.md](./direction/testing.md) | Optimising a page or planning experiments: what to test first, significance rules, scroll-map reading |
| [direction/modern.md](./direction/modern.md) | Personalisation and mobile-first conversion |

For "create a brand kit" or a brand direction board, load [direction/brand-kit-prompt.md](./direction/brand-kit-prompt.md); its Rendering section covers the `imagegen` handoff and the text-only fallback.

## Extract mode

A recording skill. It does ONE thing: read an existing codebase and write down the design decisions it already contains, as a durable `design-system.md` the other modes consume.

The guidelines defer to "what the project already does" constantly and cannot resolve it themselves; this mode is the answer they read. Load [references/design-system-extract.md](./references/design-system-extract.md) and nothing else. Five things go in the artifact: which theme source the build actually honours, the scales as used rather than as declared, the component inventory, the conventions in force, and the documented exceptions. Values, not prose.

Verify before trusting it. A theme value the build overrides is a value Build will use and the browser will discard, so check three scale values against computed styles with `ui-verification` and record any disagreement rather than quietly picking a side.

## Build mode

A construction skill. It does ONE thing: implement one design in code. Its posture is restraint: the smallest thing that serves the product, not the most impressive thing that fits.

1. Inspect the request and target files. Load the project's `design-system.md` if one exists; inspect the relevant token and component sources if no artifact exists. Run a full Extract only when requested or when inconsistent sources block the build.
2. Load `aesthetic-direction.md`, then `design-guidelines.md` and only the applicable files from its index.
3. Implement using the project's existing framework, component patterns, assets, and conventions.
4. Verify (below), which renders the result and exercises its states.

Rules:

- The guideline files are the source of truth for new UI work; `design-guidelines.md` owns the load contract, so do not maintain a second index here.
- **Build to the guideline, and know what will audit it.** A guideline that has a corresponding rule in `rules/` names it. Where a guideline sets a stricter build default than a rule's floor (touch targets: 48 build, 44 audit), build to the guideline.
- Preserve user constraints unless a guideline requires asking about a design conflict.

## Audit mode

A review skill. It does ONE thing: find user-facing defects in built UI and fix the ones it can reach. Its posture is the inverse of Build's: **default to flagging; approval is earned.**

**Load contract: `references/` and `rules/` only, plus `direction/aesthetic-direction.md` in the Deslop scope and nothing else from `direction/` or `guidelines/`.** An audit that loads the design guidance stops being an audit and becomes a redesign, which is the failure this contract exists to prevent. A finding that genuinely needs a new palette or type scale is emitted as a finding naming the mode to run next, not acted on.

Two carve-outs, both narrow on purpose. `aesthetic-direction.md` is a list of tells, so it lets Deslop recognise slop; it prescribes no palette, scale, or component, so it cannot supply a redesign. The project's own `design-system.md` is the other: it records what this codebase decided rather than what any codebase should, so reading it sharpens a drift finding into a conformance check instead of turning the pass into a redesign. Where a rule's false-positive guard cites a `guidelines/` file, that is provenance for a value already inlined in the rule, not an instruction to open it.

```text
Audit progress:
- [ ] Step 1: Scope (`git diff --name-only main -- '*.tsx' '*.jsx' '*.ts' '*.js' '*.css' '*.module.css'`, or the named files)
- [ ] Step 2: Detect features in scope (references/feature-playbooks.md)
- [ ] Step 3: Run each feature's playbook checks in order
- [ ] Step 4: Load only the rules/ files the playbook names; confirm each finding at its file:line

From mblode/agent-skills, MIT.

More from mblode/agent-skills