reviewing-design-work
Skill3 starsChanged 9 days agoMITView on GitHub
Entry-point dispatcher for REVIEWING or CRITIQUING design work — a PR that touches UI code, a rendered surface or screenshot, a Figma handoff, or a design spec. Routes the review through ordered lenses: code and markup rules first (web-interface-guidelines-review), then rendered-surface lenses (design-system-consistency, frontend-a11y, visual-polish), then the opinionated bar (designing-elite-ui), then the house stance (thrill-design) when the work is that house's — with routing rules for when the browser-driven design-critic pass fires (per orchestrating-elite-agent-qa). Use when the task is judging existing design output; for building a system load designing-a-design-system; for consuming one load consuming-a-design-system.
In this repository66 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- clud-bug-collaborationSkill
- critical-issues-onlySkill
- evidence-based-reviewSkill
- respect-existing-conventionsSkill
- skill-frontmatter-qualitySkill
- apca-contrastSkill
- api-contract-enforcementSkill
- brand-voice-reviewSkill
- chroma-harmonizationSkill
- clud-bug-collaborationSkill
- component-sizing-principlesSkill
- component-sizingSkill
- composing-a-screenSkill
- consuming-a-design-systemSkill
- conventions-templateSkill
- critical-issues-onlySkill
- curating-a-skill-catalogSkill
- designing-a-design-systemSkill
- designing-elite-uiSkill
- design-system-consistencySkill
- design-token-namingSkill
- dtcg-formatSkill
- empirical-design-principlesSkill
- evidence-based-reviewSkill
- finding-a-catalog-skillSkill
- frontend-a11ySkill
- guarding-a-regressionSkill
- ios-safari-surfacesSkill
- line-height-gridSkill
- logmindSkill
- motion-continuitySkill
- oklch-color-spaceSkill
- orchestrating-agent-delegationSkill
- orchestrating-a-multi-agent-runSkill
- orchestrating-elite-agent-qaSkill
- palette-relationshipsSkill
- pii-and-complianceSkill
- proving-an-absenceSkill
- respect-existing-conventionsSkill
- retiring-a-superseded-decisionSkill
- semver-design-tokensSkill
- session-heartbeatSkill
- skillforgeSkill
- skill-frontmatter-qualitySkill
- spacing-systemSkill
- technical-writingSkill
- test-disciplineSkill
- thrill-designSkill
- token-frugal-toolingSkill
- token-naming-conventionsSkill
- type-scaleSkill
- udts-component-sizing-laddersSkill
- udts-dtcg-extensionsSkill
- udts-linter-rulesSkill
- udts-naming-conventionSkill
- udts-reviewSkill
- udts-semver-defaultsSkill
- udts-spacing-defaultsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Run the lenses in this order within a review session.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 (every theme and mode).
- 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.
Lens order
Run the lenses in this order within a review session. (In clud-bug's pipeline the code and design lenses are independently gated passes — SPEC §2.2 — so this order sequences a reviewer's work and findings, not the passes.)
- 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.
Rendered-surface lenses — on screenshots in every theme and mode. 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 every mode.
- 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.
- Opinion lens — designing-elite-ui. The concrete elite / Figma-grade bar (one-axis color, gated contrast, subtraction, on-grid sizes, every mode). It runs after the objective lenses because it is the subjective bar; the objective violations should already be caught. REQUIRED BACKGROUND: designing-elite-ui.
- House stance last — when the work is that house's. Apply the L2 stance the work belongs to — thrill-design for Thrill's; it leans on the bar where the bar leaves room and never overrides an objective finding. Skip for anyone else's work.
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.
A finding justified by a named principle rather than by what was observed has two more L0 primitives behind it: empirical-design-principles for the falsifiable ones — Gestalt proximity (it carries the ratio a grouping claim must clear, which the polish lens defers to), Fitts, Hick, Miller, von Restorff — and usability-heuristics for Nielsen, Norman and Shneiderman, where the gate is source and edition rather than prediction.
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, then any house stance, after the objective lenses; the rendered pass is browser-driven — screenshots in every mode, 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 5 kind: design skills (four lenses and the house stance: design-system-consistency, frontend-a11y, visual-polish, designing-elite-ui, thrill-design) run as the separate design pass (SPEC §4.8), never inline with the code review, and only when the repo opts in: the design pass is listed in review.passes in .clud-bug.json, at least one design skill applies to the diff, and the trigger is a pull request. Installation alone never fires the pass, and design findings are advisory unless the repo marks that pass blocking. |
System-specific layers
These lenses are generic; an L2 stance composes on top rather than replacing them. thrill-design is one house's (lens 4). udts-review is one system's (incubating): a parity marker pointing at tokenomics, not 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, empirical-design-principles, usability-heuristics, motion-continuity.
- L0 critic lenses: web-interface-guidelines-review, design-system-consistency, frontend-a11y, visual-polish, designing-elite-ui; and orchestrating-elite-agent-qa (rendered-pass gate).
- L1 siblings: designing-a-design-system, consuming-a-design-system.
- L2 stances: udts-review (incubating), thrill-design.
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
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.

