How do I install the 21st UI Review skill?

Run npx skillmds@latest add 21st-dev/21st-ui-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is 21st UI Review safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with 21st UI Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is 21st UI Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published 21st UI Review?

21st-dev (@21st-dev) published this skill. Their other Agent Skills are listed on their SkillMD profile.

21st UI Review by 21st-dev — Agent Skill

Name: 21st UI Review
Rating: 4.2 (5 reviews)
Author: 21st-dev

21st UI Review

Review existing UI against the project's design context, accessibility expectations, responsive behavior, interaction quality, and high-confidence production rules. Use for UI audits, design QA, frontend review, accessibility review, consistency checks, or requests to find and safely fix visual defects. Trigger for requests such as "review this UI", "audit this page", "find design issues", "check responsiveness", or "fix obvious UX problems". Use 21st-ui-build when the request is primarily to create new UI.

21st-dev Updated Sep 9, 2026

File contents

Review UI with evidence

Separate deterministic defects from subjective design recommendations.

Workflow

Read .21st/design.json, project instructions, and the relevant source.

Run the deterministic review first:

21st review <path>
21st review <path> --json

Inspect the actual component composition and runtime states. Validate claims against code rather than inferring behavior from names.
Group findings into:
- deterministic defects;
- design-system drift;
- accessibility and interaction defects;
- responsive risks;
- subjective product/design recommendations.
Prioritize by user impact and include exact file and line attribution.
Use 21st review <path> --fix only for deterministic, low-ambiguity fixes. Never silently redesign, change brand identity, or alter product behavior.
Run relevant project tests after fixes and rerun review to prove resolution.

Review priorities

semantic controls and accessible names;
keyboard access, focus visibility, and dialog/menu behavior;
image alternatives and meaningful labels;
touch target size and disabled/loading states;
responsive overflow and fixed-width assumptions;
reduced-motion handling;
hardcoded visual values that conflict with project tokens;
duplicate primitives instead of existing components;
inconsistent typography, radius, spacing, shadows, and icons;
fake data, placeholder copy, or missing empty/error states.

Output

Lead with actionable findings ordered by severity. Keep subjective suggestions clearly labeled. If no issue is proven, say so and state what was inspected.

---name: 21st-ui-reviewdescription: Review existing UI against the project's design context, accessibility expectations, responsive behavior, interaction quality, and high-confidence production rules. Use for UI audits, design QA, frontend review, accessibility review, consistency checks, or requests to find and safely fix visual defects. Trigger for requests such as "review this UI", "audit this page", "find design issues", "check responsiveness", or "fix obvious UX problems". Use 21st-ui-build when the request is primarily to create new UI.--- # Review UI with evidence Separate deterministic defects from subjective design recommendations. ## Workflow 1. Read `.21st/design.json`, project instructions, and the relevant source. 2. Run the deterministic review first: ```bash 21st review <path> 21st review <path> --json ``` 3. Inspect the actual component composition and runtime states. Validate claims against code rather than inferring behavior from names. 4. Group findings into: - deterministic defects; - design-system drift; - accessibility and interaction defects; - responsive risks; - subjective product/design recommendations. 5. Prioritize by user impact and include exact file and line attribution. 6. Use `21st review <path> --fix` only for deterministic, low-ambiguity fixes. Never silently redesign, change brand identity, or alter product behavior. 7. Run relevant project tests after fixes and rerun review to prove resolution. ## Review priorities - semantic controls and accessible names; - keyboard access, focus visibility, and dialog/menu behavior; - image alternatives and meaningful labels; - touch target size and disabled/loading states; - responsive overflow and fixed-width assumptions; - reduced-motion handling; - hardcoded visual values that conflict with project tokens; - duplicate primitives instead of existing components; - inconsistent typography, radius, spacing, shadows, and icons; - fake data, placeholder copy, or missing empty/error states. ## Output Lead with actionable findings ordered by severity. Keep subjective suggestions clearly labeled. If no issue is proven, say so and state what was inspected.

Frequently asked questions