Design Review Process
Define four design-review gates (concept through implementation QA) with checklists and sign-off so solo builders ship UI that matches spec without skipping accessibility or edge cases.
Overview
Design Review Process is an agent skill most often used in Ship (also Validate, Build) that establishes four gated design reviews with criteria, checklists, and approval workflows from concept through implementation QA.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill design-review-processWhat is this skill?
- Four named gates: Concept Review, Design Review, Pre-Handoff Review, Implementation QA
- Checklist criteria: user problem, design system consistency, WCAG AA, all states, feasibility
- Approval chain: self-review → peer → design lead → stakeholder (optional) → developer acceptance
- Pre-handoff requires empty, loading, error, success states plus developer walkthrough
- Implementation QA covers responsive behavior, accessibility testing, and cross-browser/device checks
- 4 review gates
- 5 approval workflow steps
- 5 core review criteria
Adoption & trust: 563 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You ship UI without shared gates, so concepts skip research, handoffs miss states, and production diverges from the design without anyone catching it.
Who is it for?
Solo builders or tiny teams shipping SaaS or mobile apps who own design and want lightweight quality rituals instead of ad-hoc critiques.
Skip if: Teams that already run a formal design-ops program with tooling outside the agent, or pure backend/API work with no visual design surface.
When should I use this skill?
You need design review gates with criteria, checklists, and approval workflows that maintain quality without slowing delivery.
What do I get? / Deliverables
You get a repeatable four-gate review model with explicit criteria and sign-offs so each milestone is cleared before the next phase commits engineering time.
- Four-gate review framework with criteria per gate
- Approval workflow from self-review through developer acceptance
- Implementation QA checklist against design specification
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf at Ship/review because the process culminates in implementation QA and quality gates before release, even though earlier gates start in validate and build. Review subphase matches peer review, lead sign-off, stakeholder approval, and post-build design-vs-spec verification.
Where it fits
Run Gate 1 concept review to confirm the problem, research, and strategic alignment before committing to a UI direction.
Use Gate 2 and Gate 3 to lock visual design, responsive behavior, and complete state coverage before engineering starts.
Execute Gate 4 implementation QA to compare the build to spec, test accessibility, and sign off cross-browser.
Ensure Gate 1 ties user needs to research evidence before exploring multiple concepts.
How it compares
Use for structured design gates and checklists instead of one-off chat critiques with no approval criteria.
Common Questions / FAQ
Who is design-review-process for?
Indie and solo builders who design their own product and need clear review gates from concept through implementation QA without a dedicated design-ops team.
When should I use design-review-process?
During Validate when aligning concepts with research; in Build before developer handoff and design-system checks; and in Ship when running implementation QA against the spec and accessibility bar.
Is design-review-process safe to install?
It is procedural documentation with no built-in shell or network calls; review the Security Audits panel on this Prism page before installing from any third-party skill source.
SKILL.md
READMESKILL.md - Design Review Process
# Design Review Process You are an expert in establishing design review processes that maintain quality without slowing teams down. ## What You Do You create review processes with clear gates, criteria, and workflows that ensure design quality. ## Review Gates ### Gate 1: Concept Review - Problem clearly defined - User needs supported by research - Multiple concepts explored - Strategic alignment confirmed - Stakeholder input gathered ### Gate 2: Design Review - Visual design meets brand standards - Interaction patterns are consistent - Responsive behavior defined - Content strategy applied - Design system components used ### Gate 3: Pre-Handoff Review - All states designed (empty, loading, error, success) - Edge cases addressed - Accessibility requirements met - Handoff specs complete - Developer walkthrough done ### Gate 4: Implementation QA - Design matches specification - Interactions work as designed - Responsive behavior verified - Accessibility tested - Cross-browser/device checked ## Review Criteria - Does it solve the user problem? - Is it consistent with the design system? - Is it accessible (WCAG AA)? - Are all states and edge cases covered? - Is it feasible to implement? ## Approval Workflow - Designer self-review against checklist - Peer design review - Design lead sign-off - Stakeholder approval (if required) - Developer acceptance ## Best Practices - Not every project needs every gate - Scale the process to project size and risk - Use checklists to make reviews objective - Time-box reviews to prevent endless cycles - Document review decisions and rationale