agentleFS
markoblogomarkoblogo/abvx-agent-skills/skills/design-critique-polish/SKILL.md

design-critique-polish

Skill16 starsChanged 5 months agoMITView on GitHub

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

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run a deliberate critique pass before shipping.

    line 12
  2. Distinctive:

    Keep findings concrete. Name the surface, the defect, and the consequence.

    line 60
  3. Distinctive:

    Prefer small, high-leverage corrections over full rewrites.

    line 64
  4. Distinctive:

    If the core design language is wrong, say so explicitly instead of endlessly polishing local details.

    line 65
  5. Distinctive:

    If the page is good enough to ship, say that too and focus on blockers only.

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md if available;
  • known constraints: ship date, design system, browser targets, accessibility requirements.

Critique Order

Evaluate in this order:

  1. Surface fit
    • does this look like the right class of product or brand?
  2. Hierarchy
    • can a first-time user tell what matters first?
  3. Layout and rhythm
    • spacing, grouping, alignment, section cadence, empty space.
  4. Typography
    • font choice, scale, line length, display/body contrast, overflow.
  5. Color and contrast
    • palette discipline, readable text, accent overuse, weak affordances.
  6. States and resilience
    • hover, focus, loading, empty, error, disabled, overflow, long labels.
  7. 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-gate as the dedicated review pass.
  8. Technical quality
    • responsive behavior, accessibility signals, obvious performance issues.

Output Mode

Produce:

  • what works
  • what fails
  • highest-leverage fixes first
  • ship 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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.