design-qalisted

Runs a pre-ship design QA gate on a screenshot, URL, or PR HTML/CSS - checks states, WCAG 2.2 contrast, touch targets, breakpoints, and keyboard paths, then returns a pass/fail table and fix list. Trigger phrases - "QA this screen", "is this ready to ship", "check this PR for accessibility issues", "audit before launch". Skip for style critique - use design-review instead; this checks only verifiable gate criteria.
humbleteam/design-qa · ★ 0 · Web & Frontend · score 70

Install: claude install-skill humbleteam/design-qa

# Design QA Run every screen through a fixed six-category gate before it ships: component states, contrast, touch targets, responsive behavior, keyboard access, and copy conventions. Output is a pass/fail table, a severity-tagged fix list, and one verdict line. The gate is fail-closed - a category with no evidence in the input is reported as not verifiable, never marked as a silent pass. ## Step 1 - identify the input and mode The artifact arrives as one of: - **Screenshot(s)** pasted into chat. Static states only - see the coverage limits in Step 2. - **A URL.** If a browser or devtools tool is available, drive it: resize the viewport, tab through focus order, toggle hover/focus states. If no such tool is available, fetch the rendered HTML/CSS and read it statically. - **HTML/CSS** - a PR diff, a pasted snippet, or local files. Read the source directly; this is the richest input and the only one that makes every category fully verifiable. - **Design tokens**, if the user supplies a token file (CSS custom properties or JSON) alongside the artifact. Use these as the source of truth for spacing, size, and color checks instead of generic heuristics, and flag any value in the artifact that doesn't match a token as a deviation. If nothing artifact-shaped is in the message (no image, no URL, no code), ask one question: what screen, and how is it best inspected (screenshot, URL, or code)? Do not guess and do not run the gate against a description alone. If the