
Critique
Run an independent, bias-resistant UX critique of a feature, page, or component with scored feedback before you ship UI changes.
Overview
Critique is an agent skill most often used in Build (also Ship review, Validate prototype) that runs dual blind UX assessments with scoring and anti-pattern detection on a design or component.
Install
npx skills add https://github.com/pbakaus/impeccable --skill critiqueWhat is this skill?
- Mandatory Context Gathering Protocol via /impeccable; runs /impeccable teach when no design context exists
- Two blind, parallel assessments (sub-agents or sequential internal notes) so neither sees the other's output
- Quantitative scoring plus persona-based testing and automated anti-pattern detection
- Browser tab isolation: each assessment opens its own tab when automation is available
- Actionable UX feedback on hierarchy, IA, emotional resonance, and cognitive load—not a code-level audit
- Two independent assessments that must not see each other's output
- Covers visual hierarchy, IA, emotional resonance, cognitive load, and overall quality with quantitative scoring
Adoption & trust: 83.4k installs on skills.sh; 35.9k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have UI in the repo or in a browser but only get one biased chat opinion instead of structured, independent UX judgment.
Who is it for?
Solo builders who already invoked Impeccable (or will run teach) and want serious UX review before locking a screen or component.
Skip if: Teams that need automated accessibility contrast ratios, Lighthouse scores, or P0–P3 technical defect reports without a UX lens—use audit instead.
When should I use this skill?
User asks to review, critique, evaluate, or give feedback on a design or component.
What do I get? / Deliverables
You receive quantitative, persona-informed critique and anti-pattern flags you can hand to polish, audit, or implementation work—after Impeccable context is established.
- Structured UX critique with quantitative scores
- Persona-based findings and anti-pattern list
- Actionable feedback for follow-up commands—not fixes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because critique targets interfaces and components you are actively designing or refining. Frontend is where layout, hierarchy, and component-level UX decisions live—the natural scope for persona-based design evaluation.
Where it fits
Score a clickable prototype’s IA and emotional tone before you commit to full frontend build.
Run blind dual critiques on a checkout component to catch hierarchy and cognitive-load issues early.
Gate a marketing page with structured UX feedback right before release.
Sanity-check hero and CTA clarity on a campaign landing page before paid traffic.
How it compares
Use for perceived UX quality and design anti-patterns; use audit for measurable technical quality in implementation.
Common Questions / FAQ
Who is critique for?
Solo and indie builders shipping web or product UI who want agent-driven UX evaluation with scoring, not a casual “looks fine” review.
When should I use critique?
During Build when refining frontend components; during Validate when judging a prototype’s UX; before Ship when you want a design review gate on a page or feature—always after Impeccable context (teach if missing).
Is critique safe to install?
Review the Security Audits panel on this Prism page and inspect the skill source; browser automation and sub-agents may touch live URLs or spawn extra agent work.
Workflow Chain
Requires first: impeccable, impeccable teach
Then invoke: audit
SKILL.md
READMESKILL.md - Critique
## STEPS ### Step 1: Preparation Invoke /impeccable, which contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding. If no design context exists yet, you MUST run /impeccable teach first. Additionally gather: what the interface is trying to accomplish. ### Step 2: Gather Assessments Launch two independent assessments. **Neither must see the other's output** to avoid bias. You SHOULD delegate each assessment to a separate sub-agent for independence. Use your environment's agent spawning mechanism (e.g., Claude Code's `Agent` tool, or Codex's subagent spawning). Sub-agents should return their findings as structured text. Do NOT output findings to the user yet. If sub-agents are not available in the current environment, complete each assessment sequentially, writing findings to internal notes before proceeding. **Tab isolation**: When browser automation is available, each assessment MUST create its own new tab. Never reuse an existing tab, even if one is already open at the correct URL. This prevents the two assessments from interfering with each other's page state. #### Assessment A: LLM Design Review Read the relevant source files (HTML, CSS, JS/TS) and, if browser automation is available, visually inspect the live page. **Create a new tab** for this; do not reuse existing tabs. After navigation, label the tab by setting the document title: ```javascript document.title = '[LLM] ' + document.title; ``` Think like a design director. Evaluate: **AI Slop Detection (CRITICAL)**: Does this look like every other AI-generated interface? Review against ALL **DON'T** guidelines in the impeccable skill. Check for AI color palette, gradient text, dark glows, glassmorphism, hero metric layouts, identical card grids, generic fonts, and all other tells. **The test**: If someone said "AI made this," would you believe them immediately? **Holistic Design Review**: visual hierarchy (eye flow, primary action clarity), information architecture (structure, grouping, cognitive load), emotional resonance (does it match brand and audience?), discoverability (are interactive elements obvious?), composition (balance, whitespace, rhythm), typography (hierarchy, readability, font choices), color (purposeful use, cohesion, accessibility), states & edge cases (empty, loading, error, success), microcopy (clarity, tone, helpfulness). **Cognitive Load** (consult [cognitive-load](reference/cognitive-load.md)): - Run the 8-item cognitive load checklist. Report failure count: 0-1 = low (good), 2-3 = moderate, 4+ = critical. - Count visible options at each decision point. If >4, flag it. - Check for progressive disclosure: is complexity revealed only when needed? **Emotional Journey**: - What emotion does this interface evoke? Is that intentional? - **Peak-end rule**: Is the most intense moment positive? Does the experience end well? - **Emotional valleys**: Check for anxiety spikes at high-stakes moments (payment, delete, commit). Are there design interventions (progress indicators, reassurance copy, undo options)? **Nielsen's Heuristics** (consult [heuristics-scoring](reference/heuristics-scoring.md)): Score each of the 10 heuristics 0-4. This scoring will be presented in the report. Return structured findings covering: AI slop verdict, heuristic scores, cognitive load assessment, what's working (2-3 items), priority issues (3-5 with what/why/fix), minor observations, and provocative questions. #### Assessment