agentleFS
greglas75greglas75/zuvo/skills/design-review/SKILL.md

design-review

Skill7 starsChanged 28 days agoMITView on GitHub

UI/UX design consistency audit. Code-based DX1-DX20 checklist covering states, consistency, accessibility, responsive behavior, and interaction patterns. Optional visual audit via chrome-devtools screenshots and automated WCAG accessibility via axe-core. DAP1-DAP12 anti-pattern detection. Modes: [path], visual, --fix-critical, --dry-run, --max-files, --quick, loop. NOT for code quality (use zuvo:code-audit) or test quality (use zuvo:test-audit).

155 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use project-stage-detect, team-audio and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • CoralGameSkill

    project-stage-detect

    Automatically analyze project state, detect stage, identify gaps, and recommend next steps based on existing artifacts.

    Also in 16 projects that use this

  • CoralGameSkill

    team-audio

    Orchestrate audio team: audio-director + sound-designer + technical-artist + gameplay-programmer for full audio pipeline from direction to implementation.

    Also in 13 projects that use this

  • julianoczkowskiSkill

    brief-to-tasks

    Break a design brief into an ordered checklist of independently buildable tasks using vertical slices. Saves as a markdown checklist. Use when user wants to break down work, create tasks from a brief, plan implementation order, or mentions "tasks" or "breakdown".

    Also in 7 projects that use this

  • lilangMaxSkill

    asset-spec

    Generate per-asset visual specifications and AI generation prompts from GDDs, level docs, or character profiles. Produces structured spec files and updates the master asset manifest. Run after art bible and GDD/level design are approved, before production begins.

    Also in 10 projects that use this

  • lilangMaxSkill

    create-control-manifest

    After architecture is complete, produces a flat actionable rules sheet for programmers — what you must do, what you must never do, per system and per layer. Extracted from all Accepted ADRs, technical preferences, and engine reference docs. More immediately actionable than ADRs (which explain why).

    Also in 10 projects that use this

  • +4 more from CoralGame
  • +3 more from lilangMax

The file

Show its rules and text

We split this skill into the rules it gives an agent

22 rules. 0 are common, 13 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 129 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read these files before any work begins:

    line 59
  2. Distinctive:

    If any file is missing, STOP.

    line 74
  3. Very specific:

    Read ../../shared/includes/env-compat.md for agent dispatch patterns, path resolution, and progress tracking across all supported platforms.

    line 78
  4. Very specific:

    Use the deterministic preload helper FIRST: Run ~/.zuvo/compute-preload design-review "$PWD".

    line 102
  5. Very specific:

    Read ../../shared/includes/codesift-setup.md for the full initialization sequence.

    line 108
  6. Distinctive:

    Default: all views, code-only, with cross-view analysis.

    line 134
  7. Very specific:

    Next.js boundary detection: If Next.js App Router detected, scan for co-located loading.tsx/error.tsx files alongside page.tsx.

    line 183
  8. Very specific:

    If >30 views (or --max-files limit), audit top files by size, capped at limit.

    line 191
  9. Distinctive:

    Run grep commands across the codebase for:

    line 230
  10. Distinctive:

    Check for these common UI anti-patterns during scoring:

    line 265
  11. Distinctive:

    After per-view scoring, check cross-cutting concerns:

    line 284
  12. Very specific:

    Read .interface-design/system.json (preferred) or .interface-design/system.md (fallback).

    line 294
  13. Distinctive:

    Token Test: Do actual values match declared tokens?

    line 299
  14. Distinctive:

    No system artifacts = skip.

    line 301
  15. Distinctive:

    If chrome-devtools unavailable: skip entire Phase 3 with message.

    line 330
  16. Distinctive:

    After applying: re-run DX scoring on fixed views to verify gates pass.

    line 386
  17. Distinctive:

    No artifacts = purely structural audit (DX1-DX20 only).

    line 414
  18. Distinctive:

    After completing the audit, print:

    line 421
  19. Very specific:

    If gate_status = FAIL → VERDICT = INCOMPLETE.

    line 450
  20. Very specific:

    Follow the retrospective protocol from retrospective.md.

    line 463
  21. Distinctive:

    If gate check skips: print "RETRO: skipped (trivial session)" and proceed.

    line 465
  22. Very specific:

    After printing this block, append the Run: line value (without the Run: prefix) to the log file path resolved per run-logger.md.

    line 467

“Common” is measured: kept by at least 6 in 10 of the 129 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

zuvo:design-review — UI/UX Design Consistency Audit

Audit frontend views for design consistency, state completeness, accessibility, and interaction patterns. Two modes: code-based (grep + read, fast) and visual (chrome-devtools screenshots + axe-core WCAG audit, slower).

Scope: Frontend view health, design system adoption, state coverage, a11y compliance, responsive behavior. Out of scope: Code quality (zuvo:code-audit), test quality (zuvo:test-audit), creating new designs (zuvo:design), qualitative multi-agent review (zuvo:ui-design-team).

Mandatory File Loading

Read these files before any work begins:

  1. ../../shared/includes/codesift-setup.md -- CodeSift discovery and tool selection
  2. ../../shared/includes/env-compat.md -- Agent dispatch and environment adaptation

Print the checklist:

CORE FILES LOADED:
  1. codesift-setup.md   -- [READ | MISSING -> STOP]
  2. env-compat.md       -- [READ | MISSING -> STOP]
  3. ../../shared/includes/run-logger.md -- [READ | MISSING -> STOP]
  4. ../../shared/includes/retrospective.md -- [READ | MISSING -> STOP]

If any file is missing, STOP.

Environment Compatibility

Read ../../shared/includes/env-compat.md for agent dispatch patterns, path resolution, and progress tracking across all supported platforms.

MANDATORY TOOL CALLS — Design Review Validity Gate

INVALID if any tool below is skipped. "DEFERRED", "N/A" NOT valid reasons.

ToolTriggerSkip allowed?
get_file_treeAlwaysNO — find component dirs, theme files
search_textAlwaysNO — className=, design tokens, CSS variables
search_symbolsAlwaysNO — component discovery
search_patternsAlwaysNO — DAP anti-patterns
scan_secretsAlwaysNO — env-var leaks in client code
audit_scanAlwaysNO — compound check
React tools (analyze_renders, analyze_hooks, trace_component_tree)React detectedNO when React

Forbidden: same (skipped/N/A/codesift unavailable when deferred — REJECTED).

POSTAMBLE: report on disk → retro appended → ~/.zuvo/append-runlog exit 0. Every DX/DAP finding needs path/to/file.ext:LINE (verify-audit gate).

Mandatory-tools-acknowledgment: I will run get_file_tree + search_text + search_symbols + search_patterns + scan_secrets + audit_scan + React tools (when React) for this design review. Every DX/DAP finding will cite a `path/to/file.ext:LINE` resolving in the current tree.

Use the deterministic preload helper FIRST. Run ~/.zuvo/compute-preload design-review "$PWD". Math gate enforced.


CodeSift Integration

Read ../../shared/includes/codesift-setup.md for the full initialization sequence.

Design-review CodeSift usage:

  • get_file_tree(repo, path_prefix="src/components/ui") -- UI component inventory with symbol counts
  • find_references(repo, symbol_name="Button") -- shared component adoption rate
  • search_text(repo, query="aria-|role=", regex=true, file_pattern="*.tsx") -- a11y attribute scan
  • search_text(repo, query="className=.*\\[", regex=true, file_pattern="*.tsx") -- Tailwind magic values

Step 0: Parse $ARGUMENTS

ArgumentBehavior
(empty)Audit all frontend views in src/ (auto-discover)
[path]Audit views in specific directory
[file]Audit single component (deep mode)
visualEnable visual audit via chrome-devtools (requires running dev server)
--quickDX checklist only, skip cross-view analysis
--fix-criticalAfter audit, auto-fix critical gate failures (DX6/DX7/DX10/DX20)
--dry-runWith --fix-critical: show planned edits without applying
--max-files [N]Cap audit to N files (default: 30)
--url [url]Dev server URL for visual audit (default: http://localhost:3000)
loopFull cycle: audit, fix critical, re-audit quick, print delta
--from-ui-teamSkip visual re-scan (already captured), focus on DX1-DX20 code scoring

Default: all views, code-only, with cross-view analysis.


Step 0.5: Prerequisites Check

Required (all modes)

CheckHowIf missing
Frontend files exist`find src -name ".tsx" -o -name ".jsx" -o -name "*.vue"head -1`STOP -- "No frontend files found."
Package.json existscat package.jsonWARN -- cannot detect design system

Required (visual mode only)

CheckHowIf missing
chrome-devtools MCPCheck whether chrome-devtools tooling is availableSkip visual, run code-only audit
Dev server running`curl -sI [url]head -1`STOP -- suggest: npm run dev

Optional

CheckHowIf missing
mcp-accessibility-scannerCheck whether accessibility-scanner tooling is availableDX15-DX17 use manual ARIA grep
Tailwind configcat tailwind.config.* 2>/dev/nullDX2-DX4 token checks adapt
Design system artifactscat .interface-design/system.json 2>/dev/nullStructural-only audit (no craft validation)

Phase 1: Discovery

Step 1: Detect Design System

Auto-detect from project signals:

SignalDesign System
@shadcn/ui or components/ui/ with shadcn patternshadcn/ui
@radix-ui/* in depsRadix UI
@mui/material in depsMaterial UI
@mantine/core in depsMantine
@chakra-ui/react in depsChakra UI
@headlessui/react in depsHeadless UI
None + components/ dirCustom components
None + no shared componentsNo design system -- flag as DX20

Also detect CSS framework (Tailwind, CSS Modules, CSS-in-JS, CSS Variables).

Next.js boundary detection: If Next.js App Router detected, scan for co-located loading.tsx/error.tsx files alongside page.tsx. Pages with boundaries score DX6/DX7=1 automatically. Track as BOUNDARY_MAP.

Report: DESIGN SYSTEM: [name] | CSS: [name] | SHARED: [path] ([N] components)

Step 2: Discover Frontend Views

Find page-level and feature-level components. Classify as PAGE (route-level), FEATURE (>100 lines with data/state), or SHARED (reusable).

If >30 views (or --max-files limit), audit top files by size, capped at limit.


Phase 2: Code Audit (DX1-DX20)

DX Checklist

#CheckCritical Gate
DX1Layout structure (flex/grid, no absolute hacks)No
DX2Color values from design tokensNo
DX3Spacing values from scaleNo
DX4Typography from type scaleNo
DX5Component composition (slots, not prop drilling)No
DX6Loading state present for async operationsYES
DX7Error state present with recovery actionYES
DX8Empty state present for collectionsNo
DX9Success/confirmation feedback for mutationsNo
DX10Destructive actions require confirmationYES
DX11Form validation with inline errorsNo
DX12Keyboard navigation for interactive elementsNo
DX13Responsive behavior (mobile breakpoints)No
DX14Focus management (visible focus rings)No
DX15ARIA roles on interactive elementsNo
DX16Color contrast (text: 4.5:1, UI: 3:1)No
DX17Screen reader announcements for dynamic contentNo
DX18Consistent interaction patterns across viewsNo
DX19Animation/transition timing consistentNo
DX20Uses shared component library (not one-off implementations)YES

Score: 1 = YES, 0 = NO, N/A with justification. N/A excludes from denominator.

Thresholds: PASS >= 80%, CONDITIONAL >= 70% and < 80%, FAIL < 70%. Inequalities, not 70-79%: the score is a percentage of applicable gates and can be fractional, so a hyphenated band leaves 79.5% ungraded.

Step 3: Batch Code Analysis

Run grep commands across the codebase for:

  • ARIA attributes and roles
  • Hardcoded color values (hex outside tokens)
  • Magic spacing values (arbitrary px/rem)
  • Loading/error/empty state patterns
  • Confirmation dialog usage
  • Focus ring styles

Store as PROJECT_CONTEXT for per-view scoring.

Step 4: Per-View Audit

For each view, read the full component and evaluate DX1-DX20.

Dispatch follows ../../shared/includes/execution-policy.md through env-compat. Reuse existing authorization within that policy; session restrictions take precedence. Run each required gate and report its actual independence or an unmet requirement.

If >8 views: Split into batches of 4 and dispatch background agents where possible. Each agent receives the PROJECT_CONTEXT and scores independently.

Output per view:

### [file path]
View type: [PAGE/FEATURE]
DX: DX1=[0/1/NA] ... DX20=[0/1/NA]
Applicable: [N]/20 | Passed: [N] | Score: [%]
Critical gate: DX6=[0/1/NA] DX7=[0/1/NA] DX10=[0/1/NA] DX20=[0/1/NA] -- [PASS/FAIL]
Evidence (critical gates = 1): [DX=evidence pairs]
Anti-patterns: [DAP IDs or "none"]
Tier: [A/B/C/D]
Top 3 issues: [description]

DAP Anti-Patterns

Check for these common UI anti-patterns during scoring:

IDAnti-PatternDetection
DAP1Prop drilling through 3+ levelsCount prop pass-through depth
DAP2Inline styles overriding design systemstyle={{ next to className
DAP3Inconsistent button hierarchy (multiple primary CTAs)Count primary-styled buttons per view
DAP4Missing disabled state on form submitButton without disabled prop during async
DAP5Toast/notification without timeout or dismissNotification without auto-dismiss logic
DAP6Modal without escape-to-closeDialog without onEscapeKeyDown or equivalent
DAP7Infinite scroll without loading indicatorScroll listener without skeleton
DAP8Hard-coded breakpoint valuespx media queries instead of theme tokens
DAP9Z-index wars (arbitrary values)z-index values not from a defined scale
DAP10Color used as sole differentiatorStatus/state communicated only by color
DAP11Duplicate component (same purpose, different implementation)Cross-view comparison
DAP12Missing reduced-motion supportAnimations without prefers-reduced-motion

Step 5: Cross-View Analysis

After per-view scoring, check cross-cutting concerns:

  1. Component consistency -- same purpose, different implementations?
  2. State coverage matrix -- view x state (loading/error/empty/success). Gaps?
  3. Off-scale values -- count from Step 3 greps
  4. Icon library inventory -- >1 library = flag
  5. Shared component adoption rate -- percentage using shared components

Step 5.5: Craft Validation (design system artifacts exist)

Read .interface-design/system.json (preferred) or .interface-design/system.md (fallback). Run 4 Craft Validation Tests:

  1. Swap Test: Replace tokens with neutrals. Does personality survive?
  2. Squint Test: Is hierarchy clear when blurred?
  3. Signature Test: Is the unique element present (5 touchpoints)?
  4. Token Test: Do actual values match declared tokens?

No system artifacts = skip.


Phase 3: Visual and Accessibility Audit (visual mode only)

Requires: dev server running, chrome-devtools MCP available.

3.1 Screenshots

Capture at 3 breakpoints (1440, 768, 375) via chrome-devtools.

3.2 WCAG Accessibility Scan

If mcp-accessibility-scanner available:

  • scan_page per route for axe-core violations
  • scan_page_matrix for variant testing (mobile, forced-colors, reduced-motion, zoom-200%)
  • audit_keyboard for tab order, focus visibility, keyboard traps

axe-core results override grep-based checks: DX15-DX17 scores come from axe-core when scanner ran.

3.3 Computed Styles

Color and font inventories, ARIA attribute verification.

3.4 Cross-View Visual Comparison

Consistency analysis across captured screenshots.

If chrome-devtools unavailable: skip entire Phase 3 with message.


Phase 4: Report

Step 7: Aggregate Results

Combine per-view DX scores + cross-view analysis + visual audit (if run) + craft validation (if run).

Report Sections

  1. Header -- project, date, design system, CSS framework, mode
  2. Executive Summary -- average score, critical gate status, tier distribution
  3. Critical Gate Summary -- DX6/DX7/DX10/DX20 per view
  4. State Coverage Matrix -- views x states (loading/error/empty/success)
  5. Per-View Scores -- DX1-DX20 per view with tier
  6. Cross-View Analysis -- consistency findings
  7. Anti-Pattern Summary -- DAP occurrences across views
  8. Craft Validation Results (if system artifacts exist)
  9. Action Plan -- prioritized: critical gates -> consistency -> state gaps -> design system gaps
  10. Accessibility Summary (if visual mode ran)

Save to: zuvo/audits/design-review-YYYY-MM-DD.md — at the project root (zuvo/ resolves via git rev-parse --show-toplevel; override $ZUVO_OUTPUT_DIR. See ../../shared/includes/report-output-location.md).

Step 9: Propose Next Actions

If Tier D OR no design system OR DX20 widespread FAIL:

  1. "Run zuvo:design extract [path]" -- formalize implicit patterns
  2. "Fix critical gate failures only"
  3. "Fix specific view"
  4. "Skip -- keep report"

Otherwise (Tier A-C with design system):

  1. "[Best action from audit]"
  2. "Fix critical gate failures only"
  3. "Fix specific view"
  4. "Skip -- keep report"

Phase 5: Auto-Fix Critical (if --fix-critical)

Scope guard (NON-NEGOTIABLE): Auto-fix touches ONLY the UI/states layer -- loading wrappers, error boundaries, confirmation dialogs, component imports. Never modify business logic, data fetching, or event handlers.

--dry-run: List planned edits without applying.

For each critical gate failure:

GateFix
DX6=0Next.js App Router? Create loading.tsx. Otherwise: wrap with loading state.
DX7=0Next.js App Router? Create error.tsx. Otherwise: wrap with error state.
DX10=0Replace destructive onClick with confirmation dialog.
DX20=0Replace one-off component with shared library equivalent.

After applying: re-run DX scoring on fixed views to verify gates pass.


Phase 6: Loop Mode (loop argument)

  1. Audit: Full audit (Phase 1-4) -- baseline scores
  2. Fix: Apply critical fixes (Phase 5)
  3. Re-audit: Quick mode -- post-fix scores
  4. Delta summary:
DESIGN LOOP DELTA
  Before: Avg [X]% | Critical gates: [N] FAIL
  After:  Avg [Y]% | Critical gates: [N] FAIL
  Delta:  +[Z]% | [N] gates fixed
  Remaining: [top 3 unfixed issues]
  Next step: [recommendation]

Contract: zuvo:design <-> zuvo:design-review

This skill reads design system artifacts produced by zuvo:design:

  • system.json (preferred) -- machine-readable, stable token matching
  • system.md (fallback) -- human-readable, craft validation context

No artifacts = purely structural audit (DX1-DX20 only). With artifacts = adds craft validation + intent-aware token matching.


Completion

After completing the audit, print:

DESIGN-REVIEW COMPLETE
-----
Views audited: [N]
Avg DX score:  [N]%
-----

Validity Gate (REQUIRED — print BEFORE Run line, AFTER retro append + append-runlog)

VALIDITY GATE
  required_tool_calls:
    get_file_tree: [<N> | NOT_CALLED]
    search_text: [<N> | NOT_CALLED]
    search_symbols: [<N> | NOT_CALLED]
    search_patterns: [<N> | NOT_CALLED]
    scan_secrets: [<N> | NOT_CALLED]
    audit_scan: [<N> | NOT_CALLED]
    react_tools: [<result> | not_required | NOT_CALLED]
  postamble:
    retros_log_appended: [yes(bytes_added=N) | NOT_APPENDED]
    retros_md_appended: [yes(entry_count=N) | NOT_APPENDED]
    verify_audit_pass: [yes(<verified>/<total>) | NOT_RUN | REJECTED]
  gate_status: [PASS | FAIL]

If gate_status = FAIL → VERDICT = INCOMPLETE. Append the Run line via the retro-gated wrapper (NOT direct >> runs.log):

printf '%b\n' "$RUN_LINE" | ~/.zuvo/append-runlog
Run: <ISO-8601-Z>	design-review	<project>	-	-	<VERDICT>	-	<DURATION>	<NOTES>	<BRANCH>	<SHA7>	<INCLUDES>	<TIER>

Retrospective (REQUIRED)

Follow the retrospective protocol from retrospective.md. Gate check → structured questions → TSV emit → markdown append. If gate check skips: print "RETRO: skipped (trivial session)" and proceed.

After printing this block, append the Run: line value (without the Run: prefix) to the log file path resolved per run-logger.md.

<DURATION>: use N-dimensions (number of DX dimensions scored, typically 20).


Next-Action Routing

FindingActionCommand
DX6/DX7 State incompletenessFix component stateszuvo:design [component] improve
DX15-DX17 Accessibility violationsFix a11yDirect WCAG compliance fix
DX13 Responsive missingFix responsivezuvo:design [component] improve
3+ DX failures in same componentFull multi-agent reviewzuvo:ui-design-team [path]
DAP anti-patterns foundRefactor componentzuvo:refactor [component]
No design system detectedBootstrap design systemzuvo:design extract [path]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.