token-mapping

Token 映射

1. 加载规则：references/mapping-rules.md、AGENTS.md 或 CLAUDE.md，以及 docs/system/decisions.md。记录覆盖项和优先级规则。
2. 加载列表，并记录其名称、格式、位置、读取方法和时间（references/sources.md）。
3. 在每种模式下将每个别名解析为最终值，并记录与第二个来源的所有分歧。
4. 收集基础信息：每个属性占一行，记录其位置、类别和用途（mapping-rules.md，团队列表的判定标准）。
5. 按规则文件规范化双方的数据，并通过代码转换颜色。
6. 分类：候选 token 的声明用途必须涵盖该用途；语义 token 优先于原始 token；每种模式下每行只能归入一个类别，并说明原因和数值差异。
7. 统计并收尾：检查差距阈值；规则要求时，按角色检查一致性；然后填写 Summary 和 Source。

切勿提交：

• 列表中没有的 token 名称。存在差距时，绝不新增名称。
• 未先考虑用途就按数值匹配，或匹配超出规则文件规定的容差范围。
• 在语义 token 能覆盖用途时使用原始 token。
• 读取失败后凭记忆补全列表或数值。
• 用公共系统的 token 名称（包括 Geist 的 token 名称）替代团队列表。
• 对代码库做任何更改。

最终报告会将原始数值（十六进制颜色代码、像素值、阴影）映射到由他人维护的 token 列表。若没有 token 集，则提供构建 token 集所需的基础信息。

从请求中已有的信息着手

“检查设置页面上的 token”就足够了。自行查找数值和列表，只针对工具无法获取的信息提问。默认值：

• 数值：用户指定的内容；否则使用分支差异；再否则使用产品代码（references/sources.md）。
• 模式：列表的默认模式，在 Source 中注明。
• rem 根值：16px，除非项目另有规定。

协调者调用时

将简报中的数值和列表视为已确认，直接执行到底，无需提问。将问题列在 For a person to decide 下，每个问题都提供一个默认值，由调用方将其转为门槛。先输出状态行：Status: complete、Status: not actionable (gap threshold) 或 Status: stopped: <condition>，然后输出 Commit: none。将报告或下方的停止格式作为最终消息返回。

输出

按以下顺序分为七部分，每部分均按 references/mapping-rules.md（Report shape）中的规定填写：Summary、Mapping、Do not use、Ambiguous、Gaps、For a person to decide、Source。

直接运行时，聊天回复需给出 Summary 的答案和其中的数值、每条命令及其退出代码、最多三个供人决定的问题及其默认值，以及带有一条可粘贴提示词的 Next:。

满足以下条件时，报告即可交付：

• 每一行都有用途、类别和原因；每个含糊条目都列出两个或更多候选项。
• 只要语义 token 能覆盖用途，就必须使用语义 token，绝不使用原始 token。
• 任何推断而非读取的信息（例如根据类别名称推断用途）都已标记为 inferred。
• 代码库未发生任何变化。
• 最后一行是 Coverage:（mapping-rules.md，Report shape）。

停止条件

仅在以下情况停止并报告：

• 不存在列表，或没有工具能够读取列表。
• 同一种模式下，一个名称对应两个数值，导致列表无效。
• 两个来源存在分歧，且项目没有规定优先采用哪一个。报告双方的信息。

停止时，返回停止条件、第 4 步的基础信息（按 mapping-rules.md 中的 When the repo has no token file 分组），以及能解除阻塞的最简短消息，例如“请粘贴 tokens.json 或提供其路径。”存在差距不是停止条件。