Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

dec-design-system-depth

Étoiles0

Forks0

Mis à jour13 juillet 2026 à 18:05

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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

jpoindexter

jpoindexter/dec-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Concepteurs web et d'interfaces numériquesProfessions informatiques et mathématiques·SOC 15-1255

SKILL.md

readonly

name	dec-design-system-depth
description	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.
tags	["design-systems","tokens","components","governance","headless","always-on"]

Design System Depth

A real design system is token architecture + component contracts + governance — not a Figma file of colors.

Three-Tier Token Architecture:
1. Primitive / Global — raw values (blue-500, space-4).
2. Semantic / Alias — intent-mapped (color-action-primary, space-inset-md).
3. Component-Specific — scoped (button-bg-hover). Components only ever consume semantic/component tiers, never primitives.
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.

Plus depuis ce dépôt

même dépôt

dec-accessibility

jpoindexter/dec-skills

Accessibility foundations for design engineers — WCAG / POUR, semantic-HTML-first then ARIA, keyboard and focus management, inclusive design for permanent/temporary/situational constraints. Use when building or reviewing any interactive UI, adding ARIA, implementing modals/menus/forms, or auditing keyboard operability and focus order.

2026-07-130

dec-ai-native-patterns

jpoindexter/dec-skills

AI-native design engineering patterns — generative/adaptive UI, streaming as interaction, prompt-as-interface, human-in-the-loop / agentic UX, eval-driven development, designing for uncertainty, latency and cost as design constraints. Use when designing any AI/LLM-powered feature, building agentic or chat UX, handling streaming/probabilistic output, or planning for model error and cost.

2026-07-130

dec-cognitive-load

jpoindexter/dec-skills

Cognitive Load Theory for interfaces — intrinsic (task difficulty), extraneous (poor-design overhead), and germane (useful mental-model building) load. Use when a screen feels overwhelming, deciding what to simplify vs preserve, chunking complex flows, or diagnosing whether friction comes from the task or the design.

2026-07-130

dec-core-principles

jpoindexter/dec-skills

Foundational design-engineering principles that govern where complexity lives and how interfaces stay fast and consistent — Tesler's Law, progressive disclosure, progressive enhancement, recognition over recall, optimistic UI, perceived performance, single source of truth, constraints as a feature. Use when deciding system architecture vs UI exposure, reducing user-facing complexity, choosing what to render/reveal, or justifying a constraint-driven system.

2026-07-130

dec-css-architecture

jpoindexter/dec-skills

CSS and styling architecture — scaling methodologies (BEM, ITCSS, CUBE CSS) and fluid/responsive technique (mobile-first, clamp() fluid type/space, container queries for component-level responsiveness). Use when structuring stylesheets at scale, choosing a CSS methodology, building responsive layouts, or deciding between media queries and container queries.

2026-07-130

dec-discovery-validation

jpoindexter/dec-skills

Product discovery and validation frameworks — Jobs To Be Done, Continuous Discovery / Opportunity Solution Tree, Lean UX / Build-Measure-Learn, Design Sprint, Working Backwards, Story Mapping, Crazy 8s. Use when scoping what to build, validating an idea before committing, structuring user research, or turning a fuzzy outcome into testable solutions.

2026-07-130

name	dec-design-system-depth
description	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.
tags	["design-systems","tokens","components","governance","headless","always-on"]

Design System Depth

A real design system is token architecture + component contracts + governance — not a Figma file of colors.

Three-Tier Token Architecture:
1. Primitive / Global — raw values (blue-500, space-4).
2. Semantic / Alias — intent-mapped (color-action-primary, space-inset-md).
3. Component-Specific — scoped (button-bg-hover). Components only ever consume semantic/component tiers, never primitives.
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.