← ClaudeAtlas

design-qalisted

Internal prototype QA helper. Use only after a Product Design prototype, URL-to-code build, or image-to-code build has a source visual target and a rendered implementation to compare before handoff. Do not use for broad UX critique, design critique, product audits, or flow reviews; route those user-facing requests to audit.
Oatelauser/ai-front-spec · ★ 0 · Web & Frontend · score 64
Install: claude install-skill Oatelauser/ai-front-spec
# Design QA Use this internal helper to compare a prototype's source design against the rendered implementation before handoff. Do not use this skill for broad UX critique, design critique, product audits, or flow reviews. Use [audit](../audit/SKILL.md) for those user-facing requests. Use this skill before every Product Design build handoff. A passing QA run requires both: - a source visual target: Figma node, image, screenshot, mockup, or source capture - a rendered implementation: local URL, deployed URL, app screen, component, or screenshot If either artifact cannot be opened, captured, or compared, write `design-qa.md` with `final result: blocked` and name the blocker. Do not let the build skill hand off as done. ## Critical Overrides Follow [critical-overrides](../../references/critical-overrides.md). ## Workflow Compare the intended design to the implementation as a product-quality reviewer, not as a generic aesthetic critic. The output must be a prioritized fix list grounded in evidence from both artifacts. Do not write the QA review from memory, code, or file paths alone. Open or capture both the source design and the implementation first, then compare what is actually visible. Do not pretend separate image views are side-by-side comparison. Put the source image and the implementation screenshot together in the same comparison input, then judge the visible differences from that combined input. Design QA is an iteration loop. The first comparison may pass