Skip to the usage guide
Design QA Checklistby owl-listener

Design QA Checklist Skill.

Turn a design specification into implementation checks.

  • Design QA
  • Handoff
Source Review · design-qa-checklistSKILL.md
Task Turn a design specification into implementation checks. Produces A scoped checklist derived from the design specification. Before You Start A checklist needs a design reference; a vague intention cannot establish exact matching.
Editorial summary · source reviewed 2026-11-02 · not a generated example

01 What It Does

Turn a design specification into implementation checks

Create a design QA checklist covering visual accuracy, layout, interactions, content, accessibility and required platforms.

Source-based workflowNot an execution benchmark

The Working Approach

Design QA Checklist helps a team verify that a built interface matches its specification. It covers visual values, responsive layout, component states, real content, accessibility and platform requirements. The reference point is the actual design spec, so the checklist can identify mismatches more precisely than a review based on memory.

The source describes a review sequence from developer self-check to designer QA, screenshot-backed bug reports and fix verification. Generating a checklist prepares that process; executing it still requires access to the running interface, target devices and the relevant assistive checks.

Expected Deliverables

  • A scoped checklist derived from the design specification.
  • Checks for relevant visual, responsive, interaction and content states.
  • A bug-reporting and retest structure for implementation mismatches.
See the Example Brief

From Brief to Review

  1. 01
    Read the expected design

    Gather the specification, tokens and required platforms. Translate the requirements into checks that describe what the reviewer should observe.

  2. 02
    Cover states and edge cases

    Include hover, focus, active, disabled, loading, empty and error cases where applicable. Use real content and check truncation, overflow and reflow.

  3. 03
    Review the implementation

    Start with developer self-review, followed by designer inspection. Use browser tools for exact values and screenshots for meaningful design-versus-build comparisons.

  4. 04
    Prioritize and retest

    File discrepancies by severity and verify corrections. Record recurring issue types so later reviews can catch them earlier.

02 When to Use It

When to Use It

A checklist needs a design reference; a vague intention cannot establish exact matching.

A Good Fit

  • Implementation handoffA feature is built and needs a concrete design-acceptance pass.
  • Repeatable team QADevelopers and designers need the same expectations for states and visual details.

Limits to Check

  • Specification dependencyA checklist needs a design reference; a vague intention cannot establish exact matching.
  • Execution still requiredA written checklist does not prove that browsers, devices or screen readers were tested.
  • Different deliverableThe source directs engineering handoff specifications to the handoff-spec skill.

Bring These Inputs

  • Design specificationProvide layouts, tokens and expected component behavior.
  • Running buildIdentify the implementation and the states reviewers can reach.
  • Platform matrixState required browsers, devices, text sizes and accessibility conditions.

03 Decisions That Matter

Decisions That Matter

  1. Shared expectations

    Developers and designers inspect against one defined reference.

  2. State coverage

    Errors and empty states remain part of acceptance, alongside the default view.

  3. Retest discipline

    Reported fixes are checked again before the issue is considered resolved.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Source and Setup

Provide layouts, tokens and expected component behavior.

Upstream Source File
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md

The reference below opens the upstream instructions. Review the repository setup before using them; it is not an installation command.

Start With One Deliverable

Adapt the scope, source material and constraints in this brief before running the skill.

Example Brief
Use design-qa-checklist for the new invoice screen. Read its design spec and token definitions, then create checks for desktop and mobile layouts, empty results, loading, validation errors and disabled actions. Include keyboard order, visible focus, text enlargement and reduced-motion behavior where relevant. Use the real sample invoices rather than placeholder copy. Separate checklist preparation from executed tests. For any implementation mismatch we observe, record the expected behavior, actual behavior, screenshot evidence and severity, then leave an explicit retest item for the fix.

Inspect the Result

Check the actual output against these observable criteria.

  • Checklist items point to a specification or stated product requirement.
  • Executed checks and untested conditions are clearly separated.
  • Resolved bugs include verification of the corrected state.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner
owl-listener
Skill File
SKILL.md
License
MIT
Reviewed Snapshot
2026-11-02 · 9a6930cf84a8
Editorial Source Summary
Turn a design specification into implementation checks.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Is this only a visual checklist?

No. It includes interaction, content, accessibility and cross-platform checks.

Can a screenshot establish keyboard behavior?

Keyboard and focus checks require interaction with the build; screenshots support the visual comparison.

What content should QA use?

The source recommends real content and edge cases rather than relying only on happy paths or placeholder text.

OpenDesign

Keep Your Brief and Design Work Together.

Keep your brief, source material and design work together in a local workspace. Check the skill’s own setup before adding it to your workflow.

Upstream Source File
https://github.com/owl-listener/designer-skills/blob/9a6930cf84a822eb458624bd11c61aac5bbdf224/design-ops/skills/design-qa-checklist/SKILL.md