responsive-qa

Use this Skill when you want to test a website or web app in a real browser at different screen widths, with touch emulation and a throttled Slow 3G connection, then find and fix layout, tap-target, or load-speed problems one small step at a time, keeping a before and after screenshot for every fix. Ask which pages matter most if that is not already clear; good defaults are the pages a stranger would land on, such as the public product page, sign-up, login, password reset, and anything shared by a link. The qualified X post is a short in-thread quote that says "Here is the skill" and links to the GitHub repository at https://github.com/mkmaker/responsive-qa. First-person testing context is in the same-author parent post (2120887574113997219), which is indexed for context and URLs only and is not a second qualified card.

You need a website or local web app to test, and a repository the agent can work in on a branch or git worktree rather than on the main branch. The scripts need Node and Puppeteer: they are copied from this Skill into a scratch folder and run from there. If Puppeteer is missing, the Skill tells the agent to install it in that scratch folder, or to point NODE_PATH at a node_modules that already has it. To use an already installed Chrome instead of Puppeteer's own, set CHROME_PATH. Testing is done in a real browser, not only in a device toolbar. Screenshots, the qa-reports folder, and the written report are outputs, not materials you must already have. Public pages do not require a login; pages behind a login stay untested unless you set up access.

Work on a branch or git worktree, not on the main branch. Start the project's dev server and note its address. Ask which pages matter most if the user has not said. Open a real browser and test at the Skill's listed widths: 280, 320, 375, 430, 560, 600, 768, 820, 1024, 1440, and 1920, plus 667x375 and 932x430 for a sideways phone and 1280x480 for a short window. Widths under 1024 run with mobile and touch flags and an iPhone user agent. Use Slow 3G when checking load. Measure in the browser; do not trust the stylesheet alone. For each problem, say what you found, take a before screenshot, make one small edit, verify the result in the browser yourself, take an after screenshot, commit source files only with a plain sentence message, then move on. Never call a fix done only because the code looks right. Keep screenshots and a side-by-side before-after page under qa-reports/, and keep that folder out of git. Write reports in plain everyday English about what a visitor sees. When asked to run for a long time, keep testing new pages, widths, error states, open dropdowns, and sideways or short windows until several rounds in a row find nothing new. Ask before a change that is a design choice; fix clear bugs. Finish with a plain-language report of what was tested, what was fixed, what was found but not fixed, and what was not tested. Offer a second opinion on the full diff and verify each finding in the browser. Only when the user asks to ship, merge the main branch in, rebuild if needed, re-check the main pages, and hand over. Do not push unless asked. Never run a formatter, and only touch what the fix needs.

This Skill tests and fixes pages in a real browser; it is not a substitute for a full design system, and a fix is not done until it has been checked in the browser. Work happens one small fix at a time, on a branch or worktree rather than on the main branch, with a before and after screenshot for every fix. Never push unless the user asks, never run a formatter, and only touch what the fix needs. Do not create accounts or sign in as real users: pages behind a login stay untested unless the user sets up access. Ask before a change that is a design choice. The qa-reports folder, including screenshots and the written report, is kept out of git and is an output, not a prerequisite. The pinned SKILL.md does not state rules about API keys, telemetry, or sending user data off the machine beyond those login, access, and local-report boundaries; no further privacy rule is invented. The pinned LICENSE is MIT, Copyright (c) 2026 mkmaker, with notice retention and no warranty; the attached root README's Licence section also says MIT, which is consistent with the LICENSE file and is not a restriction conflict. The main post does not state a license. The default-branch HEAD at draft time equals the exact-path last commit on SKILL.md (bca98b00896a6c2195c58cb46693a6da5f513d36, 2026-11-13 14:02:58 Asia/Shanghai, "Add the responsive-qa skill"). The SKILL.md bytes still match the discovery snapshot; the draft is bound to that HEAD. GitHub login mkmaker differs from the posting handle themkmaker; the public mapping twitter_username=themkmaker and exact-path contribution by mkmaker are recorded. The repository owner is the personal GitHub user mkmaker, not an organization, so organization-member rules do not apply. The qualified post's entities.urls contain https://t.co/yf1XI7mYt3, expanded to https://github.com/mkmaker/responsive-qa, and https://t.co/XawMuOUnFC, expanded to the parent post; both are indexed as returned, and there is no note_tweet. The parent post (2120887574113997219) is same-author first-person context about overnight testing with Fable 5.2 and "20 fixes"; it is not a second qualified card, its entities.urls were empty in this fetch, and that author claim is not treated as a verified end-user case of this Skill. Media was not visually inspected. The interface reports reply_count=1; that reply was not fetched or drafted as a card. Examples stay empty. Documented Puppeteer, npm, and shot.cjs commands were not executed. Local historical search found no prior community drafts for this repository, so prior-community-post-same-repo-different-skill was not applied, and named-subskill-in-multi-skill-repo was not invented; current official SKILL.md and template text do not formally define those strings.