Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

dec-design-system-depth

Estrellas0

Forks0

Actualizado13 de julio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

jpoindexter

jpoindexter/dec-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Diseñadores de interfaces web y digitalesOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.