One Icon Scale, One Stroke Width
SHOULD: Bind icon sizes to ONE scale (16 / 20 / 24, matched to the type scale — `size-4` next to `text-sm`, `size-5` next to `text-base`) and hold the whole set to ONE stroke width, which in practice means taking every glyph from a single icon family. A toolbar sized by eye (`w-4`, `w-5`, `size-[18px]`, `h-6`) reads as ragged even when every box is aligned, because the eye compares the drawn marks and not the boxes; and a 1.5px stroke beside a 2px stroke gives two apparent weights at the same nominal size. Sizes come from tokens — a lone `size-[18px]` is a magic number.
Bind icon sizes to the type scale and hold every icon to a single stroke width, instead of sizing each one by eye
Bad
Good
Why it matters
The third clause of that bullet — the one this corpus kept dropping. design-rams-border-radius covers "borders" and design-rams-shadow-consistency covers "shadows"; this is "icon sizing", and the explanation is ours. Icons are the one element people size by eye, so a toolbar ends up at w-4, w-5, size-[18px], h-6 — every glyph centered, every box aligned, and the row still reads as ragged, because the eye compares the drawn marks and not the boxes around them.
Stroke width is the half nobody checks: a 1.5px stroke next to a 2px stroke at the same nominal size gives you two apparent weights, so one icon looks bolder than its neighbour for no reason anyone can name. Fix both with two decisions. One SIZE scale — 16 / 20 / 24, bound to the type scale so an icon matches the text it sits beside (size-4 next to text-sm, size-5 next to text-base) — and one STROKE width across the whole set, which in practice means taking every glyph from a single icon family rather than mixing libraries. Sizes come from tokens, not from arbitrary values: a lone size-[18px] is a magic number that the next person will guess wrong.