24 October 2026 · Frontend skill choice · Source check, no output test
Before you install a frontend skill, define the job
One screen or small fix? Give the agent your route, existing components and tokens, real copy, required states, target widths, and acceptance checks. Inspect the rendered result. Try a skill when you need a repeated procedure or a specialized workflow—not because the project uses React.
| Job | Start with | When a skill may help |
|---|---|---|
| Fix one existing screen | A bounded brief and the current design system. | The same review or implementation steps recur across screens. |
| Make a new visual direction | Product purpose, audience, real copy, and a reference or explicit visual choices. | You need a repeatable direction-setting and rendered-feedback workflow. |
| Verify an interaction | The route, expected behavior, states, and browser checks. | A browser skill helps capture repeatable evidence; it does not judge the design for you. |
Skills CLI README also documents a one-session skills use route without installation. We did not run the CLI.
In one generic-interface question draws both brief-and-reference advice and skill suggestions. Those discussions show live choices, not which route produces a better screen.
A brief you can reuse
“Change [route/component] for [user task]. Use [existing tokens/components]. Keep [real content and constraints]. Cover [default, loading, empty, error, focus states]. Check [target widths] and [named functional checks]. Show the rendered result and identify what remains unverified.”
This is a decision starting point, not a claim that a brief beats a skill. No listed skill has a pool-run same-project comparison against a no-skill brief. For a consequential choice, hold the project, model, and brief fixed and compare the visible and working results separately.