技能介绍

要解决的问题

设计 token 常常散落在仓库各处：CSS / theme files / Tailwind config / styled-components helpers / SCSS partials 里各有一份颜色、字体和间距定义；截图或 Figma 设计稿又把这些信息锁在视觉层。下游 token-map 想把这些 token crosswalk 到当前 OD design system 时，如果仍是分散、不可审计的证据，就很难判断哪个 token 来自哪里、被哪些组件使用，也难以处理找不到目标 token 的情况。

技能如何工作

这个 atom 只负责“lifting”：把分散的 token 证据集中到一个 token bag，输出 code/tokens.json。输入形态故意保持通用：

code/index.json：来自 code-import，用于 code-migration；
figma/tree.json：来自 figma-extract，用于 figma-migration；
一个截图文件夹：用于 tune-collab quick-tune flows。

实现上，daemon runner 会扫描已索引的 source files，提取 CSS、Tailwind 和 JavaScript token evidence，并写入 code/tokens.json。每个 token entry 携带 sources[] 与 usage[]，作为审计轨迹；当 token-map.unmatched.json 找不到目标 token 时，可以回查这些来源和使用位置。收敛条件是 code/tokens.json 存在；空 token bag 只会发出 warning，不中断流程，后续 token-map 会跳过 mapping pass。

适用边界与注意点

它适合做迁移前的 token 汇总，而不是替代完整 design audit：既不会判断设计是否合理，也不会自动补全缺失 token。遇到 color: '#fff' 这类 JSX 字面量硬编码时，必须记录为 kind: 'color' 并生成 synthetic name，避免它混入噪声；扫描 Tailwind utility 时，也要按 active theme 对 palette references 去重，不能把 bg-blue-500 和 bg-blue-600 当成同一个 token。