Ringpre Dev Design Validation

Standards Loading (MANDATORY)

This skill is a validation/checklist skill and does NOT require WebFetch of language-specific standards.

Purpose: Design Validation verifies UX artifact completeness against a checklist. Technical standards are irrelevant at this stage—they apply during TRD (Gate 3) and implementation.

However, if validating component library alignment (Section 8), MUST reference the UI library's documentation to verify component availability and variant names.

Purpose

Verify that UX specifications are COMPLETE before investing in technical architecture.

This gate prevents:

• Incomplete wireframes reaching implementation
• Missing UI states causing implementation rework
• Accessibility gaps discovered late
• Responsive behavior undefined until coding

This is a VALIDATION gate, not a CREATION gate. It checks existing artifacts, does not create new ones.

Gate Entry Criteria

MUST have these artifacts before running this gate:

If artifacts do not exist -> STOP. Return to previous gate.

UI Detection

Feature has UI if PRD contains any of:

• User stories with: "see", "view", "click", "navigate", "page", "screen", "button", "form"
• Features involving: login, dashboard, settings, profile, reports, notifications
• Any direct user-facing interaction

If feature has NO UI -> Skip this gate, proceed to TRD.

Validation Checklist

Section 1: Wireframe Completeness (CRITICAL)

Section 2: UI States Coverage (CRITICAL)

State Detection Rules:

• Screen has data_source: or API reference -> Needs loading/error states
• Screen has type: table or type: list -> Needs empty state
• Screen has type: form or type: button with action -> Needs success state

Section 3: Accessibility Specifications

Section 4: Responsive Specifications

Section 5: User Flow Completeness

Section 6: Content Specifications

Section 7: Design System (New Projects)

This section applies when: Project is new (no existing design system detected).

Detection Rule: Project is "new" if:

• No globals.css with CSS variables exists, OR
• No tailwind.config.* with custom colors exists

Why This Matters:

• Frontend engineers need design tokens before implementation
• TRD references design-system.md for styling architecture
• Missing design system = styling decisions made ad-hoc during coding

Section 8: Component Library Alignment (All UI Features)

This section validates that wireframes use components available in the project's UI library.

Validation Process:

1. Read UI library from ux-criteria.md:

   ui_library: shadcn/ui | Chakra UI | Material UI | Custom
   

2. For each wireframe, check components:

   components:
     - type: Button        # Exists in shadcn? ✅
       variant: primary    # Valid variant? ✅
     - type: DataGrid      # Exists in shadcn? ❌ (custom needed)
   

3. Flag mismatches:

   • Component doesn't exist → Needs custom: true or different component
   • Variant doesn't exist → Use correct library variant

Why This Matters:

• Prevents wireframes specifying components that don't exist
• Prevents implementation errors from incorrect variant names
• Identifies custom component work needed before TRD

Validation Process

Phase 1: Artifact Discovery

1. Read docs/pre-dev/{feature}/prd.md
2. Detect if feature has UI (see UI Detection rules)
3. If no UI -> Skip validation, proceed to TRD
4. Read docs/pre-dev/{feature}/ux-criteria.md
5. Glob docs/pre-dev/{feature}/wireframes/*.yaml
6. Read docs/pre-dev/{feature}/wireframes/user-flows.md
7. If Large track: Read docs/pre-dev/{feature}/feature-map.md

Phase 2: Systematic Validation

FOR EACH section in checklist:
  FOR EACH check in section:
    - Evaluate against artifacts
    - Record PASS or FAIL
    - If FAIL: Record specific gaps with file locations

Phase 3: Verdict

Output Format

# Design Validation Report

## Feature: {feature_name}

## Validation Date: {date}

## Artifacts Validated

| Artifact | Status | Location |
|----------|--------|----------|
| PRD | Found/Not Found | docs/pre-dev/{feature}/prd.md |
| UX Criteria | Found/Not Found | docs/pre-dev/{feature}/ux-criteria.md |
| Wireframes | Found (N files) | docs/pre-dev/{feature}/wireframes/ |
| User Flows | Found/Not Found | docs/pre-dev/{feature}/wireframes/user-flows.md |

## Validation Results

### Section 1: Wireframe Completeness

| Check | Status | Details |
|-------|--------|---------|
| all screens defined | PASS/FAIL | N/N screens have wireframes |
| ASCII prototype present | PASS/FAIL | Details |
| Components specified | PASS/FAIL | Details |
| Route defined | PASS/FAIL | Details |

### Section 2: UI States Coverage

| Check | Status | Details |
|-------|--------|---------|
| Loading state | PASS/FAIL | Details |
| Error state | PASS/FAIL | Details |
| Empty state | PASS/FAIL | Details |
| Success state | PASS/FAIL | Details |

### Section 3: Accessibility Specifications

| Check | Status | Details |
|-------|--------|---------|
| Keyboard navigation | PASS/FAIL | Details |
| Screen reader support | PASS/FAIL | Details |
| Contrast requirements | PASS/FAIL | Details |
| Focus management | PASS/FAIL | Details |

### Section 4: Responsive Specifications

| Check | Status | Details |
|-------|--------|---------|
| Mobile layout defined | PASS/FAIL | Details |
| Breakpoints documented | PASS/FAIL | Details |
| Touch targets noted | PASS/FAIL | Details |

### Section 5: User Flow Completeness

| Check | Status | Details |
|-------|--------|---------|
| Happy path documented | PASS/FAIL | Details |
| Error paths documented | PASS/FAIL | Details |
| Entry points defined | PASS/FAIL | Details |
| Exit points defined | PASS/FAIL | Details |

### Section 6: Content Specifications

| Check | Status | Details |
|-------|--------|---------|
| Button labels defined | PASS/FAIL | Details |
| Error messages specified | PASS/FAIL | Details |
| Empty state CTAs | PASS/FAIL | Details |
| Form validation messages | PASS/FAIL | Details |

### Section 7: Design System (New Projects Only)

| Check | Status | Details |
|-------|--------|---------|
| design-system.md exists | PASS/FAIL/N/A | Details |
| Color palette defined | PASS/FAIL/N/A | Details |
| Typography specified | PASS/FAIL/N/A | Details |
| Contrast validated | PASS/FAIL/N/A | Details |
| CSS variables listed | PASS/FAIL/N/A | Details |

### Section 8: Component Library Alignment

| Check | Status | Details |
|-------|--------|---------|
| UI library identified | PASS/FAIL | Details |
| Components exist in library | PASS/FAIL | Details |
| Variants match library | PASS/FAIL | Details |
| Custom components flagged | PASS/FAIL | Details |

## Summary

| Section | Status | Critical? |
|---------|--------|-----------|
| Wireframe Completeness | PASS/FAIL | Yes |
| UI States Coverage | PASS/FAIL | Yes |
| Accessibility | PASS/FAIL | Yes |
| Responsive | PASS/FAIL | No |
| User Flows | PASS/FAIL | Yes |
| Content | PASS/FAIL | No |
| Design System (new projects) | PASS/FAIL/N/A | Yes (if applicable) |
| Component Library Alignment | PASS/FAIL | Yes |

## Verdict: [DESIGN VALIDATED | CRITICAL GAPS | MINOR GAPS]

### Critical Gaps (MUST fix before TRD)

[List each critical gap with:]
1. **Gap description**
   - File: `path/to/file`
   - Required: What needs to be added

### Minor Gaps (Recommended to fix)

[List each minor gap with:]
1. **Gap description**
   - File: `path/to/file`
   - Issue: What's missing or incomplete

## Next Steps

| Priority | Action | Gate |
|----------|--------|------|
| P0 | Fix critical gaps | Return to Gate 1/2 |
| P1 | Review minor gaps | Optional |
| - | Re-run validation | After fixes |
| - | Proceed to TRD | After validation passes |

Anti-Rationalization Table

Pressure Resistance

Blocker Criteria - STOP and Report

Severity Calibration

When Validation is Not Needed

Skip this gate when all conditions are true:

• Feature is backend-only (no user-facing UI)
• Feature is pure API/infrastructure
• PRD explicitly states "No UI changes"
• Feature is bug fix with no UX modifications

If any UI exists -> Validation is REQUIRED.

Metrics