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'.
npx skills add https://github.com/jezweb/claude-skills --skill 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.
Before starting, detect available browser tools:
/playwright-cli first to load the full command reference.mcp__plugin_playwright_playwright__*) — browser_resize for viewport changes.mcp__claude-in-chrome__*) — resize_window for 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.
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:
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
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).
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).
When testing multiple URLs (e.g., "check the homepage, about page, and contact page"):
# Sub-agent pattern (playwright-cli)
playwright-cli -s=page1 open https://example.com/ &
playwright-cli -s=page2 open https://example.com/about &
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 |
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:
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.
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 |
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.
| When | Read |
|------|------|
| Looking up breakpoint details and trouble zones | references/breakpoints.md |
| Writing the responsiveness report | references/report-template.md |
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use this skill to query your Google NotebookLM notebooks directly from Claude Code for source-grounded, citation-backed answers from Gemini. Browser automation, library management, persistent auth. Drastically reduced hallucinations through document-only responses.
Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.
Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include "automate Slack app", "control VS Code", "interact with Discord app", "test this Electron app", "connect to desktop app", or any task requiring automation of a native Electron application.
Use when the task requires automating a real browser from the terminal (navigation, form filling, snapshots, screenshots, data extraction, UI-flow debugging) via `playwright-cli` or the bundled wrapper script.
Use when the user explicitly asks for a desktop or system screenshot (full screen, specific app or window, or a pixel region), or when tool-specific capture capabilities are unavailable and an OS-level capture is needed.
A fast Rust-based headless browser automation CLI with Node.js fallback that enables AI agents to navigate, click, type, and snapshot pages via structured commands.
| 所有联网操作必须通过此 skill 处理,包括:搜索、网页抓取、登录后操作、动态页面交互等。 触发场景:用户要求搜索信息、查看网页内容、访问需要登录的网站、操作网页界面、抓取社交媒体内容(小红书、微博、推特等)、读取动态渲染页面、以及任何需要真实浏览器环境的网络任务。
Take jezweb/responsiveness-check from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.