本技能用于将没有设计系统的生产应用转换为规范的设计系统，流程覆盖从应用分析到组件库搭建的完整链路。
用途与场景 当团队用 AI 快速生成产品，代码能运行但缺少统一的设计系统，导致组件不一致、无法复用、无法版本化时，可使用本技能。它适用的输入是一个或多个目标应用的绝对路径，最终产出组件清单、DTCG 令牌、Storybook 包，并可选同步至 Figma。
两种收尾方式
- 代码主导型组织：停留在 Storybook 包，它成为可打包并重新导入产品的版本化事实来源。
- 设计主导型组织：继续进入 Figma，令牌变为变量，关键组件变为 Figma 组件集。
工具模式 首选方式是连接 figma-console-mcp（本地模式），使用五个 figma_ds_* 工具，它们确定性强、受控，并在 <outDir>/.extraction/ 下持久化清单，使工作能跨越会话边界。回退方式是没有控制台 MCP 时，自行用 Read/Grep/Bash 完成相同阶段，保持相同的产物结构（自行编写 analysis.json、DTCG tokens/tokens.json 及相同的包布局），Figma 往返使用 figma-import-tokens 技能。
各阶段概要 阶段 0 发现：先与用户确认目标应用路径、代码主导或设计主导、品牌命名上下文、设计系统存放位置。 阶段 1 分析：运行 figma_ds_analyze，查看架构块（specializations 是用法命名的组件，missingPrimitives 是待构建的通用组件清单，levels 是原子设计解读）。之后进行泛化处理：将缺失的原语构建为通用组件，把特化组件重新表达为配方（story 或薄包装），按选定层次组织 Storybook。分类处理：vendored 和 bespoke 按原样移植，wrapped 保留供应商包为 peer 依赖，pure-vendor 不移植仅由主题/令牌和用法文档表示。duplicateGroups 需与用户确定规范版本。移植顺序按工具的使用排名。 阶段 2 提取令牌：运行 figma_ds_extract_tokens，已声明令牌保留名称并携带来源，.dark 值成为真正的 Light/Dark 多模式结构。推断令牌需与用户复核。语义命名是人工工作：在 tokens/tokens.json 中添加语义别名令牌，引用原语，不删除原语。 阶段 3 脚手架与 Storybook：运行 figma_ds_scaffold，安装依赖并初始化 Storybook，再运行 figma_ds_setup_storybook 连接工作坊与提取结果，生成 preview.css、复制字体、修补配置文件，应用手动步骤后重启开发服务器。 阶段 4 移植组件：按使用排名逐个组件，运行 figma_ds_extract_component 获取源码、导入闭包、属性契约等，移植到独立目录，解耦应用特定导入，用令牌替换硬编码值，适配 story 脚手架，在 Storybook 中视觉验证，用 figma_ds_status 更新状态。 阶段 5 代码主导收尾：生成可构建、可版本化的包，设置发布/版本管理，产品改为消费 @org/design-system。 阶段 6 设计主导进入 Figma：用 figma_import_tokens 导入令牌为变量（先 dry-run 预览），用现有工具将关键组件重建为组件集，绑定填充/描边/圆角到导入变量。之后同步循环为 figma_export_tokens / figma_import_tokens 的差异感知合并。
边界与注意事项 figma_ds_* 工具仅限本地模式；提取不会修改目标应用，所有产物落在 outDir 下；始终使用绝对路径；不要手动编辑生成的文件（如 tokens.css），应编辑 tokens.json 或源应用后重新生成；每个令牌的来源信息保存在 $extensions["figma-console-mcp.extraction"] 中。