This skill takes one component, renders it on a fresh page under every scenario that can actually reach it and reports what broke. A component built against one happy path looks finished right up until real content arrives.

It observes rather than judges. A finding here is something that visibly broke on the page, named in the vocabulary of the domain skill that owns the fix. Reviewing code against a standard is and ; exploring design alternatives is .

Where insists on the real page, this skill isolates on purpose. You are not judging how the component looks in context. You are checking whether it defends itself when the content is worst-case.

One component per run. "The settings page" is not a component; the profile form's text input is. Where the request spans several, list the candidates and ask which one to test, rather than picking on the user's behalf.

Restate what the component is in one sentence: what it accepts, what it renders and where it will live.

Stress only what varies. A scenario earns a slot when the component accepts something that can take that shape in production. So read the component first: its props, its slots, its states and the data it renders.

scenarios.md holds the axes, the values on each and the cue that says whether an axis applies. Walk it against the component and keep only the axes whose cue matches. A text input gets content length and states, never item quantity. A static icon button with a fixed label gets container and environment, never long text.

Write the kept scenarios down before building, one line each, so the harness renders a planned set rather than whatever came to mind. Then say which axes you dropped and why, in one line, so a wrong inference is cheap to catch.

One throwaway page, holding the real component imported from the project, rendered once per scenario in a single column. Label every instance with its scenario name, and give the harness a dashed outline around each instance so overflow past the component's own box is visible.

Use the project's own stack: a scratch route in its dev server where one exists, a single self-contained HTML file where none does. Feed scenarios as props and fixture data. The harness never imports production state, never wires to live data and production never imports from the harness.

Keep the harness visibly outside the design system, plain and unstyled, so nothing it adds is mistaken for the component's own rendering.

A run that never rendered is a code review wearing a costume. Load the page, look at every scenario and record only what you saw. Reading the CSS and predicting "this would probably overflow" is not a finding.

With a scriptable browser, screenshot the page, resize to 320px and screenshot again, and tab through the interactive scenarios. Without one, start the dev server or write the file, then ask the user to open it and continue from what they report.

For each scenario record one of two outcomes: survived, or broke with what was visible. "Text escapes the card's right edge", never "spacing feels tight".

Report findings as a table, broken scenarios first:

better-typography

better-writing

The owner column names the domain skill whose rules diagnose the break, so the fix starts in the right place. This skill owns no domain rules and issues no verdict.

"Everything survived" is a complete and useful report. Say which scenarios ran and at which widths, and end there rather than padding the result with preferences.

Do not fix anything unasked. On a request to fix, follow the owner skill's rules, then re-render the failing scenarios to confirm.

The harness is the instrument, not the deliverable. Once the report is delivered, delete the page and its fixtures unless asked to keep them.