Design critique polish
Skill markoblogo/abvx-agent-skills/skills/design-critique-polish
Reviewable capability layer for coding agents. Portable skills, delivery gates, workflow patterns, and verification-first engineering.
npx -y skills add markoblogo/abvx-agent-skills --skill design-critique-polishAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Critique and polish frontend interfaces before shipping, with focused review of hierarchy, typography, spacing, states, color, and UX clarity. Use when a page, component, or app surface feels unclear, inconsistent, flat, awkward, under-tested, or not yet production-grade and needs design verification instead of a broad rewrite.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.0 KB, as published. Nobody here has run it
Design Critique Polish
Run a deliberate critique pass before shipping. This is not a vague “make it nicer” prompt.
Use For
- pre-ship review of a frontend surface;
- critique after implementation but before release;
- “this feels off, but I do not know why” situations;
- tightening hierarchy, spacing, typography, copy, motion, and edge states.
Inputs
Take:
- the page, component, or route to review;
- screenshots, live URL, or repo files;
- current
PRODUCT.md/DESIGN.mdif available; - known constraints: ship date, design system, browser targets, accessibility requirements.
Critique Order
Evaluate in this order:
- Surface fit
- does this look like the right class of product or brand?
- Hierarchy
- can a first-time user tell what matters first?
- Layout and rhythm
- spacing, grouping, alignment, section cadence, empty space.
- Typography
- font choice, scale, line length, display/body contrast, overflow.
- Color and contrast
- palette discipline, readable text, accent overuse, weak affordances.
- States and resilience
- hover, focus, loading, empty, error, disabled, overflow, long labels.
- Motion and interaction
- helpful versus noisy; reduced-motion handling. If the diff materially changes transitions, keyframes, gestures, Lottie, popovers, toasts, or hover/press motion, run
motion-review-gateas the dedicated review pass.
- helpful versus noisy; reduced-motion handling. If the diff materially changes transitions, keyframes, gestures, Lottie, popovers, toasts, or hover/press motion, run
- Technical quality
- responsive behavior, accessibility signals, obvious performance issues.
Output Mode
Produce:
what workswhat failshighest-leverage fixes firstship blockers
Keep findings concrete. Name the surface, the defect, and the consequence.
Fix Strategy
- Prefer small, high-leverage corrections over full rewrites.
- If the core design language is wrong, say so explicitly instead of endlessly polishing local details.
- If the page is good enough to ship, say that too and focus on blockers only.
Common Frontend Tells To Catch
- same card pattern repeated everywhere;
- weak first viewport with no real anchor;
- gray text that reads low-contrast on tinted backgrounds;
- spacing that is mechanically even instead of rhythmic;
- headings that overflow or collapse on tablet/mobile;
- decorative motion without task value;
- UI copy that sounds like implementation notes rather than product language.
Final Report
Include:
- top issues ordered by severity;
- what should change now versus later;
- whether the surface is ship-ready;
- what to verify in-browser after changes.