responsiveness-check

Tests website layout responsiveness across viewport breakpoints using browser automation and screenshots.

1|Updated Aug 18, 2026
One-click install
npx skills add https://github.com/scsm-unrestrict/dsh-frontend-engineer-agent --skill responsiveness-check-scsm-unrestrict
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: responsiveness-check
Source: https://github.com/scsm-unrestrict/dsh-frontend-engineer-agent/tree/main/frontend-engineer/skills/responsiveness-check
Command: npx skills add https://github.com/scsm-unrestrict/dsh-frontend-engineer-agent --skill responsiveness-check-scsm-unrestrict

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Responsive layout bugs hide at specific viewport widths and are tedious to find manually. This Skill automates resizing a browser session through standard breakpoints, screenshots each width, and pinpoints exactly where layouts break — overflow, broken navigation transitions, bad stacking, and unreadable text. ## Core Features & Use Cases - Three testing modes: Standard check (8 key breakpoints from 320px to 2560px), Sweep mode (15 widths at 160px increments to find the exact breaking point), and Targeted Range mode for investigating known trouble zones like 768–1024px. - Transition detection: Compares adjacent widths to identify where column counts change, navigation switches between hamburger and full modes, and sidebars appear — reporting the exact width range of each transition. - Structured severity reports: Classifies findings as Critical/High/Medium/Low and writes a findings-first report to docs/responsiveness-check-YYYY-MM-DD.md with fix suggestions grouped by effort. - Use Case: Before shipping a landing page, ask for a responsiveness check; the Skill resizes through all breakpoints, catches that hero text overflows at 320px and the nav transition flickers near 960px, and delivers a report with CSS fix suggestions. ## Quick Start Run a responsiveness check on https://example.com across all standard breakpoints and report where the layout breaks.

Frequently Asked Questions about responsiveness-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test website responsiveness across breakpoints automatically?

Use browser automation to resize a single session through standard widths (320px to 2560px), screenshot each viewport, and run layout checks for overflow, stacking, and navigation transitions. The Skill compares adjacent widths to find exactly where layouts break.

What viewport widths should I test for responsive design?

Test 8 key breakpoints: 320, 375, 768, 1024, 1280, 1440, 1920, and 2560px. For finding exact breaking points, sweep every 160px from 320 to 2560. Trouble zones are typically 768–1024px (tablet) and 1440px+ (wide screens).

Which browser automation tools work for viewport resize testing?

playwright-cli is preferred for its resize support, named sessions, and sub-agent parallelism. Playwright MCP (browser_resize) and Chrome MCP (resize_window) also work, with Chrome MCP using your logged-in Chrome session.

Does responsiveness testing cover accessibility issues like contrast and ARIA?

No. Responsiveness testing only covers layout issues that vary by viewport width: overflow, stacking, navigation transitions, and touch targets. ARIA, semantic HTML, and color contrast do not vary by width and require a separate accessibility audit.

How do I find the exact width where my responsive layout breaks?

Use sweep mode, which tests every 160px from 320 to 2560 (15 widths). Comparing adjacent screenshots reveals the precise width range where column counts change, navigation switches modes, or grids reflow.