Frontend Implementer: Claude Code skill for responsive UI

Frontend Implementer is a Claude Code skill, built at AR Labs, that holds our standards for building responsive web interfaces with Vite, React and Tailwind CSS 4, and the workflows that enforce them. Use it while an agent writes or reviews UI code. AI coding agents produce layouts that look right in one window and break on a phone, usually in the same handful of ways; this skill names thirteen of them, scans code for them, screenshots the result at five common screen widths, and requires the agent to check its own visual output before handing it to a person. We add rules to it as we find new failures.

How it works

The standards come first:

• Mobile first. The phone layout is the base; complexity is added at larger breakpoints, never patched downward.
• Three layers of responsiveness, used in order. Fluid sizing (clamp(), fractions, auto-fit grids) handles most needs; breakpoints handle structural shifts such as a stack becoming a sidebar; container queries handle a component that lives in different parents.
• Let content set height. No fixed-height content containers and no overflow-hidden to hide a layout problem.
• Touch and access. Interactive targets at least 44 by 44 pixels, small-viewport height units instead of vh, reduced-motion variants on animation, visible focus, and text contrast of at least 4.5:1.

Then three workflows, plus a self-check that runs before any UI change is shown to a person:

Behaviour spec. Before coding, fill a table of what changes at each viewport: the structure, what content shows or truncates, how interaction differs (hover becomes tap), and which layer handles it. Ambiguous decisions, such as how a data table behaves on a phone, are presented as named options for a person to choose.

Scan. Read a file against the thirteen failure patterns, grouped in three severities. A reference file gives, for each, what the bad code looks like, why AI generators produce it, and the corrected Tailwind 4 code. Critical: fixed-height containers, desktop-first breakpoints, pixel spacing, overflow-hidden as a default. Common: a single breakpoint, flex without wrapping, unscaled text, unsized images, hard-coded grid columns. Subtle: small touch targets, hover-only interactions, arbitrary z-index values, the same animation at every size. The report is a table of pattern, pass or fail, line numbers and the fix, grouped so the simplest fixes come first.

Viewport test. With a browser driven by Playwright, screenshot the running page at 360, 390, 768, 1024 and 1440 pixels wide, smallest first, and review each for horizontal overflow, clipped text, small targets, wrong stacking and layouts that fail to adapt between sizes.

Self-check before handing over. A person's eye is the final gate, not the first test. The next section describes what the agent checks.

The judgement it encodes

A passing build says the code runs, not that the picture is right. Before showing any UI change, the agent zooms into each region at the size a person would see it (full-page captures are for layout shape only), checks structural claims in the DOM (overlap, centring, horizontal overflow at 360 and 390 pixels), and measures the contrast of every text node against its real background in both light and dark mode, at the 4.5:1 and 3:1 thresholds.

Reading a screenshot is not judging it. The skill records a case where pale green text on white, at roughly 1.9:1 contrast, appeared in several screenshots and was transcribed correctly each time. Reading a screenshot as data extraction ("the element is there and the text is correct") hides a contrast defect, because the successful reading feels like evidence that the text is fine. The better the extraction, the stronger the false pass. So contrast is measured, not eyeballed.

Wait for transitions before measuring. After switching to dark mode, elements with colour transitions report values from mid-transition, which produces both false alarms and false passes. The skill waits about half a second before measuring.

Follow the site's colour grammar. On arlabs.tech, the bright accent colours are fills that carry black text, never text colours on a light background. Where a project has no written design language, its most refined existing pages serve as the specification.

List the defects and fix them first, then hand over, saying what was self-checked.

What exists today

The skill is written for our React and Tailwind projects. It covers engineering, not taste: visual direction is chosen beforehand with Design Probe, which produces an HTML reference that this skill then enforces standards against during the React build.

Example

Illustrative example. Part of a scan report on a pricing-card component:

| # | Pattern                   | Status | Lines  | Fix (Layer)                         |
|---|---------------------------|--------|--------|-------------------------------------|
| 1 | Fixed height containers   | FAIL   | 23     | `min-h-[22rem]` (Fluid)             |
| 2 | Desktop-first breakpoints | PASS   | -      | -                                   |
| 6 | Missing flex wrapping     | FAIL   | 41     | add `flex-wrap` (Fluid)             |
| 9 | Hardcoded grid columns    | FAIL   | 12     | `grid-cols-1 md:grid-cols-3` (Adaptive) |
| 10| Touch target too small    | FAIL   | 58     | `min-h-11 min-w-11` on icon button  |