break

Renders one UI component under hostile content scenarios and reports visible breaks.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/falentio/cimi --skill break-falentio
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: break
Source: https://github.com/falentio/cimi/tree/main/.agents/skills/break
Command: npx skills add https://github.com/falentio/cimi --skill break-falentio

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 code review misses. This Skill stress-tests a single component by rendering it under every scenario that can actually reach it, producing a visual report 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 curated scenario catalog. - Harness Page Generation: Builds one throwaway page that imports the real component untouched and renders it once per scenario in a single column with labels, using the app's own layout, fonts, and tokens. - Findings Report: Marks each visible break on the page and reports a table mapping broken scenarios to the domain skill that owns the fix, such as better-typography or better-layout. - Use Case: Before shipping a new profile form input, render it with empty strings, 60-character unbreakable URLs, RTL text, and a 320px container to catch overflow and truncation issues in minutes. ## Quick Start Ask the assistant to run the break skill on a specific component, for example: stress test the UserCard component and show me every state where it 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 React component with edge-case content?

Render the real component on a throwaway page once per scenario, feeding hostile fixture props like empty strings, unbreakable long words, and zero items. Use fixed-width containers for width cases so one page load shows every scenario side by side.

What scenarios should I test before shipping a UI 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.

Why do my fixture props render empty in a Next.js harness page?

Fixture props can silently vanish crossing the server-client boundary into an interactive component. Mark the harness page itself as client code with "use client" so the fixtures reach the component.

Should I simulate dark mode or resize the viewport when testing components?

No. Simulating themes or resizing per scenario observes a different component than production. Render width cases in fixed containers on one page, and name environment modes like dark mode in the report for the user to toggle.

When should I use visual stress testing instead of code review?

Use visual stress testing to confirm what visibly breaks on a rendered page, since predicted failures are not findings. Use code review skills like interface-review when judging code against standards rather than observing rendered output.