Routing-first responsive layout strategy and verification for web interfaces. Use when the main job is classifying whether the failure is page-shell adaptation, reusable component/container behavior, dense-data or toolbar pressure, responsive media, or reflow verification — then turning vague “breaks on mobile” requests into one concrete strategy packet. Route component API design to `ui-component-patterns`, accessibility remediation to `web-accessibility`, system-wide breakpoint/token governance to `design-system`, and broad UI audit work to `web-design-guidelines`.
Routing-first responsive layout strategy and verification for web interfaces. Use when the main job is classifying whether the failure is page-shell adaptation, reusable component/container behavior, dense-data or toolbar pressure, responsive media, or reflow verification — then turning vague “breaks on mobile” requests into one concrete strategy packet. Route component API design to `ui-component-patterns`, accessibility remediation to `web-accessibility`, system-wide breakpoint/token governance to `design-system`, and broad UI audit work to `web-design-guidelines`.
allowed-tools
Read Write Bash Grep Glob
compatibility
Best for frontend and fullstack web repos using CSS, utility frameworks, or component libraries where the main task is responsive layout strategy or verification. Not for reusable component API architecture, broad UI polish reviews, or accessibility-heavy remediation as the primary owner.
Use this skill when the job is to name the failing responsive surface, choose the smallest viable adaptation packet, and leave behind a short strategy + verification brief.
The job is not to dump generic CSS recipes, paste framework snippets, or absorb every neighboring frontend concern.
This skill should:
classify the responsive failure first,
choose one primary responsive packet,
keep viewport vs container ownership explicit,
separate dense-data and media cases from generic layout advice,
A team says “this page breaks on mobile” and the real responsive surface is still unclear.
A dashboard, nav, form, card grid, pricing page, table, or embed needs a responsive strategy before more breakpoints are added.
You need to decide whether the fix belongs in viewport layout rules, container queries, intrinsic layout, responsive media handling, or verification/reflow follow-up.
A launch-readiness pass uncovered overflow, wrapping, density, or zoom/reflow failures and someone needs one bounded packet instead of a CSS lecture.
The request mixes page-level adaptation, component reuse, and dense-data pressure and needs routing before implementation.
When not to use this skill
The main task is reusable primitive / slot / variant API design or component-family ownership → ui-component-patterns
The main task is keyboard/focus behavior, semantics, labels, contrast, reduced motion, or accessibility-heavy remediation → web-accessibility
The main task is breakpoint governance, token policy, or cross-product responsive standards → design-system
The main task is broad UI critique, polish, heuristic review, or launch-readiness audit across many dimensions → web-design-guidelines
The main task is React hydration, rerender churn, or client-boundary performance behavior → react-best-practices
; in that case implement directly instead of re-running the router
The responsive strategy is already clear and the job is just implementation
Instructions
Step 1: Frame the responsive job before naming CSS
Ownership — responsive-design, ui-component-patterns, web-accessibility, design-system, web-design-guidelines, or react-best-practices
If the request starts from a screenshot, QA note, or “mobile is broken” report, say explicitly that the screenshot is the signal artifact, not the finished responsive strategy.
Step 7: Route adjacent work explicitly
Use these route-outs when the problem crosses boundaries:
