Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

zudo-doc-design-system

Estrelas1

Forks0

Atualizado24 de abril de 2026 às 14:45

Project-specific CSS and component rules for zudo-doc. Must be consulted before writing or editing CSS, Tailwind classes, color tokens, or component markup in this project. Covers: component-first strategy, design token system, three-tier color architecture, and palette index convention. Triggered by 'design system', 'zudo-doc-design-system', 'zudo-doc-css-wisdom' (old name).

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

Takazudo

Takazudo/zudo-css-wisdom

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

SKILL.md

readonly

name	zudo-doc-design-system
description	Project-specific CSS and component rules for zudo-doc. Must be consulted before writing or editing CSS, Tailwind classes, color tokens, or component markup in this project. Covers: component-first strategy, design token system, three-tier color architecture, and palette index convention. Triggered by 'design system', 'zudo-doc-design-system', 'zudo-doc-css-wisdom' (old name).
user-invocable	true
argument-hint	[topic: tokens, colors, component-first, palette]

zudo-doc CSS & Component Rules

IMPORTANT: These rules are mandatory for all code changes in this project that touch CSS, Tailwind classes, color tokens, or component markup. Read the relevant section before making changes.

How to Use

Based on the topic, read the specific reference doc:

Topic	File
Spacing, typography, layout tokens	`src/content/docs/reference/design-system.mdx`
Component-first methodology	`src/content/docs/reference/component-first.mdx`
Color tokens, palette, schemes	`src/content/docs/reference/color.mdx`

Read ONLY the file relevant to your task. Apply its rules strictly.

Quick Rules (always apply)

Component First (no custom CSS classes)

NEVER create CSS module files, custom class names, or separate stylesheets
ALWAYS use Tailwind utility classes directly in component markup
The component itself is the abstraction — .card, .btn-primary are forbidden
Use props for variants, not CSS modifiers

Design Tokens (no arbitrary values)

NEVER use Tailwind default colors (bg-gray-500, text-blue-600) — they are reset to initial
NEVER use arbitrary values (text-[0.875rem], p-[1.2rem]) when a token exists
ALWAYS use project tokens: text-fg, bg-surface, border-muted, p-hsp-md, text-small
Spacing: hsp-* (horizontal), vsp-* (vertical) — see design-system.mdx for full list
Typography: text-caption, text-small, text-body, text-heading etc.

Color Tokens (three-tier system)

Tier 1 (palette): p0–p15 — raw colors, use only when no semantic token fits
Tier 2 (semantic): text-fg, bg-surface, border-muted, text-accent — prefer these
NEVER use hardcoded hex values in components
Palette index convention (consistent across all themes):
- p1=danger, p2=success, p3=warning, p4=info, p5=accent
- p8=muted, p9=background, p10=surface, p11=text primary

Search & highlight tokens (role-split)

Highlight roles are deliberately split across dedicated semantic tokens — do not share one token across unrelated highlight UIs.

matched-keyword-bg / matched-keyword-fg — background and foreground of the search panel <mark> element. Driven by --color-matched-keyword-bg / --color-matched-keyword-fg; live-editable in the Design Token Panel. This is the single source of truth for "why is this color yellow in the search results" — the panel swatch matches the rendered highlight 1:1.
warning — drives admonitions (:::warning), find-in-page (.find-match, .find-match-active), and any UI that is semantically a warning. Do not reuse it for new UI-chrome highlights.

Rule: when a new highlight role appears (new kind of mark, new pill, new callout), add a dedicated semantic token rather than bolting it onto --color-warning or another existing token. Each visible highlight color should map to exactly one panel swatch.

hover:underline on link-like elements

Any element that navigates (rendered as <a href> or behaves as a link) MUST have hover:underline focus-visible:underline. Keyboard users need the same affordance as mouse users — never add hover:underline without the focus-visible:underline pair.

Links (do underline): doc content links, sidebar items, header main-nav, header overflow menu items, color-tweak panel unselected tabs, search result rows, footer links, doc history entries, breadcrumb trails, mobile TOC entries.
Controls (do NOT underline): buttons, toggles, sidebar resizer, palette selectors, color swatches, close icons. These use border/bg hover instead.

Precedents to copy the pattern from: src/components/header.astro, src/components/site-tree-nav.tsx, src/components/footer.astro.

See also: /css-wisdom for light-mode / dark-mode contrast rules and the broader three-tier token strategy.

Astro vs React

Default to Astro components (.astro) — zero JS, server-rendered
Use React islands (client:load) only when client-side interactivity is needed
Both follow the same utility-class approach

Mais deste repositório

mesmo repositório

zudo-doc-translate

Takazudo/zudo-css-wisdom

Translate zudo-doc documentation between English and Japanese with project-specific conventions.

2026-04-241

l-writing

Takazudo/zudo-css-wisdom

Writing and formatting rules for MDX articles in zcss. Use when: (1) Writing or editing MDX docs in src/content/docs/, (2) Creating new articles, (3) User says 'writing rules' or 'article format'. Auto-load when working on MDX content.

2026-03-181

b4push

Takazudo/zudo-css-wisdom

Run before-push quality checks for the zudo-css project. Use when: (1) User says 'b4push', 'before push', or 'run checks', (2) Before pushing to remote, (3) After completing implementation work.

2026-03-181

l-handle-deep-article

Takazudo/zudo-css-wisdom

Create or convert CSS best-practices articles into "deep articles" with sub-pages in the zcss Astro site. Use when: (1) An article topic has enough depth to warrant "see more" reference sub-pages, (2) Converting a flat .mdx article into a category with index + child pages, (3) Adding deep reference content to an existing article, (4) User says 'deep article', 'add sub-pages', 'expand article', or 'add reference pages'.

2026-03-181

l-translate

Takazudo/zudo-css-wisdom

Translate English docs to Japanese for the Astro i18n locale. Use when: (1) User wants to translate en docs to ja, (2) User says 'translate', 'ja version', 'Japanese translation', (3) User wants to check for missing ja docs.

2026-03-181

l-demo-component

Takazudo/zudo-css-wisdom

Guidance for using CssPreview component in zcss documentation articles. Use when: (1) Writing or editing CssPreview demos in MDX articles, (2) Deciding whether to use defaultOpen={true} or false, (3) User asks about demo component usage patterns.

2026-03-131

name	zudo-doc-design-system
description	Project-specific CSS and component rules for zudo-doc. Must be consulted before writing or editing CSS, Tailwind classes, color tokens, or component markup in this project. Covers: component-first strategy, design token system, three-tier color architecture, and palette index convention. Triggered by 'design system', 'zudo-doc-design-system', 'zudo-doc-css-wisdom' (old name).
user-invocable	true
argument-hint	[topic: tokens, colors, component-first, palette]

zudo-doc CSS & Component Rules

IMPORTANT: These rules are mandatory for all code changes in this project that touch CSS, Tailwind classes, color tokens, or component markup. Read the relevant section before making changes.

How to Use

Based on the topic, read the specific reference doc:

Topic	File
Spacing, typography, layout tokens	`src/content/docs/reference/design-system.mdx`
Component-first methodology	`src/content/docs/reference/component-first.mdx`
Color tokens, palette, schemes	`src/content/docs/reference/color.mdx`

Read ONLY the file relevant to your task. Apply its rules strictly.

Quick Rules (always apply)

Component First (no custom CSS classes)

NEVER create CSS module files, custom class names, or separate stylesheets
ALWAYS use Tailwind utility classes directly in component markup
The component itself is the abstraction — .card, .btn-primary are forbidden
Use props for variants, not CSS modifiers

Design Tokens (no arbitrary values)

NEVER use Tailwind default colors (bg-gray-500, text-blue-600) — they are reset to initial
NEVER use arbitrary values (text-[0.875rem], p-[1.2rem]) when a token exists
ALWAYS use project tokens: text-fg, bg-surface, border-muted, p-hsp-md, text-small
Spacing: hsp-* (horizontal), vsp-* (vertical) — see design-system.mdx for full list
Typography: text-caption, text-small, text-body, text-heading etc.

Color Tokens (three-tier system)

Tier 1 (palette): p0–p15 — raw colors, use only when no semantic token fits
Tier 2 (semantic): text-fg, bg-surface, border-muted, text-accent — prefer these
NEVER use hardcoded hex values in components
Palette index convention (consistent across all themes):
- p1=danger, p2=success, p3=warning, p4=info, p5=accent
- p8=muted, p9=background, p10=surface, p11=text primary

Search & highlight tokens (role-split)

Highlight roles are deliberately split across dedicated semantic tokens — do not share one token across unrelated highlight UIs.

matched-keyword-bg / matched-keyword-fg — background and foreground of the search panel <mark> element. Driven by --color-matched-keyword-bg / --color-matched-keyword-fg; live-editable in the Design Token Panel. This is the single source of truth for "why is this color yellow in the search results" — the panel swatch matches the rendered highlight 1:1.
warning — drives admonitions (:::warning), find-in-page (.find-match, .find-match-active), and any UI that is semantically a warning. Do not reuse it for new UI-chrome highlights.

hover:underline on link-like elements

Links (do underline): doc content links, sidebar items, header main-nav, header overflow menu items, color-tweak panel unselected tabs, search result rows, footer links, doc history entries, breadcrumb trails, mobile TOC entries.
Controls (do NOT underline): buttons, toggles, sidebar resizer, palette selectors, color swatches, close icons. These use border/bg hover instead.

Precedents to copy the pattern from: src/components/header.astro, src/components/site-tree-nav.tsx, src/components/footer.astro.

See also: /css-wisdom for light-mode / dark-mode contrast rules and the broader three-tier token strategy.

Astro vs React

Default to Astro components (.astro) — zero JS, server-rendered
Use React islands (client:load) only when client-side interactivity is needed
Both follow the same utility-class approach