Reviewing Design Work

Reviewing design work

You are judging existing design output — a PR diff, a rendered surface, a screenshot, a Figma handoff, or a spec — not building a system and not consuming one. This is an L1 dispatcher: it orients you, orders the lenses, and points at the skill that carries each lens's rules. Run the lenses in the order below so objective rule violations surface before subjective bar judgments, and cheap code reads run before expensive browser-driving passes. Each station gets a pointer, not a re-teaching — load the station's own skill to actually run it.

When to use

• Reviewing a PR that adds or changes UI code, styles, tokens, or theme.
• Critiquing a rendered surface or screenshot (light and dark).
• Reviewing a design spec or a Figma → code handoff before the build lands.
• Running the design-critic gate on a slice (see orchestrating-elite-agent-qa).

When NOT to use

• Building a design system (tokens, scales, palettes, naming) — load

designing-a-design-system, not this dispatcher.

• Consuming a design system (wiring an existing token set into a product) — load

consuming-a-design-system.

• Pure logic / backend review with no design surface — this dispatcher adds nothing.

Lens order

Run the lenses in this order within a review session. (In clud-bug's pipeline the code lens and the design lenses are two orthogonal, independently gated passes — protocol SPEC §12.2 — so this ordering governs how a reviewer or orchestrator sequences the work and prioritizes findings, not a cross-pass scheduling constraint; the elite-bar-last placement is this dispatcher's guidance.)

1. Code + markup lens — web-interface-guidelines-review. The opinionated rule set

(WIG, Material 3, Radix) plus token-driven contrast/typography/spacing rules: APCA-preferred contrast cross-checked with WCAG 2.2 AA, atomic typography class, token-not-raw-hex, verb-noun labels, the focus-ring contract, the 24 CSS px interactive floor. Findings cite rules, not vibes. REQUIRED BACKGROUND: web-interface-guidelines-review.

1. Rendered-surface lenses — on screenshots in light AND dark. Three lenses judge the

render itself:

• design-system-consistency — token / scale / color-discipline drift visible on

the render, not just the source line.

• frontend-a11y — contrast ratios, focus visibility, tap targets, semantics, and

motion on the rendered surface, in both themes.

• visual-polish — alignment, optical centering, spacing rhythm, glyph/pattern

quality, state coverage, theme parity ("fine but not elite" counts).

REQUIRED BACKGROUND: design-system-consistency, frontend-a11y, visual-polish.

1. Opinion lens last — designing-elite-ui. The concrete elite / Figma-grade bar

(one-axis color, APCA-gated contrast, floating stable chrome, dark verified). It runs last because it is the subjective bar; the objective violations should already be caught. REQUIRED BACKGROUND: designing-elite-ui.

Rationale: objective rule violations before subjective bar judgments, so findings land in severity order — and the cheap code lens runs before the browser-driving rendered passes.

Each lens judges against the L0 primitives it does not re-derive — the color / type / spacing math: oklch-color-space, apca-contrast, wcag-contrast, palette-relationships, chroma-harmonization, type-scale, line-height-grid, token-naming-conventions, component-sizing-principles.

What fires when

| Situation | What fires | |---|---| | PR touches UI code, no visual surface change (routing, state wiring, refactor) | Code lens only; the rendered lenses stay silent. | | PR changes a visual surface (component, layout, styles, theme) | Code lens and rendered lenses, with designing-elite-ui running last after the objective lenses; the rendered pass is browser-driven — screenshots light + dark, states exercised — per orchestrating-elite-agent-qa (REQUIRED BACKGROUND for orchestrating that gate). | | Design spec / Figma handoff, no code yet | web-interface-guidelines-review applies to the spec; designing-elite-ui sets the bar the build must hit; the rendered lenses defer to post-build review. | | clud-bug-installed repo | The 4 dedicated design lenses (design-system-consistency, frontend-a11y, visual-polish, designing-elite-ui) are kind: design / review_mode: dedicated — they run as the separate design pass (protocol SPEC §12), never inline with the code review, and only when the repo opts in: design.enabled: true in .clud-bug.json, at least one design skill applies to the diff, and the trigger is a PR review (§12.3). Installation alone never fires the pass. |

System-specific layers

These lenses are generic — they compose with a system's own opinionated stance rather than replacing it. udts-review is one system's worked instantiation (incubating): the UDTS-specific rules a reviewer checks on top of this dispatcher. Treat it as a parity marker pointing at tokenomics, not as loadable guidance yet.

Cross-references

• L0 primitives: oklch-color-space, apca-contrast, wcag-contrast,

palette-relationships, chroma-harmonization, type-scale, line-height-grid, token-naming-conventions, component-sizing-principles.

• L0 critic lenses: web-interface-guidelines-review, design-system-consistency,

frontend-a11y, visual-polish, designing-elite-ui; and orchestrating-elite-agent-qa (the QA gate that drives the browser-driven rendered pass).

• L1 sibling dispatchers: designing-a-design-system, consuming-a-design-system.
• L2 stances (incubating): udts-review.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: thrillmade
• Source: thrillmade/agent-skills
• License: MIT
• Homepage: https://logmind.dev

Install and usage instructions live in the source repository linked above.