菜单
Use this skill when creating components, implementing Figma designs, cleaning inconsistent styling, adding or reviewing tokens, spacing, typography, or component variants. Do not use for backend work, feature scoping, or visual QA that requires a live preview instead of design-system decisions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this whenever a PR has a Vercel preview URL and needs browser QA against acceptance criteria — happy path, errors, empty states, responsive behavior, a11y basics — even if the user just says "check the preview". Requires a preview URL. NOT for release/deploy-readiness checks (no preview needed there) — use deploy-ready.
Plan and split work into parallel worktree sessions. Use whenever the user wants to work on multiple tasks at once, mentions parallel sessions, worktrees, "split this up", "dispatch", or lists several independent tasks for one work session.
Use this skill when implementing or reviewing UI that needs semantic HTML, keyboard navigation, focus management, ARIA labels, color contrast, reduced motion, forms, modals, or public-facing pages. Do not use as a standalone product-planning or backend workflow; pair it with design-system-ui, responsive-ui, or vercel-preview-qa when broader UI review is needed.
Use this skill when working across client, agency, consulting, or personal projects where code, data, credentials, prompts, or reusable patterns could leak between contexts. Do not use for ordinary single-project work with no cross-client or cross-workspace boundary risk.
Use this skill when importing ChatGPT or Claude exports, old Notion databases, local notes, or messy knowledge dumps into a durable knowledge system after redaction, deduplication, and classification. Do not use for live project planning, raw unredacted client data, or content that should remain out of Notion.
Use this skill when repeated corrections, a significant feature, a slow debugging session, or a weekly review create evidence for reusable patterns and skill or CLAUDE.md updates. Do not use for one-off annoyances, immediate implementation, or unverified patterns without evidence.
| name | design-system-ui |
| description | Use this skill when creating components, implementing Figma designs, cleaning inconsistent styling, adding or reviewing tokens, spacing, typography, or component variants. Do not use for backend work, feature scoping, or visual QA that requires a live preview instead of design-system decisions. |
Design tokens, spacing, typography, component variants. The source of truth for visual consistency across the project.
Maintain a coherent design system: reuse tokens aggressively, propose new ones only when nothing existing fits, and ensure every component follows the established patterns.
Before UI work or review, read rules/ui.md and apply the project’s responsive, accessibility, component-state, and design-token expectations.
grep -r 'colors\|spacing\|fontSize' tailwind.config.*
Map the design's values against what exists. Reuse aggressively. A new token should only be added when no existing token is close enough.
For any new component: does a similar component already exist? Could this be a variant rather than a new component? Check the existing component library before building from scratch.
New colors, spacing values, or typography scales must be proposed and approved before adding. Include a justification: what existing token doesn't work and why.
Tokens use semantic names (not raw values):
background, surface, accent, muted — not blue-500space-1 through space-8 or xs/sm/md/lg/xltext-sm, text-base, text-lg — not 14px# Design system review — [component/feature]
## Tokens reused: [list]
## New tokens proposed: [list with justification]
## Component variants: [new vs variant of existing]
## Consistency issues found: [list]
figma-lovable-handoff — produces token maps this skill evaluatesresponsive-ui — spacing tokens must work across breakpointsaccessibility-ui — color tokens must meet contrast requirementsToken sprawl — Every design adds 3 new colors. Three months later you have 60 colors and no system. Push back on additions.
Raw values in components — text-[14px] instead of text-sm. Kills consistency when you later change the scale.
Spacing improvisation — Padding and gaps chosen by eye (mt-[13px], gap-[7px]) instead of from the spacing scale. Individually invisible; in aggregate the UI reads as subtly misaligned. Snap every spacing value to the scale (space-2, gap-4) and propose a new step only if nothing fits.