agentleFS
Sign inStart free
malinskibeniaminmalinskibeniamin/skills/break-ui/SKILL.md

break-ui

Skill4 starsChanged 11 days agoMITView on GitHub

Stress-test UI data/layout: long text, Unicode, zoom, narrow containers, empty states, and large collections. Use during diagnosis, dogfood, visual review, or explicit break-it requests.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use animate-expo, write-swift and 3 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.
  • sanmidableSkill

    animate-expo

    Also in 9 projects that use this

  • sanmidableSkill

    write-swift

    Also in 10 projects that use this

  • cal1888Skill

    pick-ui-library

    Pick the right library for a given frontend task from a curated, opinionated list — numbers, OTP inputs, charts, command menus, virtualization, drag and drop, toasts, state, styling, and more. Only runs when explicitly invoked; it does not trigger on its own.

    Also in 11 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 14 projects that use this

  • ozgureyilmazSkill

    apple-design

    Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.

    Also in 11 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test the real component against unkind but valid data.

    line 6
  2. Very specific:

    Use existing stories/fixtures/mocks first.

    line 13
  3. Very specific:

    Use interface compatibility.

    line 22
  4. Distinctive:

    Read CATALOG.md. Choose realistic values within the actual contract.

    line 27
  5. Distinctive:

    Keep shape, component code, tokens, and rendering path unchanged.

    line 29
  6. Very specific:

    Check fixed-size flex siblings, min-width: 0/minmax(0, 1fr), unbreakable strings, multiline glyph clipping, grapheme-safe initials, …

    line 44

“Common” is measured: kept by at least 6 in 10 of the 26 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

Test the real component against unkind but valid data. Adapted from Emil Kowalski; provenance. This is a targeted data/layout audit, not a replacement for lifecycle dogfood or general visual critique.

Endpoint

An audit returns evidence and proposed fixes, without editing production components. Use existing stories/fixtures/mocks first. Create a dev-only toggle or isolated harness only when the request includes building one; keep scratch artifacts in .context/. An explicit fix request authorizes repairing confirmed defects through TDD and delivery; do not force another approval step for routine in-scope fixes.

Loop

For component-specific scenario selection, read the pinned scenario axes alongside this catalogue. Use interface compatibility; the separate user-only break page is recommended only when requested, never created by an audit alone.

  1. Map rendered fields, their source/type, schema limit, optionality, and collection bounds. A missing bound means unknown, not permission to invent one or change the API.
  2. Read CATALOG.md. Choose realistic values within the actual contract; introduce invalid/null values only at a boundary expected to validate them. Keep shape, component code, tokens, and rendering path unchanged.
  3. Feed fixtures through the real props/mock/API boundary. Mix long/short/Unicode data, missing optional fields, all valid statuses, and counts 0/1/many. Compare normal data, worst case, empty, one item, and the supported cardinality limit.
  4. Render in the real container plus the narrowest/widest supported layout, at 200% zoom, and in supported themes/directions. Exercise overflowed actions with keyboard/touch. Capture screenshots/state; when browser access is missing, label CSS inference.
  5. Report the value, visible failure, location, impact, proposed fix, and what held up. Identify genuine product choices (wrap/truncate, pagination/virtualization); preserve existing conventions rather than turning every edge into a redesign.
  6. For requested fixes, start with a failing public-contract regression, repair, then replay every affected fixture and normal data. Keep regression fixtures test/dev-only.

Failure handles

Check fixed-size flex siblings, min-width: 0/minmax(0, 1fr), unbreakable strings, multiline glyph clipping, grapheme-safe initials, locale/plurals, image fallback, and full-value access after truncation. Never hide numbers the user must compare.

Fixtures use reserved example domains and synthetic data. Never call real customers, render fixture HTML as executable markup, or mutate production records to make a test. Report-only requests stop at the report; no gratuitous persistent process or demo switch.

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.

Check your setup, free