agentleFS
whawkinsivwhawkinsiv/claude-code-skills/skills/beautify/SKILL.md

beautify

Skill258 starsChanged 28 days agoMITView on GitHub

Use this skill to make an AI-built app look intentionally designed and behave well: 'make it look better,' 'it looks like a template,' 'something looks off,' 'make it look like Stripe or Linear,' 'review my design,' 'is the UI good enough to ship,' 'pick a look for my app,' or when building any new screen. Covers visual direction, hierarchy, spacing, color, type, the five UI states, error messages, accessibility basics, and a design review with a fix order. Not for marketing-page copy (use landing-page).

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read references/ai-slop-fixes.md for the 12 patterns AI-generated interfaces fall into and how to fix each one.

    line 12
  2. Distinctive:

    Ask one question: "What are you building, and who is it for?" Do not ask about colors or fonts.

    line 22
  3. Distinctive:

    Repeated items look identical: If one pricing card needs emphasis, change one thing: a border or a badge.

    line 43
  4. Distinctive:

    Prefer undo for actions that can be reversed.

    line 57
  5. Distinctive:

    Check every screen at phone width.

    line 60
  6. Distinctive:

    Run the app and look at the screens.

    line 64
  7. Distinctive:

    When to stop: before 10 customers, stop after items 1–4 and 7.

    line 77

≈ “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

Beautify

Make the app look intentionally designed instead of generated, and make every screen handle real data. Restraint is the main tool: fewer colors, fewer weights, fewer borders, fewer shadows.

Read references/ai-slop-fixes.md for the 12 patterns AI-generated interfaces fall into and how to fix each one. Examples there use Tailwind class names. Translate them to the project's own styling.

Choose the mode

  • Direction: a new app with no visual style yet. Do Step 1.
  • Build: a new screen. Apply the rules in Steps 2–4 while you build.
  • Review: existing screens. Do Step 5.

Step 1: Set a direction (once)

Ask one question: "What are you building, and who is it for?" Do not ask about colors or fonts. The founder reacts to proposals. They should not need design words.

Propose a direction in plain words, based on 1–2 well-known products the users already trust. For example: "Your users have this open all day, so calm and dense, like Linear: one cool accent, tight spacing, clean type." Adjust after the founder reacts. One to three rounds is normal.

Then write a small set of decisions where the project keeps its conventions (CLAUDE.md, or a file the founder names):

  • neutral colors, one accent color, and status colors (success, warning, error)
  • one font family, with 2–3 weights
  • one spacing scale (for example 4, 8, 12, 16, 24, 32, 48 px)
  • one corner radius and one shadow, or none

A finished logo is not needed before the first customers. The product name in the heading font is the logo.

Step 2: Visual rules

  • One focal point per screen. The primary action is the largest, highest-contrast element. Other buttons are outline or text buttons.
  • Size steps must be obvious. Headings 50–100% larger than body text. Two sizes 2px apart look like a mistake.
  • Space between groups is 2–3 times the space within a group. Most AI layouts have too little space between sections.
  • Color carries information. About 60% neutral, 30% secondary, 10% accent. Never use the full-strength accent color as a large background.
  • Two font weights for most screens: semibold for headings and labels, regular for body text.
  • Body text no wider than about 65 characters.
  • Left-align content. Center only heroes, empty states, and confirmations.
  • Repeated items look identical. If one pricing card needs emphasis, change one thing: a border or a badge.
  • Reuse before inventing. A new screen uses the existing buttons, cards, and spacing.

Step 3: Every data screen handles five states

  1. Loading: placeholders shaped like the real content. Use spinners only inside buttons and for a full-page load.
  2. Empty: say what will appear here and give one action to start. An empty screen is onboarding.
  3. Error: say what happened, why, and how to fix it. Keep the user's input. Never show a stack trace.
  4. Success: handles long names, missing optional fields, and odd image sizes.
  5. Overflow: paginate long lists, truncate long text, and show counts.

Step 4: Behavior and access

  • Give feedback within 100ms of every click.
  • Prefer undo for actions that can be reversed. Ask for confirmation only for irreversible actions, and name the consequence: "Delete 'Q4 Report'? This cannot be undone."
  • Text contrast of at least 4.5:1. A visible keyboard focus. A label on every input. Touch targets of at least 44px. The whole flow works with the keyboard.
  • Motion only to confirm an action or to keep the user oriented: 150–250ms, ease-out. Respect reduced-motion settings. Skip decorative animation before the product has customers.
  • Check every screen at phone width. Mobile breakage matters from the first customer.

Step 5: Review existing screens

Run the app and look at the screens. Take screenshots if you can. Name each issue by location ("the secondary button in the hero has the same weight as the main button"), not by feeling.

Fix in this order, one category at a time. Re-check after each category, because early fixes often solve later ones:

  1. Hierarchy: is the eye drawn to the main action?
  2. Spacing and alignment
  3. Color
  4. Typography
  5. Consistency across screens: the same header, padding, buttons, and cards everywhere
  6. The five states
  7. Phone width
  8. Motion and polish

When to stop: before 10 customers, stop after items 1–4 and 7. The goal is "intentionally designed," not "award-winning." Stop when the design no longer distracts from the product.

Output

  • Direction mode: the decisions written to the file the founder chose.
  • Review mode: issues grouped by the order above, each with its location and fix. Then fix them, one category at a time.

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.