Score UI genericity before merging code

This skill turns a vague "this looks generated" reaction into a structured UI Slop Score review for rendered web or iOS screens. It is a review workflow, not source-code linting and not a claim about who built the UI: it looks at a real screenshot, running app, or rendered component rather than an imagined result from a prompt. The review names the screen's job and primary user action, checks whether the visible nouns and content are product-specific or could be swapped into any SaaS app, and screens for common tells - a generic dashboard or card-grid structure, fake metrics, vague labels, decorative gradient or glass treatment, filler content, inert controls, and missing loading, empty, or error states. Based on those findings it produces a UI Slop Score from 0 to 100, where 100 signals the highest risk of looking interchangeable with any other product, and explains the two or three concrete reasons behind that score rather than presenting a fabricated precision figure. It closes with the smallest concrete repair plan, favoring a clearer workflow, product-specific content, real control outcomes, and reachable states over adding more visual decoration.

Use it when a user asks whether a UI looks generic or generated, when a rendered web or iOS screen needs an honest pre-merge visual review, or when a screenshot, local implementation, PR, redesign, or coding-agent output needs a short, actionable UI Slop Score. Do not use it as an accessibility, usability, security, or visual-quality guarantee - it is a focused product-specificity review only. It also cannot score an imagined result described only in a prompt; a rendered screenshot, running app, or component is required.

The input is a real rendered screen: a screenshot, a running app, or a rendered component. The output is a UI Slop Score from 0 to 100 with named score bands - 0-29 is specific enough to ship while still checking real states and responsive behavior, 30-59 means recognizable defaults are leaking in and the highest-impact structural choice should be repaired first, 60-79 means the screen is likely interchangeable and the hierarchy should be rebuilt around the product job and real user decision, and 80-100 means it should not ship yet and needs to be rebuilt from evidence instead of a template. The output also includes the two or three specific observed reasons for the score and a smallest-concrete-repair-plan recommendation.

Developers and reviewers using coding agents who need an honest pre-merge check on whether generated UI looks generic, and teams evaluating a screenshot, PR, redesign, or coding-agent output before it ships. Two worked examples are included: a billing dashboard scored 72/100 for its generic card-grid structure and vague metric labels, and a checkout flow scored 58/100 for missing error states and filler copy.