Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add nimadorostkar/Claude-Skills-collection --skill ui-reviewgit clone --depth 1 https://github.com/nimadorostkar/Claude-Skills-collectionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/ui-review)<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/ui-review"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/ui-review/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/ui-review"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/ui-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00034 | $0.01231 |
| Opus 5 | $0.00017 | $0.00616 |
| Sonnet 5 | $0.00007 | $0.00246 |
| Haiku 4.5 | $0.00003 | $0.00123 |
Grade A, and why
ui-review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
UI Review
Purpose
Critique an interface in a way that improves it. A critique of "it feels cluttered" is a symptom report; a critique that identifies three elements competing for the same visual weight is a fix.
When to Use
- Reviewing a mockup, a screenshot, or a live interface.
- A design that "feels wrong" and nobody can say why.
- Before a design goes to engineering.
- Auditing an interface for consistency.
Capabilities
- Hierarchy analysis: what is read first, and is it the right thing?
- Affordance: does the interface communicate what can be done?
- Consistency against a system.
- State coverage: empty, loading, error, overflow.
- Feedback that is specific enough to act on.
Inputs
- The design, and what the user is trying to accomplish with it.
- The stage: exploration (be generous) or final polish (be exacting).
- The design system, if there is one.
Outputs
Findings ranked by impact:
- Blocking — The user cannot complete the task, or will be misled.
- Should fix — The design works but costs the user effort.
- Consider — Polish.
Each with a specific observation and a specific fix.
Workflow
- Identify the primary action — What is this screen for? If a user cannot find the one thing they came to do within two seconds, nothing else matters.
- Trace the hierarchy — Squint at it. What is still visible? That is the actual hierarchy, and it is frequently not the intended one.
- Check the affordances — Does what is clickable look clickable? Is anything that is not clickable styled as though it is?
- Enumerate the states — Empty, loading, error, one item, a thousand items, a very long name. Most designs cover the state where everything is perfect and none of the others.
- Check consistency — Against the design system, and against the rest of the product. Two button styles for the same action is a defect.
- Report specifically — With a location, an observation, and a fix.
Best Practices
- The squint test is the fastest hierarchy diagnostic available. Blur the design until only the strongest elements are visible. If the primary action is not among them, the hierarchy is wrong regardless of how it looks in focus.
- "Cluttered" is never the finding. The finding is what specifically is competing: three elements at equal weight, or insufficient space between groups, or no clear primary action.
- Every design has an empty state, an error state, and an overflow state. Reviewing only the populated happy-path mockup means reviewing a third of the design.
- A disabled button with no explanation is a dead end. If the user cannot proceed, the interface must say why.
- Do not report taste as though it were a usability finding. "I would have used a different blue" is not a critique.
- Be generous in exploration and exacting in polish. Detailed feedback on a direction that is about to be discarded wastes everyone's time.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 116 lines · 34 tokens per session scan A 1e5472cd78dd
ui-review is a skill published in the GitHub repository nimadorostkar/Claude-Skills-collection (26 stars, last pushed 24d ago), licensed MIT. It adds 34 tokens to every session and 1,231 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
accessibility
Audit and improve web accessibility following WCAG 2.2 guidelines. Use when asked to "improve accessibility", "a11y audit", "WCAG compliance", "screen reader support", "keyboard navigation", or "make accessible".
frontend-design
Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build landing pages, websites, dashboards, web components, or any frontend UI. Generates creative, polished code that avoids generic AI aesthetics.
prototype
Build a self-contained local prototype at .turbo/prototypes/ .html, drive it, and hand it to the user to settle unknowns that prose cannot answer. Use when the user asks to "prototype this", "build a prototype", "mock this up", "show me what it would look like", "let me try the interaction first", or when a decision…
user-experience
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and…
slop-eval
Objectively evaluate a UI/web design against the pols.dev anti-slop design law: detect catalogued slop tells with cited evidence, score 8 weighted axes (color, type, components, layout, motion, execution, signature, cohesion), and emit a Slop Report with a 0–100 Slop Index and grade. Use when the user asks to…
design-md-validator
Validate DESIGN.md files against the official Google specification using the @google/design.md CLI linter. Works with local files. Use when the user wants to lint a DESIGN.md, check spec compliance, find broken token references, verify WCAG contrast ratios, diff two versions, export tokens to Tailwind or DTCG format…