一键在 Manus 中运行任何 Skill

design-tokens

星标3

分支0

更新时间2026年6月23日 10:30

This skill should be used when a user wants to scaffold or refactor a design token system — e.g. "set up design tokens", "create a design system foundation", "extract these hardcoded colors into tokens", "add a type scale", "theming setup", or "dark mode tokens". It produces a single source of truth for color, type, spacing, radius, shadow, motion, and z-index, emitted in the format the detected stack expects.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

TimboGP

TimboGP/timbogp-marketplace

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Design Tokens

Establish a coherent, themeable design token foundation — or migrate an existing codebase of hardcoded values onto one — adapted to whatever stack the project already uses. Tokens are the contract every other UX skill builds on: components should reference token names, never raw values.

When to use

Reach for this skill when the request resembles:

"set up design tokens" / "create a design system foundation"
"extract these hardcoded colors into tokens" / "replace these hex codes"
"add a type scale" / "give me a modular scale"
"theming setup" / "support multiple brands"
"dark mode tokens" / "add a dark theme"

Two operating modes share most of the workflow:

Scaffold — no token system exists; create one from the starter assets.
Migration — values are hardcoded across the codebase; introduce tokens and replace usages incrementally.

Step 1 — Detect the stack

Before generating anything, READ ../ux-foundations/references/stack-detection.md and run the procedure. Do not duplicate it here. Hold the resulting decisions:

framework   = react | vue | svelte | angular | vanilla
styling     = tailwind | css-in-js | css-modules | sass | vanilla-css
tokenFormat = <per stack-detection §3>
language    = ts | js

Report the detection in one line, then proceed. Extend any existing token names rather than inventing a parallel set.

Step 2 — Define token categories

Design the full set up front so categories stay consistent. Use the starter assets as the baseline and adjust values to the project's brand.

Color — use semantic layering. Keep a small primitive palette (a neutral ramp plus a brand ramp). Never expose primitives to components. Map them to semantic roles: --color-bg, --color-surface, --color-fg, --color-muted-fg, --color-primary, --color-primary-fg, --color-border, and state colors (--color-success, --color-warning, --color-danger) each with a readable foreground variant. Verify contrast of every fg/bg pair (see scripts/contrast-check.mjs) before shipping — semantic roles are promises about legibility.
Type scale — a modular scale (--font-size-xs … --font-size-3xl) in rem. Generate with scripts/type-scale.mjs.
Spacing scale — a 4px-based ramp (--space-1 … --space-12).
Radius — --radius-sm/md/lg/full.
Shadow / elevation — --shadow-sm/md/lg.
Motion — durations (--duration-fast/base/slow) and easings (--ease-standard, --ease-emphasized).
Z-index — a few named layers (dropdown, modal, etc.).
Breakpoints — named min-widths for responsive logic.

Step 3 — Emit in the stack's format

Translate the canonical tokens into what the project consumes. Keep assets/tokens.json (DTCG) as the portable source of truth regardless of output.

Vanilla CSS / CSS Modules / Sass — CSS custom properties on :root (start from assets/tokens.css). Components use var(--token). Prefer custom properties over SCSS variables so themes can switch at runtime.
Tailwind v3 — extend theme.extend in tailwind.config.*, mapping tokens to scale keys (colors, fontSize, spacing, borderRadius, boxShadow). For runtime theming, point Tailwind colors at CSS custom properties.
Tailwind v4 — declare tokens in a @theme { --color-…: … } block in CSS.
CSS-in-JS (styled-components / Emotion) — a typed theme object exported for <ThemeProvider>; emit a TypeScript type when language = ts.
Portable — assets/tokens.json in DTCG format feeds Style Dictionary or similar pipelines when one exists.

Step 4 — Theming (light / dark)

Support at least light and dark. Two complementary mechanisms:

Explicit — override semantic roles under [data-theme="dark"] so a parent attribute (or a toggle) controls the theme. This is the default; it allows a manual switch.
System — mirror the dark overrides inside a @media (prefers-color-scheme: dark) block so first paint respects the OS setting before any JS runs.

Only semantic roles change between themes — primitives and the type/spacing scales stay fixed. assets/tokens.css ships both blocks as a model.

Step 5 — Migration mode

When the codebase is full of literals, introduce tokens without a risky big-bang rewrite:

Inventory — grep for hardcoded values:
- hex colors: #[0-9a-fA-F]{3,8}\b
- rgb/rgba/hsl: rgba?\( / hsla?\(
- px font sizes: font-size:\s*\d+px
- px spacing on margin/padding/gap.
Map — for each literal find the nearest semantic token (closest color by contrast/role, nearest step on the type or spacing scale). Note ambiguous ones for review instead of guessing.
Replace incrementally — swap literals for var(--token) (or the stack's equivalent) file-by-file, presenting diffs and verifying nothing shifts visually. Add missing tokens rather than forcing a bad fit.
Guard — once migrated, treat new raw values in components as a smell; contrast-check.mjs can gate CI on the color pairs.

Principles

Single source of truth — define each value once; everything derives from it.
Semantic over literal — name by role (--color-danger), not by appearance (--color-red-500). Roles survive rebrands and theme switches.
No raw values in components — components reference token names only.
Keep the primitive palette small — a tight neutral ramp plus one brand ramp covers most needs; sprawl defeats the system.
Contrast is non-negotiable — every fg/bg pairing must meet WCAG AA.

Bundled files

Reference and reuse these:

assets/tokens.css — starter CSS custom properties on :root with a [data-theme="dark"] override; the canonical CSS baseline.
assets/tokens.json — the same tokens in W3C DTCG format; the portable source of truth for tooling.
scripts/type-scale.mjs — generate a modular type scale. Usage: node type-scale.mjs [basePx=16] [ratio=1.25] [stepsUp=6] [stepsDown=2]. Prints a px/rem table plus paste-ready --font-size-* custom properties.
scripts/contrast-check.mjs — verify token color pairs meet WCAG 2.x. Usage: node contrast-check.mjs "#111:#fff" "#777:#fff" or no args to check a built-in default set. Exits non-zero if any pair fails AA normal (CI-friendly).

References

Stack detection: ../ux-foundations/references/stack-detection.md

同仓库更多 Skills

同仓库

adjust-level

TimboGP/timbogp-marketplace

Adjust the difficulty level of a learning sub-project's curriculum — simplify a too-advanced curriculum into a gentler on-ramp, or deepen a too-introductory one into something with real teeth. Use whenever the user signals the curriculum's level doesn't match their starting point — phrases like "this paper is too hard, can we build up to it?", "simplify the curriculum", "make it easier", "go more advanced", "I want a more rigorous version", "this is too basic, push deeper", "I need an intro version of this", or "create a simpler/harder curriculum from this material". The skill is allowed to pull in external materials and training knowledge to fill the gap between the source's natural level and the target level, but every external addition is explicitly labeled — the user always knows what came from their own source materials and what came from elsewhere.

2026-07-073

bootstrap

TimboGP/timbogp-marketplace

Scaffold a new learning sub-project under the agentic-study-environment harness — create the directory, generate per-project AGENTS.md, CLAUDE.md, and PROGRESS.md from templates, and register the new project in the .studyenv/PROGRESS.md cross-project tracker. Use this skill whenever the user wants to start studying a new topic, paper, book, language, or domain with the tutor harness — phrases like "bootstrap a new project to learn X", "start a new sub-project for Y", "set up a learning project on Z", or "create a sub-project to study W" should all trigger this skill. Do not use for general project scaffolding outside the agentic-study-environment harness.

2026-07-073

help

TimboGP/timbogp-marketplace

Explain the agentic-study-environment plugin — what it does, the lifecycle skills it ships, the domain overlays, the session types, and the key conventions — or a specific one of those if the user names it. Use this skill whenever the user asks for help with the study harness itself rather than asking to study something: phrases like "help with agentic-study-environment", "what can the study harness do", "how does this plugin work", "list the study skills", "how do I use set-curriculum", "what domains are there", "explain session types", or the /study-help command. With no topic, give the full overview; with a named skill, overlay, session type, or convention, explain just that. Do NOT use this to bootstrap, set a curriculum, or run a session — those are the lifecycle skills.

2026-07-073

onboard-session

TimboGP/timbogp-marketplace

Begin a bracketed onboarding session over an existing artifact you didn't author — a codebase, a document corpus, a body of papers — inside a agentic-study-environment sub-project. The agent surveys the artifact, walks it part by part with comprehension checks, then has the user reproduce a recent change from its history. Use whenever the user signals they want to get up to speed on something someone else made — phrases like "onboard me on this codebase", "walk me through this repo", "help me get up to speed on X", "I just joined this project", "drop me into this codebase", or "get familiar with this corpus" should trigger this skill. `onboarding` is the fourth core session type; unlike `theory`/`practice`/`role-play` it has its own dedicated entry point rather than being proposed inside `start-session`. A session ends with the `stop-session` skill.

2026-07-073

set-curriculum

TimboGP/timbogp-marketplace

Build or update the teaching curriculum for a learning sub-project from its source materials. Use whenever the user wants to plan, structure, or refresh the learning path for a sub-project — phrases like "set curriculum for X", "update the curriculum", "plan the teaching path", "build a curriculum from these materials", or general intent to organize source material into an ordered teaching plan. This skill reads the sub-project's source materials and writes ai-agent-materials/curriculum.md. It does not start a session and does not update PROGRESS.md.

2026-07-073

start-session

TimboGP/timbogp-marketplace

Begin a bracketed learning session inside a agentic-study-environment sub-project — pick a topic, propose theory vs. practice (or an overlay-specific type such as simulation or defense), and conduct it per the sub-project's domain overlay. Use whenever the user signals they want to actively study, work an exercise, role-play a clinical case, rehearse a research defense, or review theory inside a sub-project — phrases like "start session", "let's work on X", "begin a practice session", "ok let's study Y", or "I want to do an exercise on Z" should trigger this skill. A session is the harness's unit of work and ends with the stop-session skill.

2026-07-073

name	design-tokens
description	This skill should be used when a user wants to scaffold or refactor a design token system — e.g. "set up design tokens", "create a design system foundation", "extract these hardcoded colors into tokens", "add a type scale", "theming setup", or "dark mode tokens". It produces a single source of truth for color, type, spacing, radius, shadow, motion, and z-index, emitted in the format the detected stack expects.
version	0.1.0

Design Tokens

When to use

Reach for this skill when the request resembles:

"set up design tokens" / "create a design system foundation"
"extract these hardcoded colors into tokens" / "replace these hex codes"
"add a type scale" / "give me a modular scale"
"theming setup" / "support multiple brands"
"dark mode tokens" / "add a dark theme"

Two operating modes share most of the workflow:

Scaffold — no token system exists; create one from the starter assets.
Migration — values are hardcoded across the codebase; introduce tokens and replace usages incrementally.

Step 1 — Detect the stack

Before generating anything, READ ../ux-foundations/references/stack-detection.md and run the procedure. Do not duplicate it here. Hold the resulting decisions:

framework   = react | vue | svelte | angular | vanilla
styling     = tailwind | css-in-js | css-modules | sass | vanilla-css
tokenFormat = <per stack-detection §3>
language    = ts | js

Report the detection in one line, then proceed. Extend any existing token names rather than inventing a parallel set.

Step 2 — Define token categories

Design the full set up front so categories stay consistent. Use the starter assets as the baseline and adjust values to the project's brand.

Color — use semantic layering. Keep a small primitive palette (a neutral ramp plus a brand ramp). Never expose primitives to components. Map them to semantic roles: --color-bg, --color-surface, --color-fg, --color-muted-fg, --color-primary, --color-primary-fg, --color-border, and state colors (--color-success, --color-warning, --color-danger) each with a readable foreground variant. Verify contrast of every fg/bg pair (see scripts/contrast-check.mjs) before shipping — semantic roles are promises about legibility.
Type scale — a modular scale (--font-size-xs … --font-size-3xl) in rem. Generate with scripts/type-scale.mjs.
Spacing scale — a 4px-based ramp (--space-1 … --space-12).
Radius — --radius-sm/md/lg/full.
Shadow / elevation — --shadow-sm/md/lg.
Motion — durations (--duration-fast/base/slow) and easings (--ease-standard, --ease-emphasized).
Z-index — a few named layers (dropdown, modal, etc.).
Breakpoints — named min-widths for responsive logic.

Step 3 — Emit in the stack's format

Translate the canonical tokens into what the project consumes. Keep assets/tokens.json (DTCG) as the portable source of truth regardless of output.

Vanilla CSS / CSS Modules / Sass — CSS custom properties on :root (start from assets/tokens.css). Components use var(--token). Prefer custom properties over SCSS variables so themes can switch at runtime.
Tailwind v3 — extend theme.extend in tailwind.config.*, mapping tokens to scale keys (colors, fontSize, spacing, borderRadius, boxShadow). For runtime theming, point Tailwind colors at CSS custom properties.
Tailwind v4 — declare tokens in a @theme { --color-…: … } block in CSS.
CSS-in-JS (styled-components / Emotion) — a typed theme object exported for <ThemeProvider>; emit a TypeScript type when language = ts.
Portable — assets/tokens.json in DTCG format feeds Style Dictionary or similar pipelines when one exists.

Step 4 — Theming (light / dark)

Support at least light and dark. Two complementary mechanisms:

Explicit — override semantic roles under [data-theme="dark"] so a parent attribute (or a toggle) controls the theme. This is the default; it allows a manual switch.
System — mirror the dark overrides inside a @media (prefers-color-scheme: dark) block so first paint respects the OS setting before any JS runs.

Only semantic roles change between themes — primitives and the type/spacing scales stay fixed. assets/tokens.css ships both blocks as a model.

Step 5 — Migration mode

When the codebase is full of literals, introduce tokens without a risky big-bang rewrite:

Inventory — grep for hardcoded values:
- hex colors: #[0-9a-fA-F]{3,8}\b
- rgb/rgba/hsl: rgba?\( / hsla?\(
- px font sizes: font-size:\s*\d+px
- px spacing on margin/padding/gap.
Map — for each literal find the nearest semantic token (closest color by contrast/role, nearest step on the type or spacing scale). Note ambiguous ones for review instead of guessing.
Replace incrementally — swap literals for var(--token) (or the stack's equivalent) file-by-file, presenting diffs and verifying nothing shifts visually. Add missing tokens rather than forcing a bad fit.
Guard — once migrated, treat new raw values in components as a smell; contrast-check.mjs can gate CI on the color pairs.

Principles

Single source of truth — define each value once; everything derives from it.
Semantic over literal — name by role (--color-danger), not by appearance (--color-red-500). Roles survive rebrands and theme switches.
No raw values in components — components reference token names only.
Keep the primitive palette small — a tight neutral ramp plus one brand ramp covers most needs; sprawl defeats the system.
Contrast is non-negotiable — every fg/bg pairing must meet WCAG AA.

Bundled files

Reference and reuse these:

assets/tokens.css — starter CSS custom properties on :root with a [data-theme="dark"] override; the canonical CSS baseline.
assets/tokens.json — the same tokens in W3C DTCG format; the portable source of truth for tooling.
scripts/type-scale.mjs — generate a modular type scale. Usage: node type-scale.mjs [basePx=16] [ratio=1.25] [stepsUp=6] [stepsDown=2]. Prints a px/rem table plus paste-ready --font-size-* custom properties.
scripts/contrast-check.mjs — verify token color pairs meet WCAG 2.x. Usage: node contrast-check.mjs "#111:#fff" "#777:#fff" or no args to check a built-in default set. Exits non-zero if any pair fails AA normal (CI-friendly).

References

Stack detection: ../ux-foundations/references/stack-detection.md