Dec design system depth
Skill jpoindexter/design-engineering-canon/skills/dec-design-system-depth
20 agent-agnostic skills encoding the foundational canon of design engineering — usability heuristics, UX laws, product strategy, accessibility, performance, motion, software principles, design systems, AI-native patterns. Installs globally for Claude Code and any SKILL.md-aware agent.
npx -y skills add jpoindexter/design-engineering-canon --skill dec-design-system-depthAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Design system depth beyond "tokens are data" — three-tier token architecture (primitive → semantic → component), W3C DTCG format and tooling, scales as systems, component API design, headless/unstyled primitives, documentation as product, governance and versioning. Use when architecting a design system, structuring tokens, designing component APIs, choosing headless primitives, or setting up contribution/versioning.
SKILL.md
2.4 KB, as published. Nobody here has run it
Design System Depth
A real design system is token architecture + component contracts + governance — not a Figma file of colors.
- Three-Tier Token Architecture:
- Primitive / Global — raw values (
blue-500,space-4). - Semantic / Alias — intent-mapped (
color-action-primary,space-inset-md). - Component-Specific — scoped (
button-bg-hover). Components only ever consume semantic/component tiers, never primitives.
- Primitive / Global — raw values (
- W3C DTCG Format & Tooling: Design Tokens Community Group spec; Style Dictionary and Tokens Studio transform one source into CSS / iOS / Android / JSON.
- Scales as Systems: 4pt/8pt spacing grid, modular type scale (e.g. 1.25 ratio), constrained color ramps. Decisions become lookups.
- Component API Design: Props as the contract; variants, sizes, and states as enumerable options; compound components and slots for composition; sensible defaults so the easy thing is the right thing.
- Headless / Unstyled Primitives: Radix, React Aria, Ark — accessibility and behavior solved in the primitive, styling left to the system. The modern foundation.
- Documentation as Product: Storybook for live docs; usage guidelines, do/don't, props tables treated as part of the deliverable.
- Governance & Versioning: Contribution models, semver for breaking changes, deprecation paths, adoption metrics.
How to apply
- Never let a component reference a primitive token directly — route through a semantic alias so theming works.
- Build behavior/accessibility on a headless primitive, then layer system styling — don't re-solve focus traps and ARIA per component.
- Treat the component API as the contract: enumerable variants/sizes/states, good defaults, composition via slots.
- Ship docs and a versioning/deprecation policy with the system, or adoption stalls.