Start with the task, not an install
For one screen or small fix, give the agent the route, existing tokens and components, real content, required states, target widths, and checks. Inspect the render. Add a skill when a procedure repeats or needs a specialized workflow. This is a decision route, not a measured claim that no skill works better. See the brief and source check.
New design system or one screen? OpenDesigner is a conditional option for creating reusable tokens and DESIGN.md. Its own instructions say to use an existing system for a one-off UI task. Codex loading and frontend results are untested by this pool. Read the source check.
Claude Code users: Check that the intended skill is available and invoked before judging its output. See the invocation check.
Skill trial: Hold the brief and project fixed, then check visual-system fit and working behavior separately. See the two-check method.
Dashboard decision: With an existing system, start with its components, tokens, real data, units, freshness, and empty or error states. Try a no-skill brief first. PracticalSwan 2.0 is a conditional next trial if the screen still needs a dashboard workflow. See the dashboard decision.
Catalogue check · 31 October 2026
Frontend Design revision: A contributor-reported comparison favors proposed text over an older version by screenshot judge. The PR is open; it is not a current-source or no-skill result. Read the evidence limits.
Compare skills by task and requirements.
Have a reference screenshot? Match the existing project first. UXKIN ui-from-screenshot describes a same-width render comparison using project components and tokens. It is a conditional source-read option, not a tested result. See the task check.
Sources differ: some are pinned to commits; others follow a mutable branch. This is not a ranking. “Strong fit” means task fit in the stated conditions, not a measured better outcome. Anthropic Frontend Design asks for palette and type choices but says a fixed brief wins; check its plan against your existing system. A small contributor report found pill-shaped buttons in 10 of 21 Opus 5.5 pages made with current skill text; it lacks a no-skill baseline and a skill commit. Check the limit. An external functional benchmark found mixed results from injected web skills; it did not test these listings. See the baseline comparison limit.
Platform gate: Game UI Frontend targets browser games, including responsive browser layouts. Do not use its mobile guidance as evidence of native-app fit. See the source check.
Agent Browser loading: Its v0.38.1 SKILL.md is a discovery stub, not the full browser workflow. Read the tagged core source; in a real trial, record the installed version and agent-browser skills get core output. We have not run it. See the source check.
Concept or QA? If you need a new visual target, Frontend App Builder is a conditional concept-first route. If the screen exists and a change needs proof, name the expected state and use Frontend Testing & Debugging for a targeted rendered check. Write your own release criteria first. Neither skill has a pool-run outcome test. Compare the jobs.
Before Ideate: If you cannot name the target screen and intended user outcome, write that brief first. Get Context is a Product Design prerequisite, not a measured result or a catalogue listing. See the task boundary.
Existing design system: Start with a brief that names the real components, tokens, route, and states. Vercel Labs DS Skills Pipeline generates a project-specific skill from source; it is not a catalogue listing. The author marks Codex support expected, and we have not tested its result. See when to build one.
After a skill update: An “up to date” message from Vercel Skills’ global updater does not check installed bytes against upstream. If you edited a skill locally, inspect its files and link type after updating. See the source check.
Motion-first candidate held: Silk Design makes smooth scrolling and reveal effects defaults. Before using it, check stack fit, reduced-motion behavior, and mobile readability. We have not run it; it is not a catalogue listing. Read the source check.
OpenDesign file check: frontend-skill is a pointer to a removed OpenAI bundle. A separate frontend-design file contains an adapted Anthropic workflow and puts existing tokens and components first. These are not the same skill. We have not tested Codex loading or output. Compare the files.
Package hold: Snowe UI Skill is not listed. GitHub currently reports a YAML error in its SKILL.md frontmatter. We did not test host behavior. Check that metadata parses before you compare a method.
Improve UI
Audit one existing app screen against its current design rules before changing product code.
- Needs
- The target route or component, governing design evidence, source access, and rendered evidence for visual claims.
- Watch for
- It reports findings and writes selected plans under
design-plans/; it does not edit product source. Functional and accessibility checks need explicit scope. Mutable source; no pool-run result test. - Install
- Current install command; review the files and choose your agent and scope first.
- Source
- Ibelick Improve UI · main (mutable) · MIT · checked 30 October 2026
OpenDesigner
A new project needs a reusable design system, tokens, and a written visual rule set.
- Needs
- Python 3.10+, a project brief, existing asset and stack context, a target agent, and review of generated files.
- Watch for
- For a one-off screen with an existing system, follow its DESIGN.md instead. The source is mutable; Codex loading and frontend outcomes are untested by this pool.
- Source
- OpenDesigner main (mutable) · metadata 0.1.0 · MIT
Hueyexe Forms, Inputs, and Checkout
A checkout, registration, or data-entry flow whose fields, validation, errors, and recovery need work.
- Needs
- Real field requirements, the form route, target agent, and keyboard and server-error checks.
- Watch for
- The source is mutable, its references and Codex loading are unverified, and the pool did not test a result.
- Source
- Hueyexe main (mutable) · no declared skill version · MIT repository
OpenAI Game UI Frontend
A browser-game HUD, menu, or overlay that must protect the playfield and make input boundaries explicit. Not an established native-app fit.
- Needs
- A browser-game surface, game fantasy and player verbs, desktop and mobile expectations, and a reviewable playfield and input state.
- Watch for
- Do not use it for a normal dashboard. The source is mutable and its HUD rules are author guidance, not a pool result test.
- Source
- OpenAI main (mutable) · Game Studio 0.1.2 · MIT declared
PaulRBerg Frontend Design
An existing or substantial screen that needs one project-bound direction and rendered inspection.
- Needs
- Existing system context, real content, relevant states and widths, local checks, and its chromium-browser dependency or a host browser or DevTools fallback.
- Watch for
- It is author guidance, not a result test. The source is mutable and has no declared skill version.
- Source
- PaulRBerg main (mutable) · MIT repository
Product Design Ideate
Three visual directions for a new or redesigned screen before a prototype.
- Needs
- Product Design availability, a minimum brief, relevant references, Image Gen, and a user selection.
- Watch for
- Generated directions are not a tested or final interface. The skill source is mutable.
- Source
- OpenAI main (mutable) · Product Design 0.1.52
Frontend App Builder
New visual surface with an approved concept before code.
- Needs
- Image Gen, a browser render, real content, time to approve the concept, and your project-specific release checks.
- Watch for
- Concept-and-fidelity workflow, not a small-fix default or proof that release criteria passed.
- Source
- OpenAI 789aa61 · Build Web Apps 0.1.2 · MIT
Anthropic Frontend Design
A new landing page or major refresh when visual direction is open.
- Needs
- A brief, audience, product constraints, and ideally a screenshot loop.
- Watch for
- It asks for a palette and type plan, but says a fixed brief wins. Give it current tokens and components; reject a plan that replaces them. No pool result test.
- Source
- Anthropic 41bbe19 · Apache-2.0
PracticalSwan Frontend Design
A substantial product surface that needs a stated task, real state model, responsive checks, and rendered verification.
- Needs
- Existing system context, real content, relevant empty or error states, representative widths, and one primary design direction.
- Watch for
- Its hard gates are author instructions. Do not stack it with another design-direction skill before a project trial.
- Source
- PracticalSwan afbb609 · 2.0 · MIT AND Apache-2.0
Wenkang Frontend Design
Project-bound visual feedback before you apply a UI change.
- Needs
- A real route or a defined concept, the project’s components and tokens, a browser for the local preview, and a person to make the visual decisions.
- Watch for
- It exports decisions and annotations for Codex. The preview is not proof that the real route matches or works.
- Source
- Wenkang fae5ad1 · MIT
React Composition Patterns
A flag-heavy React component API.
- Needs
- A React component worth refactoring.
- Watch for
- The pinned lifted-state example uses `Composer.Context`, while a related rule defines `ComposerContext`. Check it before copying; no runtime test was done.
- Source
- Vercel 063bee94 · 1.0.0 · MIT
React View Transitions
Meaningful React or Next.js motion.
- Needs
- Documented runtime support plus reduced-motion and browser checks.
- Watch for
- Not decorative animation or a cross-browser acceptance check.
- Source
- Vercel 063bee94 · 1.0.0 · MIT
Agent Browser
A runnable frontend whose named states need browser navigation, snapshots, and retained screenshots.
- Needs
- Node.js 24 or later, CLI Bash access, Chrome or Chromium CDP, an isolated named session, a reachable route, and the full core instructions loaded from the installed CLI.
- Watch for
- The linked SKILL.md is a discovery stub. Run
agent-browser skills get coreand record the installed version. It does not decide whether the design is right or prove full accessibility. - Source
- Vercel v0.38.1 discovery file · tagged core workflow · Apache-2.0
Agent Browser Dogfood
Exploratory QA for a runnable frontend when a failure needs replayable browser evidence.
- Needs
- Agent Browser, a reachable target URL, a named session, an output path, and a legitimate authentication route when needed.
- Watch for
- It documents user-observed failures. It does not read source, enforce your design system, or certify quality.
- Source
- Vercel v0.38.1 · Apache-2.0
Frontend Testing & Debugging
A specific rendered frontend change or bug that needs a named QA loop.
- Needs
- Build Web Apps, a named route, action and expected state, Browser availability or an explicitly allowed Playwright fallback, and retained QA evidence.
- Watch for
- Record the browser backend, viewport, and session context. A screenshot can prove the wrong surface.
- Source
- OpenAI main (mutable) · Build Web Apps 0.1.2 · MIT
Product Design Audit
A real product flow or screen that needs screenshot-tied UX and visual review.
- Needs
- A named flow, a capture route, and time to inspect screenshots.
- Watch for
- It cannot audit a flow you cannot run or prove full accessibility from pixels.
- Source
- OpenAI 33bd952 · Product Design 0.1.52 · Proprietary declared
Web Design Guidelines
A concise UI review with file-and-line findings.
- Needs
- Named source files and network access for its current guidelines.
- Watch for
- The pinned skill still fetches mutable rules from another repository. Record both the skill commit and the rules commit for comparable reviews. A project example vendors both and reads a local rules file. That is a packaging example, not a better-result test; a clean file review is not an accessibility test.
- Source
- Vercel 063bee94 · 1.0.0 · MIT collection
React Best Practices
React or Next.js performance work.
- Needs
- A React or Next.js codebase.
- Watch for
- Performance improvement is author guidance until tested in your app.
- Source
- Vercel 063bee94 · 1.0.0 · MIT
Game UI is a separate lane
Look elsewhere: Game UI Frontend is for a browser-game playfield, not an ordinary product dashboard. If the player can move or aim, record the camera and input state beside the HUD state; the screen can fail even when the overlay looks polished.
One record every installation should add
Adoption record: target agent · project or global scope · upstream URL and revision · local edits · update review. For a single-direction rendered loop, add the route, system constraints, one chosen direction, required states and widths, local checks, and retained render evidence. For a visual-direction selection loop, add the minimum brief, references, three directions, and selected target. For a design-and-build skill, add user and screen job, existing system, in-scope states, viewports, and input methods. For a project-bound feedback loop, add the represented route, source tokens, human decisions, annotations, export, applied diff, and later live-route comparison. Add the proof resource too: a concept and browser comparison for a visual build; a named route, interaction, expected result, Browser path, backend, viewport, and session context for targeted QA; a named flow and accepted screenshots for a flow audit; a target URL, named session, output directory, retries, and retained repro artifacts for exploratory QA; or the relevant files and rule revision for a code review.
Not in this catalogue
Prompt collections, component libraries, templates, whole applications, and design-system conversion pipelines solve different problems. A repository with a SKILL.md can also bundle scripts and references, so inspect every file before adoption.