break

Renders a component under hostile content scenarios and reports visible breaks.

6.7k|239|Updated Jul 10, 2026
One-click install
npx skills add https://github.com/jakubkrehel/skills --skill break-jakubkrehel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: break
Source: https://github.com/jakubkrehel/skills/tree/main/skills/break
Command: npx skills add https://github.com/jakubkrehel/skills --skill break-jakubkrehel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Components built against one happy path look finished until real content arrives: long strings, empty states, narrow containers, and error states expose breaks that normal development never shows. This Skill stress tests a single component by rendering it in every realistic scenario on one temporary page. ## Core Features & Use Cases - Scenario Inference: Reads the component's props, slots, and states, then selects only the applicable stress axes (content length, content shape, quantity, container width, state, environment) from a defined scenario catalog. - Harness Page Generation: Builds a throwaway page that imports the real component untouched, rendering one instance per scenario in fixed-width containers with labels. - Visual Break Reporting: Produces a findings table of observed breaks, each assigned to the owning domain skill (better-typography, better-layout, better-accessibility, and others) so fixes start in the right place. - Use Case: Before shipping a new profile form input, render it with empty strings, 60-character unbreakable URLs, RTL text, zero items, and a 320px container to catch overflow and missing empty states in one page load. ## Quick Start Ask the agent to run the break skill on a specific component, for example: stress test the UserCard component against worst-case content and show me what breaks.

Frequently Asked Questions about break

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I stress test a UI component with edge case content?▼

Render the component once per scenario on a single throwaway page, feeding hostile inputs as props: empty strings, unbreakable long words, RTL text, zero items, and narrow fixed-width containers. Load the page once and note what visibly broke under each label.

What scenarios should I test when breaking a component?▼

Test only axes whose cue matches the component: content length and shape for components rendering external text, quantity for repeating lists, container widths for everything, and states only for states the component accepts as props. Drop non-matching axes and say why.

Does this work with Next.js server and client components?▼

Yes, but the harness page itself must be client code with the "use client" directive in Next.js. Fixture props can silently vanish crossing the server-client boundary into an interactive component, leaving every scenario rendering empty.

Why do my test scenarios render empty in the harness page?▼

Empty scenarios usually mean the harness is broken, not the component. The most common cause is fixture props failing to cross the server-client boundary, so make the page client code and re-check that props actually arrive.

When should I use stress testing instead of a full interface review?▼

Use stress testing to check whether one component defends itself against worst-case content in isolation. Use a full interface review when judging code against design standards across UI, typography, layout, color, and accessibility categories.