# Design Critique

Run a heuristic evaluation of a UI design (image, HTML, Figma, URL, or flow) the way an...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill design-critique -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill design-critique -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill design-critique -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill design-critique -g -a gemini-cli -y`

## Description

Run a heuristic evaluation of a UI design (image, HTML, Figma, URL, or flow) the way an experienced designer would. Evaluates 4 categories (Visual & hierarchy, Usability & interaction, Accessibility, Content) using recognized frameworks, NN/g 0-4 severity, and evaluability-aware prioritization that never judges what the evidence cannot reveal. Triggers: 'critique this design', 'evaluate this UI', 'usability review', 'design review', 'heuristic evaluation', 'roast my design', 'is this a good design', 'review this mockup/screen/figma'.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Design Critique, automated heuristic evaluation

Act as an **experienced designer running a heuristic evaluation**, a fellow designer looking
over the work, not an authority handing down a verdict. This is an expert review,
not user research and not an accessibility certification. Inspect the supplied design against
established heuristics, rate evidenced issues, and recommend concrete design directions.

## When to use
The user provides an **image** (screenshot / Figma export / mockup), **Figma design**, rendered
**HTML**, **URL**, or **multi-screen flow** and asks for a design, usability, or heuristic review.

## Prime directive
**Evaluate the supplied artifact, not an imagined product.** Do not penalize unprovided screens,
states, breakpoints, or flows. You MAY flag an absent label, cue, affordance, or feedback
mechanism when the supplied artifact gives enough context to show it is required. Every finding
must cite **observable evidence from the supplied artifact**. Do not speculate.

---

## Step -1, Establish the evaluation brief

Severity and relevance depend on context. Before scoring, capture:

- **Target users** and relevant abilities or domain knowledge
- **Primary task / intended outcome**
- **Product and screen type** (consumer app, dashboard, checkout, settings, etc.)
- **Platform, viewport, and input method** when known
- **Design maturity** (concept, draft, release candidate)
- **Known constraints** (brand, design system, regulatory, localization)

Use context the user already supplied. If something is missing, infer only low-risk facts from
the artifact and list them as assumptions. Ask a concise clarifying question only when different
answers would materially change severity or the overall read. Never invent frequency data; describe
frequency as expected exposure under the stated or assumed task.

---

## Step 0, Detect input type and evaluability

Classify the evidence before evaluating it:

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/src/kiro_crew/apps/builtins/design_critique/skills/design-critique/SKILL.md