mcpField
T
token-mapping

token-mapping

github.com/arla6kaデザイン・UI221241 回インストール4 日前に更新
リポジトリ

token-mapping について

画面の値をチーム既存のデザイントークンに対応付けるワークフロースキルです。プロジェクト固有のルールに従って根拠や曖昧さを記録し、リポジトリを変更せず構造化レポートを作成します。

主な機能

  1. 01プロジェクトルールとトークンソースの読込
  2. 02ルールに沿った値の正規化
  3. 03用途と分類に基づくトークン照合
  4. 04曖昧さ、差分、判断事項の記録
  5. 05構造化された対応付けレポートの作成

活用シーン

  1. 01ページのスタイルとチームのトークン一覧の監査
  2. 02モードごとのトークン候補の比較
  3. 03トークンセットがない場合の基礎情報整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/arla6ka/skills --skill token-mapping

インストール後、Claude Code で/token-mappingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
TESTS.md
references/
mapping-rules.md
sources.md

詳細

トークンのマッピング

  1. ルールを読み込みます:references/mapping-rules.md、AGENTS.md または CLAUDE.md、docs/system/decisions.md。上書き設定と優先順位のルールを確認します。
  2. リストを読み込み、その名前、形式、場所、読み取り方法、読み取り時刻を記録します(references/sources.md)。
  3. 各モードで、すべてのエイリアスを最終的な値に解決し、別のソースとの不一致をすべて書き留めます。
  4. 下準備を集めます。プロパティごとに1行で、場所、カテゴリ、役割を記載します(mapping-rules.md、「チームのリストと見なされるもの」)。
  5. ルールファイルに従って両方を正規化し、コードで色を変換します。
  6. 分類します。明示された目的が役割を満たす候補トークンを選び、プリミティブよりセマンティックを優先します。各モードの各行につきクラスは1つとし、その理由と数値の差を記載します。
  7. 集計して締めくくります。しきい値の差、ルールで求められる場合は役割別の一貫性、続いて Summary と Source を記載します。

決して次のことをしてはいけません。

  • 読み込んだリストにないトークン名を使うこと。差があっても、新しい名前は作りません。
  • 目的を確認する前に値で一致させること、またはルールファイルの許容範囲外で一致させること。
  • 役割を満たすセマンティックトークンがあるのに、プリミティブを使うこと。
  • 読み込みに失敗した後、記憶を頼りにリストや値を補うこと。
  • チームのリストの代わりに、Geistを含む公開システムのトークン名を使うこと。
  • リポジトリに変更を加えること。

この結果は、生の値(16進コード、ピクセル値、シャドウ)を、他の人が所有するトークンリストに対応づけたレポートです。トークンセットがない場合は、作成のための下準備を返します。

依頼内容を起点にする

「設定ページのトークンを確認してください」だけで十分です。値とリストは自分で見つけ、ツールで取得できないものだけを尋ねます。デフォルトは次のとおりです。

  • 値:指定されたもの、なければブランチの差分、それもなければ製品コード(references/sources.md)。
  • モード:リストのデフォルトモード(Sourceに記載)。
  • remのルート:プロジェクトで別の値が設定されていない限り、16px。

コーディネーターから依頼された場合

依頼書に記載された値とリストをそのまま受け入れ、質問せずに最後まで進めます。確認事項はそれぞれデフォルトとともに「人が判断する項目」に記載し、呼び出し元がゲートに変換できるようにします。まずステータス行として Status: complete、Status: not actionable (gap threshold)、または Status: stopped: <condition> のいずれかを記載し、続けて Commit: none と記載します。レポート、または以下の停止時の形式を最終メッセージとして返します。

出力

references/mapping-rules.md(Report shape)で指定されている7つのパートを、この順序で記載します:Summary、Mapping、Do not use、Ambiguous、Gaps、For a person to decide、Source。

直接実行する場合、チャットの返信には、Summaryの回答と数値、終了コードを添えた各コマンド、人が判断するための質問(デフォルト付き、最大3件)、および貼り付けるプロンプトを1つ含む Next: を記載します。

レポートの完成条件は次のとおりです。

  • すべての行に役割、クラス、理由があり、曖昧な行には候補が2つ以上記載されている。
  • 役割を満たす箇所にはすべてセマンティックトークンが使われ、プリミティブは使われていない。
  • クラス名から推定した役割など、読み取りではなく推定した内容には「推定」と明記されている。
  • リポジトリに変更がない。
  • 最終行が Coverage: である(mapping-rules.md、Report shape)。

停止条件

停止して報告するのは、次の場合に限ります。

  • リストが存在しない、またはリストを読み取るツールがない。
  • 同じモードで1つの名前に2つの値があり、リストが壊れている。
  • 2つのソースが食い違っており、どちらを優先するかを定めたプロジェクトルールがない。両方を報告します。

処理を停止した場合は、停止条件、手順4で集めた下準備(mapping-rules.md、「リポジトリにトークンファイルがない場合」に従って分類)、および作業を進めるための最短のメッセージを返します。例:「tokens.json を貼り付けるか、パスを指定してください。」差は決して停止条件にしません。

コメント