Design Resources

A curated, verified catalog of what to use and where to look, plus the method for choosing. The value is in accuracy. Several popular URLs are not what their names suggest, licenses changed in 2026, and some beloved libraries are frozen. Every entry here says what the resource actually is, what stack it needs, and when to reach for it. Anything that could not be verified is marked. Prefer fewer, better tools: one primitive layer, one icon family, one motion approach.

Before you start

If .agents/project-context.md exists (or .claude/project-context.md), read it first and treat it as ground truth for stack, platforms, scale, design system, and constraints. Only ask for what it does not cover. If it does not exist and the task is larger than a quick fix, suggest running the project-context skill — but never block on it.

Check what the project already uses (package.json, components.json, the icon imports, the font files). The best resource is usually the one already installed.

Core principles

1. Installed beats new. Extend the current library before adding a second one, since every dependency costs bundle size, upgrades, and consistency.
2. One per category. One primitive system, one icon family, one toast, one motion library per surface.
3. Accessibility is inherited. Choose libraries built on accessible primitives. You cannot patch a11y into a div-based dropdown later.
4. License before install. MIT, ISC, and Apache-2.0 are straightforward. AGPL, "Other", and commercial terms need a decision before code lands.
5. Maintained or frozen, know which. Check the last release and the README before depending on something.
6. References are for patterns, not pixels. Study how shipped products solve a flow. Never copy a brand's identity.

Workflow

• Name the need precisely. Is it a primitive (behavior), a styled component, a block or template, an asset (icons, fonts, backgrounds), a reference (patterns, visuals), an agent tool, or reading?
• Check what exists in the project, and whether the platform covers it natively (<dialog>, popover, <details>, SF Symbols, Material components).
• Shortlist 1–3 from the top picks below or from the reference tables.
• Vet each one: stack fit, license, maintenance, accessibility base, token compatibility (does it use your CSS variables?), bundle and dependencies, and lock-in (copy-in source vs a runtime dependency).
• Recommend one, with the runner-up and the reason, then name the install step and the first integration check.
• Verify before citing any URL you haven't checked this session. Say "unverified" rather than guessing.

Top picks (as of 2026-09)

Other stacks

The catalog leans toward React because most of 2026's registries are React-first. For other stacks, apply the same layering (primitives → owned styled components → assets). These equivalents are well known but were not re-verified this session, so check their current status before installing:

License quick map

Identifying an unknown URL

When a user pastes a design-tool URL and asks what it is:

1. Check it against the reference tables and the "Names that mislead" gotcha below.
2. If it is not listed, read the page itself (title, about page, pricing, GitHub link, license) before describing it. Do not infer from the domain name.
3. Report: what it actually is, who makes it, stack and license if known, whether it fits the user's goal, and a better-fitting alternative if not. Mark anything you could not confirm as unverified.

Choosing within a category

• Component source: use platform primitives first, then the existing library, then a copy-in registry, then a new runtime dependency. Copy-in (shadcn-style) means you own the code and the upgrades. A runtime dependency means someone else's release schedule.
• Icons: pick by stroke and weight fit with your typography and radius, not by count. Weights (Phosphor) help when type weights vary. Line/Fill pairs (Remix, Material FILL) help with selected states. Coverage (Tabler, Hugeicons) helps dense admin UIs.
• Galleries: for a pattern that must work (onboarding, checkout, settings), use shipped-product libraries. For visual direction, use curated showcases. For agent workflows, prefer those with an MCP server (Mobbin, Refero, Gummble) or DESIGN.md libraries.
• Agent skills: load one design skill per concern. Stacking several opinionated skills produces contradictory rules. This collection's design-taste plus design-review cover most needs; add a third-party skill for a specific capability (detectors, video, CRO).

Gotchas

• Names that mislead (verified 2026-09):
  • atlas.attio.com is Attio's GTM Atlas, a go-to-market guide, not a design system.
  • driver.rybicki.ai is a text-based racing-career browser game.
  • revyl.com is an AI mobile-testing platform, not a gallery.
  • animos.app is a design-to-motion-video tool, not an inspiration site.
  • rams.ai is an automated design-review engine, not Dieter Rams' principles.
  • godly.design resolves to godly.website.
  • typeui.sh is verified; ui.sh is not, so don't confuse them.
• coss ui licensing: the apps/ui and apps/origin code is MIT, but the monorepo default is AGPL-3.0. Copy only from the MIT parts, or get a license decision.
• Remix Icon changed license (Remix Icon License v1.0, Jan 2026). It is no longer Apache-2.0. Commercial use is allowed; read the terms.
• Lucide v1 removed brand icons. Use Simple Icons for logos, and only for real partners or integrations.
• Vaul is unmaintained per its README. It still works under shadcn's Drawer, but don't build new abstractions on it.
• Base UI's npm package name: confirm it against the current docs before installing (it was @base-ui/react in 2026 docs).
• Brand DESIGN.md files (getdesign.md, Refero Styles) are references. Shipping another company's palette and type on your product is impersonation-adjacent and still generic.
• Backgrounds and gradient packs (for example backgrounds.supply) push toward the purple-gradient slop look. Use them sparingly and only when the direction calls for it.
• Dribbble-sourced galleries (Collect UI) show concepts that never shipped. Validate the pattern against shipped products.
• revenue-centric-design has a source-available license with a field-of-use restriction. Link to it as a companion. Don't copy its text into MIT/Apache work.
• Counts, prices, and versions drift. The numbers in the reference tables are approximate as of 2026-09. Re-check them before quoting to a user who will pay.

Output format

When recommending, reply with:

Need: <precise need>
Recommendation: <name> — <URL> — <why it fits this project (stack, license, a11y, tokens)>
Runner-up: <name> — <when you would pick it instead>
Install/first step: <command or action>
Check after install: <e.g. uses your CSS variables, keyboard works, bundle delta>
Caveats: <license, maintenance, unverified details>

For "what is this URL?", answer with what it actually is, whether it fits the user's goal, and a better-fitting alternative if it doesn't.

References

Related skills

• design-taste — decide the direction before picking resources that encode one.
• design-systems — integrate a chosen library into tokens and DESIGN.md.
• design-foundations — icon sizing and usage rules after picking a set.
• motion-design — decide whether and how to animate before adding a motion library.
• ux-principles — apply the principles behind the learning resources.