Responsiveness Check
Sweep fixed viewport widths to catch layout breaks, overflow, and breakpoint transitions before you ship responsive UI.
Overview
responsiveness-check is an agent skill most often used in Build (also Ship testing, Launch distribution) that supplies standard and sweep viewport breakpoints so you can systematically find responsive layout failures.
Install
npx skills add https://github.com/jezweb/claude-skills --skill responsiveness-checkWhat is this skill?
- 8 standard breakpoints from 320px through 2560px with device context and typical failure modes
- 15 sweep breakpoints every 160px from 320 to 2560 for overlooked transition zones
- Maps widths to Tailwind breakpoints (sm, xl, 2xl) and common max-w container choices
- Calls out nav hamburger-to-full switch zones near 960px and sidebar appearance near 1120px
- Frames 320px as the hard mobile baseline—if it passes there, mobile is usually solid
- 8 standard breakpoints from 320px to 2560px
- 15 sweep breakpoints every 160px from 320px to 2560px
Adoption & trust: 1.1k installs on skills.sh; 841 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship pages that look fine on your laptop but break on small phones, tablet nav transitions, or ultra-wide monitors because you never tested a defined width ladder.
Who is it for?
Indie builders polishing marketing sites, dashboards, or storefronts who want a concrete width list for manual checks, screenshots, or browser automation.
Skip if: Native-only mobile apps without responsive web layouts, or teams that already enforce visual regression CI with their own device matrix and do not need a reference sheet.
When should I use this skill?
You need a defined list of viewport widths and transition zones to check responsive layouts, navigation switches, and max-width containment across devices.
What do I get? / Deliverables
You get a repeatable breakpoint checklist—8 standard plus 15 sweep widths—so layout reviews cover the zones where navigation, grids, and containers usually fail.
- Breakpoint test plan keyed to 8 standard and 15 sweep widths
- Notes on which transition zones (nav, sidebar, max-width) failed per viewport
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Responsive layout verification is canonically a Build frontend task because it exercises real CSS and component behavior while pages are still being composed. Frontend subphase holds breakpoint matrices and device-context tables that agents use while implementing layouts, nav transitions, and max-width containers.
Where it fits
Run the 8-width matrix while tightening a marketing hero and hamburger menu before merging the layout PR.
Use the 15 sweep breakpoints to catch overflow between 800px and 960px where nav patterns often flip.
Verify landing page CTAs and grids at 375px and 1440px before pushing paid traffic.
How it compares
Use as a width catalog for structured responsive QA instead of ad-hoc resizing to whatever window size your editor happens to be.
Common Questions / FAQ
Who is responsiveness-check for?
It is for solo frontend builders and agents implementing CSS layouts who need a shared breakpoint vocabulary for phones, tablets, laptops, and ultra-wide desktops.
When should I use responsiveness-check?
Use it while building UI components and pages, again in Ship testing before release, and when fixing Launch-ready landing pages where hero and nav behavior must hold from 320px to 2560px.
Is responsiveness-check safe to install?
The skill is reference documentation; confirm trust via the Security Audits panel on this Prism page before installing the parent claude-skills repository.
SKILL.md
READMESKILL.md - Responsiveness Check
# Breakpoints Reference ## Standard Breakpoints (8) | Width | Device Context | What Typically Breaks | |-------|---------------|----------------------| | 320px | Small phone (iPhone SE, Galaxy S) | Everything — if it works here, mobile is solid | | 375px | Standard phone (iPhone 14/15, Pixel) | Minor text overflow, touch target sizing | | 768px | Tablet portrait (iPad) | Navigation transition zone, sidebar visibility | | 1024px | Tablet landscape / small laptop | Grid column counts, content width constraints | | 1280px | Laptop (13-14") | Max-width containers, wide table layouts | | 1440px | Desktop (15-16") | Content centering, hero section proportions | | 1920px | Full HD monitor | Ultra-wide whitespace, content lost in space | | 2560px | 4K / ultra-wide | Maximum stretch — most sites need max-width containment | ## Sweep Breakpoints (15) Every 160px from 320 to 2560: | Width | Transition Zone | |-------|----------------| | 320px | Mobile baseline | | 480px | Large phone / small phablet | | 640px | Phablet — Tailwind `sm:` starts here | | 800px | Between tablet and desktop — often overlooked | | 960px | Common nav hamburger → full switch point | | 1120px | Sidebar appearance zone | | 1280px | Tailwind `xl:` — laptop standard | | 1440px | Common `max-w-7xl` container width | | 1600px | Wide desktop | | 1760px | Transition to ultra-wide | | 1920px | Full HD — Tailwind `2xl:` | | 2080px | Ultra-wide territory | | 2240px | Max-width containers should be capping by now | | 2400px | Extreme width — tests containment | | 2560px | 4K upper bound | ## Trouble Zones These width ranges are where responsive bugs hide: | Range | Why It Breaks | |-------|--------------| | **768–1024px** | Tablet no-man's land. Mobile layouts are too cramped, desktop layouts don't fit. Nav transitions happen here. Many sites have NO breakpoint between 768 and 1024. | | **1024–1280px** | Sidebar visibility zone. Content needs to decide: stack or side-by-side? Grid columns usually jump from 2 to 3 here. | | **1440–1920px** | Wide screen gap. Sites with `max-w-7xl` (1280px) containers leave massive margins. Hero sections and full-bleed elements need attention. | | **1920–2560px** | Ultra-wide. Text line lengths become unreadable without containment. Background images may not cover. Grid gaps look enormous. | ## Default Height Use **900px** viewport height for all tests. This matches a typical laptop/desktop viewport and provides a consistent baseline for above-fold comparisons. Only vary height if specifically testing vertical responsiveness (rare). ## Tailwind v4 Default Breakpoints For reference when diagnosing where CSS breakpoints are set: | Prefix | Min Width | |--------|-----------| | `sm:` | 640px | | `md:` | 768px | | `lg:` | 1024px | | `xl:` | 1280px | | `2xl:` | 1536px | # Responsiveness Report Template Use this structure when writing responsiveness check reports. ## Report Structure ```markdown # Responsiveness Check: [URL] **Date**: YYYY-MM-DD **Mode**: Standard / Sweep / Targeted (range) **Breakpoints tested**: [list widths] **Browser tool**: playwright-cli / Playwright MCP / Chrome MCP ## Summary | Width | Status | Issues | |-------|--------|--------| | 320px | Fail | 2 critical, 1 high | | 375px | Fail | 1 high | | 768px | Warn | 1 medium | | 1024px | Pass | — | | 1280px | Pass | — | | 1440px | Pass | — | | 1920px | Warn | 1 medium | | 2560px | Fail | 1 high | **Overall**: X issues across Y breakpoints. [1-sentence summary of the main finding.] ## Critical & High Issues ### [Issue title] — [Severity] **Width(s)**: 320px, 375px **Check**: Horizontal overflow [Description: what's happening, what element is affected] [Screenshot reference or inline image] **Fix suggestion**: [CSS/HTML fix if obvious] --- [Repeat for each critical/high issue] ## Transition Analysis | Transition | Observed At | Clean? | Notes | |-----------|-------------|--------|-------| | Nav: hamburger → full | ~960px | Yes | Smooth transition, no