ultrapolish-web

Universal polish for web interfaces. Any app or site, its own style, from 6/10 to 11/10 on detail, UX, and cohesion.

This is not a visual style. It is a craft standard and a procedure. It works with editorial monochrome, with dense data tools, with playful consumer apps. It makes what is already there feel considered, continuous, and alive.

0. The universality guard

Read this before touching a pixel.

1. Read before you write. Find the project's own rules: DESIGN.md, AGENTS.md, CLAUDE.md design sections, globals.css, tailwind.config, @theme blocks, token files, a motion.ts, a components directory. Grep for --radius, --ease, cubic-bezier, transition:, box-shadow, font-family, @media (prefers-. Build the intake table (section 1) before proposing anything.

2. Never introduce what the project does not have. No new typeface, no new palette, no new radius language, no new motion personality. If the site is sharp and flat, polish it sharp and flat. If it is soft and rounded, polish it soft and rounded.

3. Numbers here are defaults for projects without an established value. The project's own token wins whenever it is used consistently. Inconsistency is the finding; the value is not.

4. The anti-pattern list is a negative list. It says what reads as generic or careless. It does not imply a positive style.

5. No system? Build one with them before polishing. Do not hand over the technical template: it asks for OKLCH values and line-height ratios, and someone without a design system cannot fill that in. Run the six plain-language questions in references/finding-the-vibe.md, derive the numbers yourself, and show them what you derived in words they can push back on. The result is the 15-line contract in references/design-contract-template.md, agreed and committed before any pixel moves. Polishing without a contract produces a second, competing style.

6. Restraint is a deliverable. The right change is often "remove", "align", or "reuse". Every finding must name what the user gains. If you cannot, it is not a finding.

7. Look at it. Reading the code tells you what was intended; only the rendered result tells you what happened. Render the screen, screenshot it, and play any motion back at a tenth speed before writing a finding about it. Half the findings worth having are invisible in the source: the thing that lands a frame late, the two greys that turned out identical, the row that reflows at the second breakpoint, the state nobody wired up. A finding you have not seen is a guess, and it belongs in the output marked as one.

1. Workflow