responsiveness-check
Test website responsiveness across viewport widths using browser automation. Resizes a single session through breakpoints, screenshots each width, and detects layout transitions (column changes, nav switches, overflow). Produces comparison reports showing exactly where layouts break. Trigger with 'responsiveness check', 'check responsive', 'breakpoint test', 'viewport test', 'responsive sweep', 'check breakpoints', or 'test at mobile'.
- Installs
- 1.8K
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/jezweb/claude-skills --skill responsiveness-check- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads responsiveness-check automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Responsiveness Check
Test how a website's layout responds to viewport width changes. Resizes through breakpoints in a single browser session, screenshots each width, compares adjacent sizes, and reports where layouts break.
What this tests: Layout responsiveness — overflow, stacking, navigation transitions, content reflow.
What this does NOT test: General accessibility (ARIA, semantic HTML, heading hierarchy, colour contrast). Those don't vary by viewport width — use the ux-audit skill instead.
Browser Tool Priority
Before starting, detect available browser tools:
- playwright-cli (preferred) — supports resize, named sessions, and sub-agent parallelism. If installed, run
/playwright-clifirst to load the full command reference. - Playwright MCP (
mcp__plugin_playwright_playwright__*) —browser_resizefor viewport changes. - Chrome MCP (
mcp__claude-in-chrome__*) —resize_windowfor viewport changes. Uses the user's logged-in Chrome session.
If none are available, inform the user and suggest installing playwright-cli or Playwright MCP.
Operating Modes
Mode 1: Standard Check
When: "check responsive", "responsiveness check", "test breakpoints"
Test 8 key breakpoints that cover the device spectrum:
| Width | Device Context |
|---|---|
| 320px | Small phone (iPhone SE) |
| 375px | Standard phone (iPhone 14) |
| 768px | Tablet portrait (iPad) |
| 1024px | Tablet landscape / small laptop |
| 1280px | Laptop |
| 1440px | Desktop |
| 1920px | Full HD |
| 2560px | Ultra-wide / 4K |
Process:
- Open the URL in a single browser session (height: 900px)
- Start at 320px. For each breakpoint width: a. Resize the viewport b. Wait briefly for CSS reflow (layout transition) c. Screenshot the above-fold area d. If the page has significant below-fold content, scroll and screenshot e. Run the 8 layout checks (see matrix below) f. Note any issues with severity
- Compare adjacent widths — identify where layout transitions occur
- Write the report
Mode 2: Sweep
When: "responsive sweep", "sweep all breakpoints", "find where it breaks"
Test every 160px from 320 to 2560 (15 widths total). Same single-session approach as Standard — just more data points. This is the mode for finding the exact width where a layout breaks.
Widths: 320, 480, 640, 800, 960, 1120, 1280, 1440, 1600, 1760, 1920, 2080, 2240, 2400, 2560
Briefly confirm before starting sweep mode (15 screenshots is a meaningful session).
Mode 3: Targeted Range
When: "check between 768 and 1024", "test tablet breakpoints", "focus on mobile widths"
Test a user-specified range at 80px increments. Use when a known trouble zone needs detailed investigation.
Example: "check between 768 and 1024" tests: 768, 848, 928, 1008 (plus 1024 as endpoint).
Multi-URL
When testing multiple URLs (e.g., "check the homepage, about page, and contact page"):
- Launch parallel sub-agents, one per URL (not per breakpoint)
- Each sub-agent runs a standard check on its URL in its own named session
- Combine results into a single report
# Sub-agent pattern (playwright-cli)
playwright-cli -s=page1 open https://example.com/ &
playwright-cli -s=page2 open https://example.com/about &
Layout Check Matrix
These 8 checks target issues that actually vary by viewport width:
| # | Check | What to Look For |
|---|---|---|
| 1 | Horizontal overflow | Content wider than viewport — horizontal scrollbar appears, elements cut off |
| 2 | Text overflow | Text truncated mid-word, overlapping adjacent elements, font size unreadable (< 12px) |
| 3 | Navigation transition | Hamburger menu appears/disappears at correct width, no "broken" state between modes |
| 4 | Content stacking | Multi-column layouts stack to single column in logical reading order on narrow widths |
| 5 | Image/media scaling | Images overflow container, distorted aspect ratios, missing responsive sizing |
| 6 | Touch targets | Interactive elements < 44px on mobile widths (< 768px) — buttons, links, form inputs |
| 7 | Whitespace balance | Too cramped on mobile (no breathing room), too sparse on wide screens (content lost in space) |
| 8 | CTA visibility | Primary call-to-action visible above the fold at each width without scrolling |
Transition Detection
The unique value of this skill is finding where layout transitions happen and whether they're clean.
When comparing screenshots at adjacent widths, flag any width where:
- Column count changes (3-col → 2-col → 1-col grid)
- Navigation mode switches (full nav → hamburger, or vice versa)
- Sidebar appears/disappears (content width jumps)
- Grid reflows (cards wrap to next row)
Report the exact width range where each transition occurs:
| Transition | From | To | Width Range |
|---|---|---|---|
| Nav: hamburger → full | 768px | 1024px | Switches at ~960px |
| Grid: 1-col → 2-col | 640px | 768px | Reflows at ~700px |
| Sidebar appears | 1024px | 1280px | Shows at ~1100px |
This tells the developer exactly where to set (or fix) their CSS breakpoints.
Severity Levels
Consistent with ux-audit:
| Severity | Meaning |
|---|---|
| Critical | Layout is broken — content unreadable, navigation inaccessible, page unusable |
| High | Significant layout issue — major overflow, key content hidden, broken transition |
| Medium | Noticeable but usable — awkward spacing, minor overflow, suboptimal stacking order |
| Low | Polish — whitespace tweaks, slight alignment issues, minor touch target shortfalls |
Autonomy Rules
- Just do it: Resize viewport, take screenshots, analyse layout, compare widths
- Brief confirmation: Before sweep mode (15 viewports), before testing 4+ URLs in parallel
- Ask first: Before interacting with forms or clicking through authentication flows
Report Output
Write report to docs/responsiveness-check-YYYY-MM-DD.md (or inline for single-page quick checks).
See references/report-template.md for the report structure.
Reference Files
| When | Read |
|---|---|
| Looking up breakpoint details and trouble zones | references/breakpoints.md |
| Writing the responsiveness report | references/report-template.md |
FAQ
What does the responsiveness-check skill do?
Test website responsiveness across viewport widths using browser automation. Resizes a single session through breakpoints, screenshots each width, and detects layout transitions (column changes, nav switches, overflow). Produces comparison reports showing exactly where layouts break. Trigger with 'responsiveness check', 'check responsive', 'breakpoint test', 'viewport test', 'responsive sweep', 'check breakpoints', or 'test at mobile'.
How do I install responsiveness-check?
Run npx skills add https://github.com/jezweb/claude-skills --skill responsiveness-check in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/responsiveness-check/ (personal) or .claude/skills/responsiveness-check/ (project).
Which AI agents can use responsiveness-check?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is responsiveness-check safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains responsiveness-check?
It is published by jezweb in jezweb/claude-skills. It has 1,793 recorded installs.
More from jezweb/claude-skills
shadcn-ui
jezweb/claude-skills
Install and configure shadcn/ui components for React projects. Guides component selection, installation order, dependency management, customisation with semantic tokens, and common UI recipes (forms, data tables, navigation, modals). Use after tailwind-theme-builder has set up the theme infrastructure, when adding components, building forms, creating data tables, or setting up navigation.
color-palette
jezweb/claude-skills
Generate complete, accessible colour palettes from a single brand hex. Produces 11-shade scale (50-950), semantic tokens, dark mode variants, Tailwind v4 CSS output, WCAG contrast checks. Use whenever the user supplies a brand hex and asks for a palette, mentions setting up a design system, wants Tailwind theme colours from a brand colour, or asks to check colour accessibility / contrast.
tailwind-theme-builder
jezweb/claude-skills
Set up Tailwind v4 + shadcn/ui themed UI with dark mode. Install deps, configure CSS variables via @theme inline, wire dark mode toggle, verify. Use whenever the user mentions Tailwind v4, setting up Tailwind theming, shadcn/ui colours, dark mode, or troubleshooting colours not working, tw-animate-css errors, @theme inline conflicts, @apply breaking after upgrade, or v3 → v4 migration issues.
wordpress-elementor
jezweb/claude-skills
Edit Elementor pages and manage templates on WordPress sites via browser automation (for visual / structural changes) or WP-CLI (for safe text replacements). Use whenever the user wants to edit an Elementor page, update text in Elementor widgets, apply or manage Elementor templates, or make content changes to pages built with the Elementor page builder.
ux-audit
jezweb/claude-skills
Walk through a live web app AS a real user to find usability + behavioural bugs that static reviews miss. REQUIRES proof of interaction (typing, clicking, sending, observing) before any verdict — a sweep that didn't interact terminates with verdict 'Incomplete'. Walks threads, exercises every element, runs the multi-pane stress matrix, visual polish sweep, component perfection checklist, automated a11y (axe-core), pragmatic performance budget (LCP/CLS/INP), scenario battery (11 scenarios), and stress recipes including the real-flavour data battery. Hard gates: console errors/warnings = 0, network 5xx = 0, layout collapse = 0, axe Critical/Serious = 0, perf budget green. Audit-the-audit meta-check rejects rushed reports. Each finding has reproduction steps, evidence path, and suspected code location. Trigger with 'ux audit', 'walkthrough', 'qa sweep', 'audit the app', 'dogfood this', 'check all pages', 'find what's broken', 'stress the UI'.
tailwind-v4-shadcn
jezweb/claude-skills
Set up Tailwind v4 with shadcn/ui using @theme inline pattern and CSS variable architecture. Four-step pattern: CSS variables, Tailwind mapping, base styles, automatic dark mode. Prevents 8 documented errors. Use when initializing React projects with Tailwind v4, or fixing colors not working, tw-animate-css errors, @theme inline dark mode conflicts, @apply breaking, v3 migration issues.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work