design-system-aware（设计系统意识）

Design System Aware Code Generation

Trigger condition: This skill activates when ANY .tsx or .jsx file inside src/ or app/ is being created or modified, AND .claude/design-tokens/design-tokens.json exists.

When writing or editing React/Next.js frontend code in this project, follow these rules:

Before Writing Code

1. Check if .claude/design-tokens/design-tokens.json exists.
2. If it exists, read it and use it as the source of truth for all design decisions.
3. Check the components section before creating any new component — reuse what exists.

Token Usage

• All colors, spacing, font sizes, shadows, and border radii must come from .claude/design-tokens/design-tokens.json.
• Never hardcode design values. No raw hex colors, no magic number padding or margins.
• Use the project's styling approach as specified in styling_approach.

Preferred Library Conventions

• If preferred_libraries exists in design-tokens.json, always use the selected library for each capability category.
• Data fetching: use whatever is at preferred_libraries.data_fetching.selected. If React Query, use useQuery/useMutation. If SWR, use useSWR. If axios, use the project's axios instance. Never use an alternative library that is installed but not selected.
• Dates: use whatever is at preferred_libraries.dates.selected. Never mix date libraries (e.g., don't use moment if date-fns is selected).
• Forms, validation, icons, animation, charts, etc.: same rule — always use the selected library for each category.
• Follow the project's error handling and loading state patterns as documented in the api section.
• Place API-related code in the same directory structure the project already uses.

Component Reusability

• If a UI pattern appears 2+ times, extract it into a reusable component. A pattern is "repeated" if 2+ elements share the same HTML structure (same nesting, same tag types) AND the same visual styling (same colors, spacing, border treatment). Different text content does not make a pattern different.
• New components must be props-driven. No hardcoded content inside components.
• Compose complex UI from small pieces: a PageHeader uses Heading + Breadcrumbs + ActionBar.
• Sub-component extraction rule: Extract sub-components into separate files if they exceed 15 lines. Sub-components of 15 lines or fewer may stay in the parent file.

SOLID

• Single Responsibility: One component, one job.
• Open/Closed: Extend via props and composition, not source modification.
• Interface Segregation: Don't bloat props. Split if needed.
• Dependency Inversion: Depend on props and hooks, not concrete implementations.

DRY

• Shared logic → custom hooks.
• Shared layout → layout components.
• Shared styles → design tokens.
• No copy-paste between components.