designlisted
Audit and fix the design of interfaces that already exist in files, across 17 modes (checkup, smell, review, deslop, typeset, recolor, motion, interaction, relayout, responsive, redesign, tokenize, setup, finish, refine, voice, surface). Use this whenever the user types "/design" or "design" followed by a mode name or a target file. Also use it, without waiting for the word "design", whenever someone says a screen looks generic, AI-generated, templated, sloppy, boring, flat, weak, unfinished, or "like every other landing page", or asks to audit, critique, review, de-slop, restyle, recolor, retype, relayout, tighten, polish, or ship-check an existing page or component. Trigger on complaints about a hero, feature cards, spacing, type hierarchy, color palette, motion, hover or focus states, empty and error states, dark mode, or responsive behavior in code that is already written. For inventing a brand new interface from nothing, prefer the frontend-design skill; this skill is for UI that is already in files.
adnanalpolink/design-skill · ★ 0 · Web & Frontend · score 60
Install: claude install-skill adnanalpolink/design-skill
# design
Generated UI has a look. The model was never missing the capability, it was missing the policy of *when*. Absent a policy it picks the median answer, and the median of every landing page ever written is indigo, centered, three tiles.
This skill is that policy: a curriculum of principles, a catalogue of common violations, and a bar each mode must clear before it may claim it did anything.
## The four rules
Every mode inherits these. They are what keep the loop honest.
**1. Report modes only report.** `checkup`, `smell`, and `review` write their `.md` and `.html` artifacts and stop. They never edit a source file, not even an obvious one-line fix. Fixing is a separate, explicit command, so an audit never changes a file behind the user's back.
**2. Treatment modes read the reports first.** Any mode that changes the interface checks `.design/` before deciding what to change, applies the findings that are relevant to its own job, and then still runs its own full bar. A report is a head start, not a substitute for looking.
**3. Truthful completion.** Say "added", "fixed", or "changed" only when the change is visible in the rendered result. If something was looked at and left alone, the word is *inspected*, not *fixed*. If a state was implemented but cannot be reached in the current UI, say so plainly instead of counting it. A pass that cannot point at a visible change does not get to claim it made one.
**4. Never invent evidence.** Good design work is specific, and