design-review-workflow

Runs one end-of-build design and QA pass with screenshot sweeps, on-device checks, and graded findings.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/zakariaf/NearlyStop --skill design-review-workflow-zakariaf
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-review-workflow
Source: https://github.com/zakariaf/NearlyStop/tree/main/.claude/skills/design-review-workflow
Command: npx skills add https://github.com/zakariaf/NearlyStop --skill design-review-workflow-zakariaf

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams either skip design QA entirely or block every build task on pixel critiques, and accessibility regressions slip into releases. This Skill enforces exactly one structured design review at the end of a build, on the release build, so visual and accessibility issues are caught once, graded, fixed in a single round, and formally signed off before release. ## Core Features & Use Cases - Screenshot sweep matrix: Captures every screen across light/dark themes, LTR/RTL directions, largest text scale, and reduce-motion states, with sortable per-cell file naming. - Graded findings rubric: Classifies every issue as BLOCKER, FIX, or NOTE, with any accessibility-floor violation (contrast, tap targets, text-scale reflow, RTL correctness) always graded BLOCKER. - On-device pass: Verifies behavior on real budget hardware with screen-reader traversal, migration and export/import data-safety rehearsal, and crash-log symbol checks. - Use Case: After finishing all build tasks for a Flutter feature with CI green, run the pass to produce a dated sign-off artifact that gates the release tag. ## Quick Start Run the design review pass on the release build now that all build tasks are done and CI is green, and produce the sign-off artifact.

Frequently Asked Questions about design-review-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a design review before releasing a mobile app?

Run one structured pass after the last build task is done and CI is green: a screenshot sweep of every screen across themes, directions, and text scales, plus an on-device pass on real hardware. Grade findings as BLOCKER, FIX, or NOTE, fix in one round, then write a dated sign-off artifact.

What should a mobile app QA screenshot matrix include?

The matrix covers every screen and meaningful state multiplied by light and dark themes and LTR and RTL directions, with the largest text scale applied to every still. Motion moments are captured as short videos with reduce-motion on and off, since skippability is only judgeable on video.

When should design review happen in the development workflow?

Design review happens exactly once per app or feature, at the very end, after the last build task is done and all CI gates and tests are green. Per-task visual critiques during the build are an anti-pattern; mid-build issues are noted and reviewed in the final pass.

Why test a release build on real cheap hardware instead of an emulator?

Emulators and flagships hide bugs the median user hits: audio and haptics behavior, real fonts, memory pressure on budget silicon, and real system settings like silent mode. The on-device pass also covers screen-reader traversal, migration rehearsal, and crash-log symbol checks that only manifest on physical devices.

What accessibility issues block a mobile app release?

Any accessibility-floor violation is a mandatory BLOCKER: insufficient contrast, undersized tap targets, text truncation at the largest scale, state conveyed by color alone, RTL rendering errors, and missing reduce-motion paths. Aesthetics never offset a floor violation, and a surviving BLOCKER means no sign-off.