responsive-design

name	responsive-design
description	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 and system-wide breakpoint/token governance to `design-system`, and accessibility remediation plus broad UI audit work to `web-accessibility`.
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 or accessibility-heavy remediation as the primary owner.
license	MIT
metadata	{"tags":"responsive, mobile-first, layout, container-queries, breakpoints, frontend, css, reflow","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.1.0","source":"akillness/jeo-skills","modernization":"2026-04-13T00:00:00.000Z","hardening":"2026-04-19T00:00:00.000Z"}

Responsive Design

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:

1. classify the responsive failure first,
2. choose one primary responsive packet,
3. keep viewport vs container ownership explicit,
4. separate dense-data and media cases from generic layout advice,
5. keep reflow/verification visible,
6. route neighboring frontend work honestly.

Read these support docs first:

• references/intake-packets-and-route-outs.md
• references/layout-decision-checklist.md
• references/handoff-boundaries.md

When to use this skill

• 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 → design-system
• 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-accessibility
• The main task is React hydration, rerender churn, or client-boundary performance behavior → react-best-practices
• The responsive strategy is already clear and the job is just implementation; in that case implement directly instead of re-running the router