An icon set is not an icon system. Your agent now knows.

There are 334,616 open-licensed icons in the world. I know the number because Iconify keeps it, across 236 collections, refreshed every week.

Nineteen of my own shipped skills describe an icon slot. They do it roughly 875 times. And until this week, not one UI glyph existed anywhere in my fleet.

That gap was never a sourcing problem. Here is what it actually was.

The obvious fix is the wrong fix

The obvious fix is to pick a set, download it, and ship two hundred SVG files.

I nearly did. Then I read what my own skills were asking for, and they contradict each other on purpose. My section-design skill speaks 150 design languages. One of them says never use fill-based icons in the chrome. Another says filled and rounded, never outlined. Both are right for their own system. A single house set guarantees the wrong answer on most of them.

So a curated set does not solve it. It also buys a maintenance job that Iconify already does better than I would.

The catalogue is a commodity. It was never the problem.

Two design systems, opposite rules for the same icon. Whichever single house set you pick, it is wrong on one of them.

The four questions nobody had written down

Here is the part that has no library behind it. Every time an icon goes into a page, four questions have to be answered, and none of them are about which file to download.

May you ship this to a client? You can download Tabler in about a minute. Almost nobody can tell you whether they may put a Docker logo in a deck a client pays for. Of the 236 sets Iconify indexes, 70 carry no licence URL at all. Not a bad licence. No licence you can open and read. And the sets that do carry one are not all equal: non-commercial and share-alike terms bite at end use, and a client page is end use.

The one that catches people is brand marks. Simple Icons ships thousands of company logos under CC0, and CC0 is about as permissive as licensing gets. But CC0 licences the drawing. It does not licence the mark. A trademark is not handed over by whoever drew the SVG. Putting a competitor's logo in your comparison chart is usually defensible. Putting it on a page that implies they endorse you is not, and no icon set will stop you.

CC0 covers the file. The trademark is a separate question, and your icon set does not answer it.

Will it take your brand colour? An icon bound to currentColor inherits whatever colour surrounds it, so it matches your brand for free and survives your dark theme. An icon carrying a hard-coded hex in a class does not. It renders perfectly, inherits nothing, and quietly fails contrast the day you flip the board to dark.

Is it big enough to be legal? Here is where you are most likely to be wrong, and it is a specific wrongness. You have probably quoted 4.5:1 for contrast, because that is the text rule. Icons are not text. WCAG 2.2 puts non-text contrast at 3:1, and it puts the minimum target at 24 pixels, rising to 44 for the stricter level. A 16 pixel glyph is fine. A 16 pixel tap target is not. Those are two different measurements and most icon guidance treats them as one.

The glyph and the target are not the same measurement.

Where does it sit in Hebrew? This is the one I could not find documented anywhere. I ship in Hebrew and Arabic. In a right-to-left page, a directional icon moves to the logical right in source order, and it mirrors. Get it wrong and a trailing arrow that means "next" points away from the direction the reader is reading. I surveyed 236 sets and the documentation of the big four, and not one of them covers it.

In a right-to-left page the directional icon moves, and it mirrors.

So this ships a contract, not a folder

@di-atomic/iconography is live on the marketplace, and it contains no icon files at all.

What it contains is 43 semantic slots, harvested out of the skills that were already asking for them rather than invented at a desk. Each slot carries its token name in each set, the SPDX licence id, a link to that licence, and the date I checked it. It classes all 236 sets by whether they are safe in the work your clients pay for, and it rejects the ones that are not in writing rather than quietly leaving them off a list.

Your agent asks for a magnifier. It gets back a token that resolves, a set that matches the design system in front of it, a size and contrast rule it can check, and a straight answer on whether that glyph may appear in the thing your client is paying for.

The part that earns your trust

One number from the build, because it is the honest argument for why a contract beats a folder.

The token checker failed on the very registry it shipped with. I had written circle-help. Lucide has renamed that icon twice, and the live key is now circle-question-mark. The old one is dead. A dead icon token does not throw a build error, does not log a warning, and does not go red in review. It renders nothing at all, and you find out when a client does.

That is exactly the failure a downloaded folder cannot protect you from and a checked contract can.

One thing it does not do, so you are not surprised: it decides which icons exist and what they cost you legally. It does not bind a label to an icon at render time. That is a different defect with a different fix, and I am not going to pretend otherwise.

What to do with this

If you put icons into work someone pays for, the licence is your exposure, not the icon author's. Start there. Ask the four questions on your next deliverable and see how many you can currently answer.

Then get @di-atomic/iconography free from the OPVS marketplace and let your agent answer them for you.