菜单
Use when validating frontend behavior in a real browser, including functional flows, visual quality, accessibility, responsive behavior, perceived performance, or adversarial edge cases.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a request will produce frontend UI, a visual asset, an image prompt, or a video prompt, AND the intent/style is not already fully specified by the user or an existing design system in the repo. Forces a minimal, checkable design-context object to exist before generation so output does not default to generic/templated. Do NOT use for: single-property edits (color, spacing, copy tweak) with no ambiguity; bug fixes; refactors; or when the user already gave complete visual specs and you only need to execute. For those, just do the work.
Root orchestrator. Reads durable state, routes to one phase, dispatches fresh workers.
Pre-implementation alignment gate. Checks spec / plan / tasks consistency and plan vs codebase reality before code is written.
Define the goal: what problem we solve, for whom, and what success looks like. The directional anchor that architecture and specs must serve.
RED-GREEN-REFACTOR implementation per task. Each task passes before next. Produces handoff.md with reproducible evidence.
Design architecture: components, API schema, DB model, impact analysis, test strategy.
| name | frontend-qa |
| description | Use when validating frontend behavior in a real browser, including functional flows, visual quality, accessibility, responsive behavior, perceived performance, or adversarial edge cases. |
Frontend QA validates what users actually experience in the browser across seven independent layers. This is a self-contained skill — its framework is defined inline, not inherited from a shared QA core.
Signoff lens: Utility × Usability × Craft — does the feature solve the right job, stay understandable under real interaction, and feel intentional rather than merely unbroken?
Execute passes in order. Each layer builds on the previous. Record findings per layer before moving to the next.
Validate pixel-level fidelity against the design source (Figma, design system, or reference screenshots).
[See references/playbook.md#visual-qa for detailed procedure]
Validate that every interactive element behaves correctly across all states and transitions.
[See references/playbook.md#interaction-qa for detailed procedure]
Validate that the implementation faithfully uses the design system — not ad-hoc styling.
z-index: 9999)[See references/playbook.md#design-system-qa for detailed procedure]
Validate that the feature is usable by everyone, including assistive technology users.
alt=""prefers-reduced-motion — all animations disabled when OS setting is onprefers-color-scheme — dark mode respects system preference[See references/playbook.md#accessibility-qa for detailed procedure]
Validate behavior across all target viewports and devices.
[See references/playbook.md#responsive-qa for detailed procedure]
Validate behavior with real-world, messy content — not just ideal design data.
[See references/playbook.md#content-qa for detailed procedure]
Validate that the feature feels fast and smooth — measured, not guessed.
font-display: swap, no invisible text during loadsrcset, lazy loading[See references/playbook.md#performance-qa for detailed procedure]
Use three severity levels for all findings:
| Severity | Definition | Examples |
|---|---|---|
| Blocker | Release-stopping. Core journey broken or safety-critical failure. | Critical flow cannot complete; user data lost; UI unusable on required device/accessibility path |
| Major | High user impact with real cost, but not total release stop. | Confusing state in primary workflow; responsive breakage hiding important controls; severe accessibility regression |
| Minor | Real defect with limited blast radius or low urgency. | Non-critical visual inconsistency; secondary-state polish issue; copy/spacing problem not blocking comprehension |
Before any pass execution, build an inventory covering:
Every QA execution produces:
| Trap | Consequence | Prevention |
|---|---|---|
| Testing only the homepage | Inner pages, error pages, empty states are uncontrolled | Build a page matrix; test at least one instance of every template |
| Testing only in Chrome | Safari/Firefox rendering differences in backdrop-filter, border-radius, font line-height | Test in Safari (WebKit) and Firefox (Gecko) minimum |
| Ignoring loading states | Users see white screen for 3s, assume site is broken | Test skeleton screens, loading spinners, progressive loading |
| Testing only the "ideal" screen | Admin sees perfect data; real users see chaos | Test with different roles, permissions, data states |
| Not back-syncing design files | Design files and code permanently diverge | After QA signoff, update Figma tokens to match code reality (reverse sync) |
| Calling a feature "passed" because code looks correct | Code is not behavior | Verify in browser, not in source |
| Counting one happy-path run as signoff | Most failures live in non-happy-path states | Minimum 10-state coverage: default, loading, empty, populated, success, error, partial, dense, disabled, unauthorized |
Before signoff, touch as many of these states as the feature supports:
| Purpose | Tools |
|---|---|
| Pixel comparison | PerfectPixel (Chrome), Figma Dev Mode |
| Color / contrast | Stark, Colour Contrast Analyser, APCA calculator |
| Accessibility | axe DevTools, WAVE, Lighthouse, macOS VoiceOver, Windows NVDA |
| Animation | DevTools Animations panel, Motion DevTools |
| Responsive | DevTools Device Mode, BrowserStack, real devices (iPhone + Android) |
| Performance | Lighthouse, WebPageTest, GTmetrix |
| Hardcoded values | grep for #, rgb(, hsl( in source |