extract 是 better-web-ui 技能集中的一个技能，用途是把可复用的组件、产品模式与设计令牌抽取出来，整合进设计系统，以实现系统化复用。其目标不是把代码库里的每个值都收进来，而是建立受约束的系统，减少未来的设计决策并保持界面一致。使用时应参考设计系统对齐资料，理解令牌、组件与模式的区别、漂移问题，以及如何避免把不一致变成令牌泛滥。
【强制准备】用户以 /extract 启动该工作流。该技能激活后需加载 $frontend-design，其中包含设计原则、反模式与上下文收集协议，须先遵循该协议；若尚不存在设计上下文，必须先加载 $setup。
【发现阶段】分析目标区域以识别抽取机会：定位设计系统、组件库或共享 UI 目录（可搜索 design system、ui、components 等词），理解其结构，包括组件组织与命名约定、设计令牌结构（如有）、文档模式、导入导出约定。关键点：若不存在设计系统，需先询问再创建，先弄清偏好的位置与结构。识别模式，包括：重复组件（按钮、卡片、输入框等被多次使用的相似 UI 模式）、硬编码值（本应成为令牌的颜色、间距、字体、阴影）、不一致变体（同一概念的多种实现，如三种按钮样式）、可复用模式（值得系统化的布局、组合与交互模式）、缺失的系统（团队反复重新解决间距、字体、颜色、圆角或高度问题的地方）。评估价值：并非所有东西都该抽取，需考虑是否已使用 3 次以上或很可能被复用、系统化是否提升一致性、是通用模式还是特定上下文、维护成本与收益对比。
【抽取计划】制定系统化抽取计划：要抽取为可复用组件的 UI 元素、要创建的令牌（哪些硬编码值转为设计令牌）、系统边界（哪些令牌集应有意识地保持精简，以引导决策而非记录混乱）、每个组件需支持的变体、与既有模式一致的组件名/令牌名/prop 名等命名约定、迁移路径（如何把现有用法重构为使用新的共享版本）。重要提示：设计系统是增量成长的，只抽取当下明确可复用的部分，而不是未来某个时候可能可复用的全部。
【已有组件库时的抽取】若项目已使用 shadcn/ui 等库，优先抽取本地包装、可复用组合与有文档的模式；除非项目确实需要稳定的定制抽象，否则不要用冗余的本地副本替代上游基础组件。好的抽取往往位于库基础组件之上的一层：不是又一个通用 Button，而是使用既有基础组件、保持一致的产品级操作栏、筛选面板、设置区块或空状态模式。
【抽取与充实】构建改进后的可复用版本。组件应具备：清晰的 props API 与合理默认值、面向不同用例的恰当变体、内置无障碍（ARIA、键盘导航、焦点管理）、文档与用法示例。设计令牌应具备：清晰命名（基础令牌与语义令牌）、合理的层级与组织、每个令牌何时使用的说明、在适用处对间距、字体、颜色、圆角与高度的受约束刻度。推荐的做法是：间距采用有意义的少量档位，而非 4 到 64 之间每个数字；字体采用为 UI 角色手工制作的一组字号与字重；颜色定义色阶，而非临时明暗变化；高度用少量有语义的阴影，而非无尽的定制 box-shadow。模式应记录何时使用、代码示例、变体与组合。绝不要：抽取未做泛化的一次性、特定上下文实现；创建过于通用而无用的组件；不考虑现有设计系统约定就抽取；跳过正确的 TypeScript 类型或 prop 文档；为每个值创建令牌（令牌应有语义）；把不一致变成令牌目录，而不是简化成系统。
【迁移】用新的共享版本替换现有用法：找到所有实例，系统化替换每一处用法，充分测试以保证视觉与功能一致，删除死代码，移除旧实现。
【文档】更新设计系统文档：把新组件加入组件库，记录令牌用法与数值，添加示例与指南，更新 Storybook 或组件目录。该技能强调：好的设计系统是活的系统，应随模式出现而抽取、审慎充实并持续维护。