Icon System — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited Icon System (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
An icon set without shared rules decays one icon at a time: each new glyph is drawn against a slightly different grid, stroke, or metaphor, and within a year the product carries three visual dialects that no single redraw can fix cheaply. This skill produces the spec that makes every icon - including ones drawn by future contributors - feel like one family, and the audit checklist that catches drift before it ships.
Follow the order: the grid constrains the stroke, the stroke constrains the drawing rules, and naming/export only matter once the drawing rules are fixed. Changing the grid after 200 icons exist means redrawing 200 icons.
Collect before drawing anything. Label assumptions as guesses.
currentColor inheritance, iOS/Android asset pipelines).Pick a base canvas, standard is 24x24px. Inside it define:
Names describe function, not appearance, so a visual redesign never forces renames:
delete not trash-can; settings not gear.name-variant with optional category prefix - arrow-left, arrow-left-filled.remove → delete, preferences → settings) so searches succeed.viewBox="0 0 24 24" and no width/height attributes.fill="currentColor" (or stroke) wherever color should inherit; no hard-coded brand hex values in the file.Never scale 24px art down to 16px - it goes muddy. For 16px, redraw with reduced detail, simplified counters, and a stroke that stays near 1.5-2px rendered. Ship size variants as separate optically-tuned files (icon-name-16, icon-name-24).
ICON SYSTEM SPEC - [FILL: product name]
GRID
Canvas: 24x24px Live area: 20x20 Padding: 2px
Keylines: square 20x20, circle Ø22, h-rect 22x16, v-rect 16x22
STROKE
Weight: 2px (never mixed) Caps: round Joins: round
Corner radius: 1px interior, round endpoints
DRAWING RULES
Pixel-aligned edges at 24px. Optical centering for diagonals.
Circles overshoot live area to Ø22. One detail level: [FILL: minimal / moderate]
Canonical metaphors: plus, chevron, arrow drawn once, reused everywhere.
NAMING
Pattern: name-variant (lowercase-hyphenated-singular)
Examples: arrow-left, arrow-left-filled, delete, settings
Aliases: remove→delete, preferences→settings, [FILL: more]
EXPORT
viewBox="0 0 24 24", no width/height, fill="currentColor"
SVGO-optimized, no editor metadata, <1KB target
16px variants redrawn, suffixed -16
SIZES SHIPPED: [FILL: 16 / 20 / 24]
OWNER OF FUTURE ICONS: [FILL]Run against an existing set; every "no" is a defect to log:
Produce an icon system spec containing: the grid and keyline definitions, stroke and corner rules, drawing rules with optical-sizing notes, the naming convention plus alias table, the export pipeline checklist, and - for audits - the defect list from the checklist with a fix priority (grid violations first, naming last, because grid fixes require redraws while renames are mechanical).
gear breaks the day the settings icon becomes sliders.Pair with design-handoff-doc when the spec ships to engineering alongside other design deliverables, and with design-qa-checklist to verify implemented icons match the spec post-build.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.