カラーシステム
カラーシステムとは、役割ごとに名前付けられた少数のランプ（段階的な色の集合）であり、実際にレンダリングされる背景に対して検証されたものです。ほとんどの色のバグはシステムバグです。単独で選ばれた値、見た目が合っていたから借用したトークン、誰も測定しなかったペア。
自分で測定していないコントラスト値を報告してはならず、計算できる色を推測してもいけません。色は、正確な答えが存在する数少ないインターフェース上の関心事であるため、正確な答えを提供してください。
コントラスト要件は hr-better-accessibility に属します。サーフェス、シャドウ、アイコン色はこのスキルの範囲外です。
プロジェクトのカラーシステムに合わせる
プロジェクトのトークンと表記法を再利用してください。ひとつの値を修正するために別の表現を追加すると、パレットの理解が難しくなります。一貫性のある16進数システムは、その中に oklch() が散在しているものよりも優れています。
トークンが存在すれば、トークンファイル外のカラーリテラルを禁止するリントルールまたはガードテストで強制し、生の値が必要な場所には短い許可リストを設けてください。「トークンを使え」というルールを書くだけでチェックがなければ、次第に形骸化します。
新しいシステムには oklch() が最適なデフォルトです。その数値は以下のランプルールで説明するように振る舞うからです。それ以外の場所では、カラーライブラリを使用してプロジェクト自身の表記法で同じランプを生成します（color-formats.md）。
システムは色ではなくランプである
ニュートラルランプ1つ、アクセントランプ1つ、そして製品が実際にレンダリングするステータスランプのみです。何もインポートしない warning ランプは、ゼロピクセルのためのメンテナンスです。2番目のアクセント色相は、2つのものを一目で区別する必要がある場合にのみ正当化されます。
各ステップに役割がある
ランプは目で選ぶグラデーションではありません。各ステップは、ページ背景、コンポーネントのホバー、境界線、ベタ塗り、本文テキストなど、役割が必要とするために存在します。どの役割も消費しないステップを生成してはいけません。Tailwindの 50–950 とRadixの 1–12 の両方の規則が、それらの役割にマッピングされます（palette-structure.md）。
プリミティブは色相で、セマンティックは役割で名付ける
プリミティブは値を名付け（--blue-500）、コンポーネントで直接適用されることはありません。セマンティックトークンは役割を名付け（--color-text-secondary）、プリミティブを指し示し、コンポーネントが参照する唯一の階層です。
その境界こそがテーマ設定を可能にするものです。これがないと、ダークモードはすべての使用箇所を監査して、「アクセント」を意味していたのか、単に青が欲しかったのかを判断する必要があります（token-naming.md）。
トークンはその役割でのみ使用する
値が今日合っているからといって、トークンを借用してはいけません。セパレーターをテキスト色として使用すると、境界線が薄くなったときにテキストも一緒に薄くなります。役割にトークンがない場合は、トークンを追加してください。
ランプ全体で色相を一定に保つ
整形式のランプを定義する4つの特性：
- ステップは意図的な 知覚 明度の進行に従うこと（palette-generation.md）。
- 色相は最初から最後まで一定であること。
- 鮮やかさはランプの中間でピークに達し、両端で低下すること。
- ステップは暗い端よりも明るい端で密に配置されること。
両端は、純粋な黒と白の手前で止まります。これらは色相をまったく保持できないからです。感覚に頼るのではなく、カラーライブラリを使用してください（palette-generation.md）。
一つの色に一つの意味
インターフェース全体で一つの色を一つの目的に使用し、色相が 15° 以内のものは同じ色として扱います。アクセントがインタラクティブを意味する場合、その色相を静的なテキストに使うと、クリックできないものをクリックできるとユーザーに誤認させます。また、インタラクティブな要素をニュートラルでレンダリングすることも同様に誤解を招きます。色は意味を伝える唯一の手段ではありません。これは hr-better-accessibility が担当します。
ビューごとに正確に一つのアクションを塗りつぶす
塗りつぶし色がプライマリ強調を表す場合、一つのプライマリアクションだけがそれを受け、同列のものはニュートラルのままにします。色はラベルではなく背景に配置してください。塗りつぶしボタンは部屋の向こう側からでもプライマリと読めます。ニュートラルボタン上のアクセント色のテキストはリンクのように読めます。
複数の色付き背景は、同列のものとして競合するのではなく、異なる状態やカテゴリをエンコードする場合には問題ありません。
レンダリングされたペアを測定し、報告する
前景を、ページ背景ではなく、実際にレンダリングされる背景に対して測定してください。ペアが不合格の場合、そのペア、測定値、および満たしていないしきい値を報告し、色自体は変更しないでください。それらはデザイン上の決定です。依頼があった場合にのみ変更し、その後再測定してください（contrast.md）。
グラデーションの補間空間を選択する
空間は見た目の問題であり、正しさの設定ではありません。
in oklabが最適なデフォルトです：明るさが均一で、色相の驚きがありません。in oklchは中央を通るのではなく色相環を周回し、鮮やかさを保ち、中間色の間のすべての色相を掃引します。2色のグラデーションが中間で灰色になるときに使用してください。- sRGBデフォルト は中間点を暗くし、くすませます。これは、ほとんどのインターフェースが既に持っているものです。なぜなら、特に指定しなければ得られるものだからです。
詳細は color-usage.md を参照してください。
終了前に確認すること
| 誤り | 修正方法 |
|---|---|
| プロジェクトにトークンがあるのに生の値を使っている | プロジェクトの表記法で、役割トークンを再利用または追加する |
16進数コードベースに孤立した oklch() 値を入れた | 移行が範囲内でない限り、確立された表記法を維持する |
--blue-500 のようなプリミティブをコンポーネントで直接使用している | セマンティックトークンでそれを指すようにする |
見た目（--color-blue-button）や最初の使用（--color-sidebar-gray）で名前付けられたトークン | 役割で名前付ける：--color-accent-solid、--color-bg-surface |
--color-primary がブランドを意味し、--color-text-primary が本文テキストを意味する | accent をブランド用に予約し、primary は「そのグループ内で最も顕著なもの」を意味させる |
| セマンティックトークンを役割外で使用（セパレーターをテキストとして） | 不足している役割のトークンを追加し、値で借用しない |
| HSLの明度を変えてランプを構築している | 一定の色相で知覚明度に対して再構築する |
| ランプを全範囲に均等に配置している | 明るい端を 50 と 100 が2つのサーフェスとして読めるまで詰める |
| 同じ彩度の値を色相間で再利用している | 生の値ではなく、各色相の最大値に対する割合を一致させる |
| アクセント色相と衝突するステータス色相 | 破壊的（destructive）とプライマリが並べて見て区別できるまで移動する |
| ライトパレットを機械的に反転させたダークモード | 開始点として反転し、鮮やかさを減らし、暗い端を広げ、すべてのペアを再チェックする |
prefers-color-scheme で一部のトークンを設定し、.dark クラスで別のトークンを設定している | 1つの切り替えメカニズムを選び、全体で使用する |
| 色相を変えてコントラストを修正した | コントラストが応答するチャネルである明度を変更する |
| sRGBフォールバックのないP3色 | 最初にsRGB値を宣言し、@media (color-gamut: p3) 内で上書きする |
報告
重要度. HIGH はコンテンツを読めなくする、または誤解を招くセマンティックカラーを割り当てます。MEDIUM は顕著なテーマ、トークン、または色域の障害です。LOW は孤立した洗練度の問題です。
検証. ブラウザなし：トークン値、宣言されたすべての色の色域、両方のテーマブロックの存在、宣言されたトークンペアから計算されたコントラスト。ブラウザあり：テキストの背後に実際にレンダリングされる背景（不透明度やその下の画像を含む）を、明るいテーマと暗いテーマの両方で測定します。不合格のペアは報告され、再描画されません。実行できなかったチェックはすべて「未検証」として報告してください。
形式. 発見事項を、違反している原則ごとにグループ化し、重要度順に並べ、原因ごとに1行、それが現れるすべての場所をリストします：
| 重要度 | 場所 | 修正前 | 修正後 | 理由 |
|---|
場所 は path/to/file:line です。理由 は原則とユーザーへの影響を記述します。
どの HIGH も残っている場合は Block を報告し、それ以外の場合は Approve を報告し、残りは対応すべき作業としてテーブルに残します。調査しなかった範囲に対して Approve を決して行わないでください。報告するものがない場合は、「修正可能な色に関する発見事項はありません」と述べ、検証を報告してください。