design-critique

name	design-critique
description	Pre-emit self-critique for UI/visual/design output (components, CSS, copy, layouts) — anti-slop gates, taste dials, and a design-token contract check, run BEFORE the work is shown, not after. Use whenever producing or editing anything with a visual/UX surface.
user-invocable	true

Design critique

A checklist run against your OWN output before you show it, not a linter run after the fact. This is the one home for several related ideas (hallmark's pre-emit self-critique, a slop-gate list, astryx-style token discipline) folded into a single skill rather than several overlapping ones or a whole new source module — the value here is procedural judgment, which is what a skill is for; building deterministic tooling around subjective taste would be false precision.

Slop gates — catch these before emitting

• Generic AI-visual-cliché markers: purple/blue gradient backgrounds with no reason, emoji used as section icons, everything centered regardless of content type, decorative rounded corners/shadows applied uniformly instead of purposefully, stock-phrase headers ("Unlock the power of...").
• Padding/spacing that wasn't decided, just defaulted. If every gap is the same "safe" value, that's the tell of not having actually looked at the layout.
• Copy that describes instead of communicates. "This section shows your recent activity" above a list literally showing recent activity is filler, not information.

Pre-emit self-critique (do this last, right before showing the work)

Look at what you are about to output and ask, plainly: would someone who does this for a living ship it, or does it read as generated? If the honest answer is "generated," name the specific reason (not "needs polish") and fix that one thing before emitting — vague dissatisfaction doesn't converge, a named defect does.

Taste dials — calibrate, don't default

State (even briefly, to yourself) where this piece sits on the axes that matter for its context: formal ↔ playful, dense ↔ spacious, bold ↔ restrained. A dashboard for financial data and a landing page for a kids' app should not default to the same visual voice.

Token-contract check

If the project already defines a design-token system (CSS custom properties, a Tailwind config, a theme object), every color/spacing/type value in new work should reference a token, not a one-off magic value — an unreferenced #3b82f6 next to a token file that defines --color-primary is a drift bug, not a style choice. If no token system exists, this check doesn't apply — don't invent one uninvited.

Boundary

This is a self-review pass, not a build gate — there's no CI enforcement here, deliberately: taste resists deterministic scoring, and a false-precision linter for it would produce confident-wrong verdicts. It also isn't a replacement for testing the actual rendered result in a browser when the work is inspectable that way — this catches what looking at code alone can catch. Motion/animation taste is a large enough topic to warrant its own skill rather than sprawling this one — see motion-design for anything with a transition, animation, or micro-interaction in it.