agentleFS
shayan-m81shayan-m81/layerwright/skills/library/better-layout/SKILL.md

better-layout

Skill8 starsChanged 38 days agoMITView on GitHub

Helps with grouping, alignment, reading order, progressive disclosure and other details that make a good layout.

26 other projects use a version of this, 17 of them edited; 2 new projects in the last 4 weeks, against 2 the 4 before.

Adopted by

Steady: 2 new projects took it in the last 4 weeks, 1× the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 2 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 1 new projectWeek of Oct 18: 0 new projectsWeek of Oct 25: 1 new projectWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 4 in all, so this is a hint, not a trend.

Most recently taken up by

Used with

Projects with it also use improve-ui, good-css and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Discriminative-shoji607Skill

    improve-ui

    Audit an existing product surface against its own design evidence, identify verified UI problems, and write self-contained implementation plans for another agent. Strictly read-only on product source. Use when asked to review, refine, improve, or clean up an interface without replacing its identity; investigate design-system drift; or prepare a design handoff.

    Also in 3 projects that use this

  • sanmidableSkill

    good-css

    Also in 3 projects that use this

  • agentset-aiSkill

    fixing-metadata

    Ship correct, complete metadata.

    Also in 3 projects that use this

  • wxyhgkSkill

    find-animation-opportunities

    Search a codebase or UI for places that don't animate but should, and reject everything that shouldn't. Read-only; it proposes motion with exact values, it does not implement it. Use when the user asks "what could be animated here?" or wants to "make this feel more alive". For fixing existing animations, use improve-animations or review-animations instead.

    Also in 6 projects that use this

  • VercelSkill

    baseline-ui

    Validates animation durations, enforces typography scale, checks component accessibility, and prevents layout anti-patterns in Tailwind CSS projects. Use when building UI components, reviewing CSS utilities, styling React views, or enforcing design consistency.

    Also in 3 projects that use this

  • studio-lgtmSkill

    make-interfaces-feel-better

    Apply design engineering best practices to polish UI components - use when reviewing or improving interfaces, animations, typography, or interaction details.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 18 edited versions we read keep these.

  • 1

    Distinctive

    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:

    Use logical properties for direction-dependent layout: padding-inline-start, margin-inline-end.

    line 26
  2. Distinctive:

    Never park a critical action where resizing or scrolling clips it.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “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

Layout

Position, spacing and alignment carry hierarchy before a word is read. This skill builds that structure and stress-tests it: resize it, translate it, mirror it for RTL.

Write every fix in the project's styling system. The numbers below are starting points for interfaces with no established density system, and where one applies, use it as written rather than a familiar-looking substitute. Keep deliberate platform chrome, compact professional tools and project tokens where they still pass the stress tests.

Hit areas and focus behavior belong to better-accessibility. Radius, shadows and animation belong to better-ui. Line length and text spacing belong to better-typography.

Group with space, not lines

Space groups first, background shapes second, separator lines last and only where space alone can't carry the structure. The gap between groups must be at least 2× the gap within one (8px intra-group to 16px+ inter-group), or the grouping reads as noise. Alignment edges and importance ordering are in grouping-and-alignment.md.

Keep controls distinct from content

Give every interactive element a background shape, a border, or a consistent placement zone. A control styled like the static text beside it does not read as a control.

Align to shared edges

Pick alignment edges and stick to them; every stray edge reads as noise. Use one project spacing step per level of subordination, where 16px is a useful default.

Use logical properties for direction-dependent layout: padding-inline-start, margin-inline-end. Reserve physical left and right for genuinely physical geometry.

Order by importance

The most important content sits near the top and the leading edge. Reading order flows top-to-bottom, leading-to-trailing. Think in leading and trailing, not left and right.

Hint at hidden content

Progressive disclosure needs a visible affordance. Use the project's established cue, or let the next item peek 16–32px past the scroll edge, or show a disclosure control. Content hidden with zero cue may as well not exist.

Breathing room between targets

Without an established density system, start with 12px between adjacent bordered or filled controls and 24px around borderless text- and icon-only ones. Compact layouts may use less, as long as better-accessibility hit areas don't overlap and the controls stay distinct. Layout margins and breakpoint recipes are in spacing-and-adaptivity.md.

Inset buttons from the edges

In content layouts, keep full-width buttons inside the layout margins with a visible radius, starting near 16px inline on mobile. Edge-to-edge actions work when they follow established platform chrome, account for safe areas and stay distinguishable from system UI.

Content bleeds, controls float

Backgrounds and media extend to the viewport edges. Controls and text stay inside the layout margins and safe areas (env(safe-area-inset-*)). Sticky chrome floats above the content layer rather than blocking it.

Hold structure until it breaks

Breakpoints come from the content, not device presets. Keep the expanded layout as long as it genuinely fits and collapse late. Prefer container queries for component-level adaptation, and test the smallest and largest sizes first.

Plan for growth and clipping

Translated strings grow, and short ones grow proportionally more, so a one-word button label is the riskiest thing on the screen. Put no fixed width or height on a text container, and let rows wrap. Test with pseudo-localization and one representative locale rather than budgeting a percentage.

Never park a critical action where resizing or scrolling clips it. Keep it in the normal flow, or in stable chrome suited to the product.

Before you finish

MistakeFix
margin-left / padding-right in a localizable layoutmargin-inline-start / padding-inline-end
Content-layout button touches the viewport edgeInset within the project margins; keep intentional platform chrome
Breakpoints at 768/1024 because they're the defaultsBreak where the content actually stops fitting
Fixed-width text container sized to one languagemax-width and wrapping; test pseudo-localization
Primary action at the clip-prone bottom of a paneSticky positioning or stable chrome with safe-area padding

Reporting

Severity. HIGH blocks content or an action at a supported viewport. MEDIUM harms hierarchy, reading order, or adaptability. LOW is isolated alignment or spacing polish.

Verification. Without a browser: logical properties in place of physical ones, container and media queries against the supported viewport list and DOM order against the intended reading order. With one: every supported width, 200% zoom and the RTL mirror. Report every check you could not run as Not verified.

Format. Group findings under the principle each violates, ordered by severity, one row per root cause listing every location it appears in:

SeverityLocationBeforeAfterWhy

Location is path/to/file:line. Why names the principle and the user impact.

End with Block when any HIGH remains, Approve otherwise, leaving the rest in the table as work to do. Never Approve coverage you did not inspect. With nothing to report, state "No actionable layout findings" and report verification.

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.