AI Enablement
Stopping New Team Members From Repeating the Same Design Mistakes
Documenting the judgment that used to live only in senior designers' heads, so AI could apply it too.
Skill anatomy
The structure of a single component skill: variants, when each applies, implementations that work versus ones that don't, and edge cases.
Variant coverage map
Every documented variant traced to a real usage context, closing the gap between "technically correct" and "actually right."
Before and after
A component's documentation compared before and after the skill was written — the exceptions that used to live only in a senior designer's memory, now written as applicable rules.
Applied output
Screens generated by Claude using a completed skill, matching the judgment a senior designer would apply to the same request.
Challenge
Claude could list a component's props from a spec file, but it couldn't reliably say when to use one variant over another. Surface-level documentation produced surface-level output: technically correct, and wrong.
Process
I built each skill by documenting every implementation I'd seen work, every variant with its real use case, and the judgment calls that used to live only in a senior designer's head. The first skill I wrote was for the Table. It took a full day and I rewrote it three times.
Research
Writing the skills showed me gaps in components I'd considered finished. A component wasn't really done until its skill could describe every context it had to handle correctly.
Design
A component ships with its skill the same way it ships with accessibility guidelines. If the knowledge isn't captured well enough for Claude to apply it, it isn't captured well enough for a new teammate either.
Outcome
Requests that used to need a design review to catch a misused pattern increasingly come back right on the first pass, and review time goes to new problems instead of repeat mistakes. The skills drift from the components every time one changes, and I don't have a good way to catch that yet.