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? Propose one before polishing. Offer the 15-line design contract from references/design-contract-template.md, get it agreed, then work inside it. 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.

1. Workflow