Back to Details

extract

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
The goal is not to capture every value in the codebase. The goal is to create constrained systems that reduce future design decisions and keep the interface coherent.
Consult the design-system alignment reference for tokens vs components vs patterns, drift, and how to avoid turning inconsistency into token sprawl.
识别可复用的模式、组件和 Design Token，然后提取并整合到设计系统中，以便系统化复用。
其目标不是记录代码库中的每一个值，而是创建受约束的系统，减少未来的设计决策，并保持界面协调一致。
请参阅设计系统对齐参考文档，了解 Token、组件与模式之间的区别、体系漂移，以及如何避免将不一致性转化为 Token 泛滥。

MANDATORY PREPARATION

强制准备

Users start this workflow with 
/extract
. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first.
用户通过 
/extract
启动此工作流。此 Skill 激活后，需加载 $frontend-design——其中包含设计原则、反模式以及 Context Gathering Protocol（上下文收集协议）。继续执行前必须遵循该协议；如果尚不存在设计上下文，则必须先加载 $setup。

Discover

发现

Analyze the target area to identify extraction opportunities:
  1. Find the design system: Locate your design system, component library, or shared UI directory (grep for "design system", "ui", "components", etc.). Understand its structure:
    • Component organization and naming conventions
    • Design token structure (if any)
    • Documentation patterns
    • Import/export conventions
    CRITICAL: If no design system exists, ask before creating one. Understand the preferred location and structure first.
  2. Identify patterns: Look for:
    • Repeated components: Similar UI patterns used multiple times (buttons, cards, inputs, etc.)
    • Hard-coded values: Colors, spacing, typography, shadows that should be tokens
    • Inconsistent variations: Multiple implementations of the same concept (3 different button styles)
    • Reusable patterns: Layout patterns, composition patterns, interaction patterns worth systematizing
  • Missing systems: Places where the team is clearly re-solving spacing, type, color, radius, or elevation repeatedly
  1. Assess value: Not everything should be extracted. Consider:
    • Is this used 3+ times, or likely to be reused?
    • Would systematizing this improve consistency?
    • Is this a general pattern or context-specific?
    • What's the maintenance cost vs benefit?
分析目标区域，识别可提取的机会：
  1. 查找设计系统：定位设计系统、组件库或共享 UI 目录（grep "design system"、"ui"、"components" 等）。了解其结构：
    • 组件组织和命名约定
    • Design Token 结构（如果存在）
    • 文档编写模式
    • 导入/导出约定
    关键：如果不存在设计系统，在创建之前必须先询问用户。了解首选位置和结构。
  2. 识别模式：查找：
    • 重复组件：多次使用的相似 UI 模式（按钮、卡片、输入框等）
    • 硬编码值：应转化为 Token 的颜色、间距、排版和阴影
    • 不一致变体：同一概念存在多种实现方式（例如 3 种不同的按钮样式）
    • 可复用模式：值得系统化处理的布局模式、组合模式和交互模式
    • 缺失的系统：团队明显在反复重新解决间距、字号、颜色、圆角或阴影层级问题的位置
  3. 评估价值：并非所有内容都应被提取。考虑：
    • 是否使用了 3 次以上，或者很可能被复用？
    • 系统化处理能否提升一致性？
    • 它是一般性模式，还是特定于上下文？
    • 维护成本与收益相比如何？

Plan Extraction

规划提取

Create a systematic extraction plan:
  • Components to extract: Which UI elements become reusable components?
  • Tokens to create: Which hard-coded values become design tokens?
  • System boundaries: Which token sets should stay intentionally small so they guide decisions instead of documenting chaos?
  • Variants to support: What variations does each component need?
  • Naming conventions: Component names, token names, prop names that match existing patterns
  • Migration path: How to refactor existing uses to consume the new shared versions
IMPORTANT: Design systems grow incrementally. Extract what's clearly reusable now, not everything that might someday be reusable.
制定系统化的提取计划：
  • 要提取的组件：哪些 UI 元素将成为可复用组件？
  • 要创建的 Token：哪些硬编码值将成为 Design Token？
  • 系统边界：哪些 Token 集合应有意保持精简，以指导决策，而不是记录混乱？
  • 需要支持的变体：每个组件需要支持哪些变化形式？
  • 命名约定：与现有模式一致的组件名称、Token 名称和 Prop 名称
  • 迁移路径：如何重构现有用法，使其使用新的共享版本
重要：设计系统是逐步成长的。只提取当前明确可复用的内容，不要提取未来可能复用的所有内容。

Extraction when a component library already exists

项目已有组件库时的提取方式

If the project already uses a library such as 
shadcn/ui
, prefer extracting:
  • local wrappers
  • reusable compositions
  • documented patterns
Do not replace upstream primitives with redundant local copies unless the project truly needs a stable customized abstraction.
A good extraction often sits one layer above the library primitive: not another generic 
Button
, but a product-specific action bar, filter panel, settings section, or empty-state pattern that uses the existing primitives consistently.
如果项目已经使用 
shadcn/ui
等库，优先提取：
  • 本地包装组件
  • 可复用组合
  • 已文档化的模式
除非项目确实需要稳定且定制化的抽象，否则不要用冗余的本地副本替换上游 Primitive。
好的提取通常位于库 Primitive 的上一层：不要再创建一个通用的 
Button
，而是创建产品特定的操作栏、筛选面板、设置区块或空状态模式，并一致地使用现有 Primitive。

Extract & Enrich

提取与完善

Build improved, reusable versions:
  • Components: Create well-designed components with:
    • Clear props API with sensible defaults
    • Proper variants for different use cases
    • Accessibility built in (ARIA, keyboard navigation, focus management)
    • Documentation and usage examples
  • Design tokens: Create tokens with:
    • Clear naming (primitive vs semantic)
    • Proper hierarchy and organization
    • Documentation of when to use each token
    • Constrained scales for spacing, typography, color, radius, and elevation where applicable
Prefer systems like:
  • Spacing: A small scale with meaningful jumps, not every number between 4 and 64
  • Typography: A hand-crafted set of sizes and weights for UI roles
  • Color: Defined ramps instead of ad-hoc lighten/darken variations
  • Elevation: A few shadows with semantic meaning, not endless custom box-shadows
  • Patterns: Document patterns with:
    • When to use this pattern
    • Code examples
    • Variations and combinations
NEVER:
  • Extract one-off, context-specific implementations without generalization
  • Create components so generic they're useless
  • Extract without considering existing design system conventions
  • Skip proper TypeScript types or prop documentation
  • Create tokens for every single value (tokens should have semantic meaning)
  • Turn inconsistency into a token catalog instead of simplifying it into a system
构建改进后的可复用版本：
  • 组件：创建设计良好的组件，包括：
    • 清晰的 Props API，并提供合理的默认值
    • 适用于不同用例的恰当变体
    • 内置无障碍支持（ARIA、键盘导航、焦点管理）
    • 文档和使用示例
  • Design Token：创建具备以下特点的 Token：
    • 清晰的命名，区分 Primitive 与 Semantic
    • 合理的层级和组织方式
    • 说明每个 Token 的使用时机
    • 在适用的情况下，为间距、排版、颜色、圆角和阴影层级建立受约束的刻度体系
优先采用以下系统：
  • 间距：使用具有明确级差的小型刻度体系，而不是收录 4 到 64 之间的每个数字
  • 排版：为 UI 角色手工编排一组字号和字重
  • 颜色：定义色阶，而不是临时进行调亮或调暗
  • 阴影层级：提供少量具有语义的阴影，而不是无限增加自定义 box-shadow
  • 模式：记录以下内容：
    • 何时使用该模式
    • 代码示例
    • 变体和组合方式
绝不：
  • 提取仅供单次使用、且未经泛化的上下文专用实现
  • 创建过于通用以至于毫无实际用途的组件
  • 在未考虑现有设计系统约定的情况下进行提取
  • 省略恰当的 TypeScript 类型或 Prop 文档
  • 为每一个单独的值创建 Token（Token 应具有明确语义）
  • 把不一致性塞进 Token 目录，而不是将其简化成一套系统

Migrate

迁移

Replace existing uses with the new shared versions:
  • Find all instances: Search for the patterns you've extracted
  • Replace systematically: Update each use to consume the shared version
  • Test thoroughly: Ensure visual and functional parity
  • Delete dead code: Remove the old implementations
使用新的共享版本替换现有用法：
  • 查找所有实例：搜索已提取的模式
  • 系统化替换：更新每处用法，使其使用共享版本
  • 全面测试：确保视觉与功能保持一致
  • 删除废弃代码：移除旧实现

Document

编写文档

Update design system documentation:
  • Add new components to the component library
  • Document token usage and values
  • Add examples and guidelines
  • Update any Storybook or component catalog
Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
更新设计系统文档：
  • 将新组件添加到组件库
  • 记录 Token 的用法和取值
  • 添加示例和指南
  • 更新 Storybook 或组件目录
请记住，良好的设计系统是一个持续演进的系统。随着模式逐渐出现，及时提取它们、 thoughtfully 地完善它们，并始终如一地维护它们。