authoring-hi-fi

authoring-hi-fi — SKILL.md

バリエーション： 標準 · 使用するタイミング： 上流のワイヤーフレームとデザインシステムを基に、高忠実度 UI デザインを実行・描画可能なコードとして作成（または修正）するとき。エンジニアが本番環境向けに発展させられるビルドの種であり、人による視覚的な確認を必須とします。

概要

このスキルは、優れた包括的なコードとしての高忠実度 UI デザインを作成するための「方法」です。セクションの一覧ではなく、作成者が適用する判断基準を扱います。成果物はピクセルとして描画されるコードです。デフォルトでは単体の HTML+Tailwind を使い、ビルドスタックが React の場合は React+shadcnを使います（ビルド対象に近い状態で種を作成し、ずれを最小限に抑えるためです）。このスキルでは、テンプレートツール（セクション構成）、ヘッドレスブラウザー（agent-browser/Playwright。描画とスクリーンショットに使用）、プロダクトのデザインシステムとshadcn（トークンとコンポーネントの信頼できる情報源）、およびリサーチ機能を前提とします。作成者には、上流のワイヤーフレーム（画面、状態、構成）とデザインシステム（トークン、コンポーネントの仕様）が渡され、ワイヤーフレームで指定されたすべての画面を具現化します。白紙から始めることも、構成を再決定することもありません。

特徴的な仕組みは、一度だけ書くのではなく、ループを回すことです。生成 → ヘッドレスで描画 → スクリーンショットを撮影（ビューポート × 状態ごと）→ DS、ワイヤーフレーム、基準に照らしたビジョンによる自己レビュー → 改善 → 基準に達するまで反復 → 人による視覚的なゲート。この作業にはビジョン対応のランタイムが必須です。テキストのみの実行は、視覚的に確認できないコード生成（品質低下）になるため、その旨を伝え、描画したふりをしてはいけません。

この役割を守るために、2つの境界を設けています。ハイファイが担うのは、ピクセルとして具現化された最終ビジュアルと、数値に基づくピクセル単位の WCAG 評価です（ワイヤーフレームは、これらのための枠だけを確保しています）。デザインシステムのトークンを利用しますが、トークンを新たに考案したり評価したりしません。指定されたワイヤーフレームの構成を描画しますが、レイアウト、画面、ナビゲーションを再決定しません。また、これはビルドの種であり、意図的に薄く作ります（テストなし、モックデータ可、CDN 利用可、単一ファイル可）。最終的な本番コードではありません（ビルドフェーズでデータレイヤー、ルーティング、状態、テスト、パフォーマンスを作り直します）。

使用するタイミング

• 上流のワイヤーフレームとデザインシステムを基に、新しいハイファイデザインをコードとして作成するとき。
• ワイヤーフレーム文書で指定された主要画面（およびその状態）を、描画されたピクセルとして具現化するとき。
• トークン、画面、共通レイアウト、または参照されるコンポーネントの変更に伴い、既存のハイファイを修正するとき（ステップ 8 を参照）。
• 調査済みで描画可能な、判断が完了した画面をハイファイテンプレートに追加するとき。

次の場合は有効にしないでください：

• 完成したハイファイをレビューまたは評価するとき → reviewing-hi-fi を使用します。
• 画面の構成（レイアウト領域、コンポーネントの選定、構成としての状態）を作成するとき → 上流工程のワイヤーフレームで扱います。
• トークンシステム／コンポーネントカタログを作成または評価するとき → デザインシステムで扱います。ここではそれを利用します。
• 存在する画面や画面遷移を再決定するとき → user-flowsで扱います。
• 最終的な本番コード（テスト、実際のバックエンド、ルーティング）を書くとき → ビルドフェーズで扱います。ここでは種を作成します。

入力

プランから渡されたすべてのドキュメントを読みます。対象は depends_on セットです（典型的な上流ドキュメントは、画面の名前と構造を定めるワイヤーフレームと、トークンとコンポーネントの仕様を提供するデザインシステムです）。指定された上流ドキュメントは指針であり、前提条件ではありません。自己完結させ、受け取ったものをもとに成果物を作成します。想定される上流ドキュメントがない場合は、手元にある情報だけで進め、不足を前提条件として明示します（ステップ 7）。決して捏造しないでください。実行環境でレンダリングできること、そしてレンダリング結果を確認できること（ビジョン機能を備えた実行環境とヘッドレスブラウザー）を確認してください。できない場合はその旨を伝え、実行が不完全な状態として扱ってください。未検証のレンダリング結果をレビュー済みとして提示してはいけません。

機能コンテキスト（提供された場合）： 呼び出し元から capability_record（capability-map.yaml product_capabilities のレコード）が渡された場合は、ステップ 1 の前に読みます。これはスコープの境界を定めます。owns = 担当するエンティティ、refs = 参照するが担当しないエンティティ、publishes/consumes = 表面化させるイベント、entry_points/exit_points = ユーザーがどこから入り、どこへ移動するか、has_ui/has_api/has_persistence = 該当するサーフェスを示します。これがある場合は厳格な制約として扱い、定められた境界を越えてはいけません。

ワークフロー

ステップ 1：構成をテンプレートツールから取得する — アウトラインを考案しない

ハイファイテンプレートツール（包括版）からセクション構成を取得します。ここでセクション一覧を繰り返してはいけません。このスキルが示すのは、各セクションを適切に仕上げる方法です。利用できるテンプレートがない場合は、包括的なハイファイ構成を入手または作成してから進めます。

capability_record がある場合は、デザインシステムのトークンを各機能のワイヤーフレームにのみ適用します。シェルや他の機能を再設計してはいけません。scope=system の場合は、システムワイヤーフレーム（シェル）にのみ適用します。仕上げるワイヤーフレームドキュメントと同じ境界を守ってください。

ステップ 2：上流のワイヤーフレームから画面セットを導き出す

ハイファイ成果物は、ワイヤーフレームを depends_on に含みます。ワイヤーフレームで名前が付けられたすべての画面と、フロー／ワイヤーフレームを通じて表示されるすべての状態について、レンダリングされたハイファイ画面を作成します。 カバレッジを監査できるよう、画面インベントリ（各画面とその状態、対象ビューポートから該当セクションへの対応表）を作成します。これは変更時の影響範囲でもあります（ステップ 8）。ワイヤーフレームで名前が付けられた画面にコンテンツが定義されていない場合は、不足として記録し（ステップ 7）、決して作り出さないでください。指定された構成をレンダリングし、ワイヤーフレームに記載されていない画面、領域、ナビゲーションを追加してはいけません（範囲の逸脱）。

ステップ 3：トークンからコードへのマッピングを設定する（デザインシステムを使用し、捏造しない）

デザインシステム／DTCG トークンをコードのテーマレイヤーに一度だけマッピングし、すべてをそのテーマに結び付けます。セマンティックなCSS カスタムプロパティ（.dark によるオーバーライドを含む --background、--primary など）を定義し、Tailwind ユーティリティ（設定内の hsl(var(--token))、または v4 の @theme ブロック）と、React スタック上の shadcn CSS 変数テーマで使用します。視覚表現に使う値はすべてトークンに基づくものにします。トークンを介さない生の #hex、12px、bg-blue-500 を使ってはいけません。デザインシステムにないトークン／コンポーネントは不足として明示し（→デザインシステムを修正）、インラインで追加してはいけません。（詳細：references/render-loop-and-tokens.md。）

ステップ 4：ビジュアル言語を実現し、ピクセル単位で仕上げる

ワイヤーフレームの構造と DS トークンを、完成度の高い実際の画面に仕上げます。

• ビジュアルの実装 — トークンに基づく色、実際のタイポグラフィ（文字サイズの尺度／ウェイト／行の高さ／行長）、8pt のスペーシングリズムの適用、エレベーション／シャドウ、角丸、実際のアイコンセット、プレースホルダーに安全な画像。ワイヤーフレームの構造的な階層を、実際のコントラスト／サイズ／ウェイト／色／位置で表現します。
• 客観的な仕上がり（確認可能） — グリッドに沿った配置、一貫したスペーシングの尺度、視覚的なバランス、要素の欠け／重なり／孤立がないこと、トークンに沿った値、同系統の画面間で一貫した扱い。
• 5 つの名前付き美的ヒューリスティック（プログラムの仕上がり基準。評価対象ですが、それぞれ名前があり、説明できることが条件です。範囲外の主観的な好みは要件ではありません）：バランス（視覚的な重みの配分）、余白と抑制（意図的なネガティブスペース。窮屈でも、装飾過剰でもないこと）、スペーシングのリズム（一貫性があり、心地よい間隔）、フォーカスの明確さ（視線が向かう明確な強調箇所が 1 つあること）、美的な一貫性（寄せ集めではなく、意図的に「デザインされた」と感じられること）。（各ヒューリスティックの詳細と「良い状態」の例：references/visual-a11y-and-amend.md。）

ステップ 5：実際のコンテンツとすべての状態をレンダリングし、レンダリング→ビジョンレビュー→改善のループを実行する

• 実際のコンテンツ（lorem ではない）と、現実的なエッジデータ（長い文字列、オーバーフロー、空の状態、複数形、i18n による長さの変化）を使用します。lorem では、レイアウト／オーバーフロー／トーン／a11y の問題が見えません。
• フロー内のすべての状態を、実際のピクセルとしてレンダリングします。空の状態（理由＋操作への案内）、読み込み中＝入力済みレイアウトを模したスケルトン（単なるスピナーではありません）、入力済み、エラー（平易な言葉で原因を説明し、復旧方法を示す）、成功（変更内容＋次のステップ）、一部のみ。
• ループを実行します： コードを生成 → ヘッドレスでレンダリング（agent-browser）→ ビューポート × 状態ごとにスクリーンショットを撮影 → DS＋ワイヤーフレーム＋ステップ 6 の基準に照らしてスクリーンショットをビジョンレビュー → 改善 → 繰り返し。ループには上限があります（§9）：反復回数を制限します。画面が基準に達しない場合（例：DS トークンの不足によりコントラストを高められない場合）は、そこで止めて、阻害要因を前提または不足事項として明示します。延々と繰り返してはいけません。初回生成コードではなく、改善後の画面とそのスクリーンショットを提示してください。

Step 6: 引き渡し前に基準に照らしてセルフチェックする

以下のすべてを満たしていることを確認します（これは reviewing-hi-fi が定める基準であり、同じリストを一元管理し、画面のアーキタイプに応じた比重になっています）。

1. 完全な網羅性 — ワイヤーフレームで名前が付けられたすべての画面と状態がレンダリングされている（ワイヤーフレームにあるのに対応するものがない状態がない）。
2. 忠実度とスコープ — 高忠実度のビジュアルである（ワイヤーフレームのグレー表示ではない）。独自の構造、ナビゲーション、トークンを追加しておらず、これは シード である（作り込みすぎておらず、本番対応済みとうたっていない）。
3. ビジュアルの実装と階層 — DS のビジュアル言語を反映している。主要な要素が視覚的に際立ち、階層が明確に読み取れる。
4. 仕上がり — 客観的に評価できる項目と、名前が挙げられた5つのヒューリスティックを満たしている。対象範囲外の主観的な好みは押し付けていない。
5. トークンに基づいている — すべての値がトークンに基づいている（Tailwind/CSS-var/shadcn）。トークンにない値を直接指定しておらず、DS との対応関係が忠実である。
6. レンダリング済みでセルフレビュー済み — すべての画面が問題なくレンダリングされ、ワイヤーフレームと DS を照合しながら、ループを通じて目視レビューされている。
7. コンテンツの現実性 — 実際のコンテンツを使用し、lorem を使っていない。エッジデータも検証している。
8. レンダリングされた状態 — フローで訪問する各状態がレンダリングされている。スピナーではなくスケルトンを使用し、エラーには原因と回復方法が示されている。
9. レスポンシブ対応 — 対象ビューポートでレンダリングし、検証している。フォームファクターが重要な場合は、モバイルでコンテンツの優先順位を付け、ナビゲーションを適応させている。
10. レンダリング上で数値により確認できる WCAG 2.2 AA — コントラスト比 4.5/3:1（SC 1.4.3/1.4.11）、フォーカスが視認でき、遮られていない（2.4.7/2.4.11）、かつ外観が ≥2px/3:1（2.4.13、社内ルール）、ターゲットが ≥24px（2.5.8）、キーボード操作、動きの低減に対応している。axe-core のチェックに合格し、無効化されたルールがない。
11. DS への準拠 — 逸脱や上書きがない。不足しているトークンやコンポーネントは表面化させ、インラインで補っていない。
12. ギャップの明示 — 未定義の画面やコンテンツ、不足している DS 要素、劣化した実行（レンダリングなし）は、明示的な前提として記載している。
13. バージョン管理（修正時） — 変更内容がドキュメント自体のバージョンと変更履歴に反映されている（Step 8）。
14. 機能範囲の境界（capability_record がない場合は該当なし） — デザインシステムのトークンを全体で使用している。デザインシステムにないコンポーネントを新たに追加していない。レンダリング範囲がワイヤーフレームの範囲と一致している（機能単位のレコードでは内部のみ、システム範囲ではシェルのみ）。refs エンティティや exit_point を超えるコンテンツがない。

Step 7: ギャップを明示する

コンテンツが未定義の、ワイヤーフレームで名前が付けられた画面、DS にないトークンやコンポーネントが必要な要素、トークンでは解消できないコントラストやターゲットの失敗、または劣化した実行（テキストのみ、レンダリングなし）は、未解決の質問または前提として扱います。リストに記載し、不足しているトークンやコンポーネントをデザインシステムの担当者に伝えます。ギャップを埋めるために、トークンやコンポーネントを独自に作ったり、スクリーンショットを偽装したりしてはいけません（§7）。

ステップ 8：修正モード — 再生成せず、差分を編集して再レンダリングする（反復時）

既存のハイファイデザインと変更を受け取った場合は、再生成ではなく、スコープとバージョンを定めた差分として扱います。

1. スコープと波及範囲 — 変更対象の画面／状態を特定し、波及範囲を追跡します。トークン→コードのマップを通じて変更された DS トークンを使用するすべての画面（特徴的な広範囲のハイファイ波及）、変更された共有レイアウト／コンポーネントを再利用するすべての画面、上流のワイヤーフレーム変更によって追加／削除されたすべての画面、変更／非推奨になった DS コンポーネントを参照するすべての画面を確認します。
2. 編集して差分を再レンダリング — 既存の箇所を最小限編集します。未変更の画面のコードはバイト単位で安定した状態に保ち、スクリーンショットを再取得しません（バイト単位の差分比較ではありません。ヘッドレスレンダリングは実行ごとにバイト単位で一致しないためです）。差分のみを再レンダリングし、再度ビジョンレビューします。トークン変更はマップに一度だけ適用してから、すべての使用箇所を一括で再レンダリングします（正当な広範囲の波及はこれだけです）。画面ごとに手作業で編集してはいけません。
3. バージョンと変更履歴 — ドキュメント自体のバージョンを上げます。MAJOR（画面、または画面ごとの状態の削除／改名。ビルドシードの契約を破る変更）、MINOR（画面／状態／コンポーネントの追加）、PATCH（仕上げ／文言／トークン値の微調整）。画面／状態単位で Keep-a-Changelog 形式のエントリーを記載します。
4. 削除前に非推奨にする — 画面／状態を削除する前の MINOR で非推奨としてマークし、置き換え先を記載します。その後、MAJOR で削除します。削除時にはリンク／インデックス／関連画面からの参照が残っていないことを確認し、削除します。

ルール

厳守事項（決して違反しないこと）：

• **ワイヤーフレームで名前が付けられた画面／状態ごとに、レンダリング済み画面を 1 つ用意します。**網羅性はワイヤーフレームを基準にします。名前が付いていてもレンダリングされていない画面は未完成です。
• **デザインシステムを使用し、独自に作らないでください。**トークンで定義された値のみを使用します。生の 16 進数値／px 値は使いません。トークン／コンポーネントが不足している場合は、インラインでその場しのぎの実装をせず、ギャップとして報告します。
• **指定された構造をレンダリングします。**ワイヤーフレームの画面をレイアウトし、構造やナビゲーションを再決定してはいけません。
• **反復作業は上限を設けて行います。**引き渡す前に生成→レンダリング→スクリーンショット→ビジョンレビュー→調整のループを実行します。反復回数に上限を設け、行き詰まった場合は回し続けず、障害要因を明らかにします（§9）。
• **これはシードであり、本番用ではありません。**テストや実際のバックエンドは不要です。本番運用可能と主張してはいけません。ビルドフェーズで堅牢化します。
• **実際のコンテンツを使い、ダミーテキストは使いません。**実データとエッジケースのデータを使用します。ハイファイでのダミーテキストは不具合です。
• **レンダリング結果の数値に基づいてアクセシビリティに対応し、ルールを無効化してはいけません。**コントラスト／フォーカス／ターゲットはトークン層で修正します。axe ルールの抑制は指摘事項です。
• **ビジョン対応ランタイムを使用するか、その旨を明記します。**テキストのみの実行は機能が制限されます。そのことを明示し、スクリーンショットを捏造してはいけません。
• **重複させず、組み合わせます。**セクション構成はテンプレートツールから取得します。
• **不足を明らかにし、独自に作らないでください。**未定義の画面／コンテンツ、欠落したトークン／コンポーネント、機能が制限された実行は、明示的な前提として示します。
• **再生成ではなく修正します。**差分を編集して再レンダリングし、バージョンを更新して変更履歴を記載します。未変更の画面は再レンダリングしません。
• **機能の境界（capability_record が提供された場合）。**ドキュメントの出力範囲は、そのレコードの境界内に限定します。境界外のコンテンツを作成すること（refs のエンティティを自分の担当範囲であるかのように扱う、exit_point を越えるフローを設計するなど）は、仕様にないコンテンツを作ることと同等のスコープ違反です。

推奨事項（変更可能）：

• デフォルトでは単独の HTML+Tailwind を使用します。ビルドスタックが React の場合は、React+shadcn に切り替えます。
• 「包括的」は意欲的な水準を示しますが、相応の範囲にとどめます。静的で薄い画面なら、状態は少なく、レスポンシブ対応やインタラクションの作業も不要です。
• レイアウトが分かっている場合は、単なるスピナーよりもレイアウトを反映したスケルトンを優先します。
• 5 つの美的ヒューリスティックは評価対象ですが、名前があり、言葉で説明できます。色味やレイアウトに関する個人的な好みを押し付けないでください。

注意点

• コードを生成するだけで、画面を確認しないこと。 レンダリングして確認せずにコードを生成することが、失敗の最大の原因です。ループ（Step 5）にこそ価値があります。テキストだけで実行した場合は品質が低下することを明示してください。
• トークンを介さない値を使うこと。 #3b82f6 や 13px のようにトークンマップを迂回する値は、デザインシステム（DS）とのずれにつながります。すべてを DS トークンに紐付けてください（Step 3）。
• Lorem ipsum を使うこと。 プレースホルダーテキストは、はみ出し、トーン、アクセシビリティの問題を隠し、デザインが未完成であることを示します。実際のコンテンツをレンダリングしてください。
• シードを本番環境向けと見なすこと。 テストや実際のバックエンドを追加するのは過剰な構築であり、本番対応済みと主張するのは過剰な誇張です。これはシードであり、ビルドによって強化されます。
• axe のルールを無効にして合格させること。 color-contrast を除外すると、実際の不具合が隠れてしまいます。トークンを修正し、正当な例外は文書化してください。
• 不足しているコンポーネントをでっち上げること。 DS にないコンポーネントは、DS のオーナーが対応すべき不足です。画面内で即興で作らないでください。
• 構造を再検討すること。 ワイヤーフレームに記載のない画面、領域、ナビゲーションを追加するのは、ワイヤーフレームの担当範囲を越えています。
• 修正時にトークン変更のずれを生じさせること。 トークンマップで一度だけ変更せず、画面ごとにトークンの値を手作業で変更することは、修正時に最もよく起きるリグレッションです。値は一度だけ変更し、そのトークンを使用するすべての画面を再レンダリングしてください。

アンチパターン

• 「コードは正しそうだから、出荷しよう。」 UI はレンダリングして確認するまで完成ではありません。ループを実行してください。
• 「ここはきれいな青を使おう。」 トークンから外れています。DS トークンに紐付けるか、不足として明示してください。
• 「今は Lorem ipsum で問題ない。」 実際のレイアウトの問題を隠してしまいます。実際のコンテンツと境界ケースのコンテンツを使ってください。
• 「バックエンドを接続して、テストも追加しよう。」 シードに対する過剰な構築です。薄く保ち、ビルドによって強化してください。
• 「axe がコントラストを指摘しているから、そのルールを除外しよう。」 トークンを修正してください。実際のルールを無効にしてはいけません。
• 「ワイヤーフレームが曖昧だから、画面を追加しよう。」 代わりに、前提事項として明示してください。
• 「小さなトークン調整だから、すべて再生成しよう。」 修正時は、トークンを一度だけ変更し、そのトークンを使用する画面だけを再レンダリングし、バージョンと変更履歴を更新してください。

出力

Step 6 の基準（ワイヤーフレームに対する網羅性、高忠実度とシードの範囲、視覚的な仕上がりと明確な階層、客観的かつ名前の付いたヒューリスティックに基づく洗練、トークンに基づきずれがないこと、レンダリング済みでビジョンレビュー済みであること、実際のコンテンツ、レンダリング済みの状態、レスポンシブ対応、レンダリング結果で数値化された WCAG 2.2 AA 準拠、DS への準拠、不足の明示、修正時のバージョン管理）を満たす、包括的でレンダリング済みの高忠実度 UI デザインのコードです。各画面は、実行可能なコードと、ビューポート × 状態ごとのレンダリング済みスクリーンショットで構成されます。抽象的な利用者は、人間によるビジュアル確認の関門、シードを本番環境へと成長させるビルド段階、そして同じ基準への準拠を確認するレビュアーです。このドキュメントの構造はテンプレートツールによって決まり、このスキルはコンテンツの品質を担います。

実例（1 画面でのループ）。 引き継ぎ内容：ワイヤーフレーム「Projects — list」（状態：データあり、空、読み込み中、エラー）と、--primary、--muted、Card、Button、Table を備えたデザインシステム。手順：トークンを Tailwind/CSS 変数のテーマにマッピングします（Step 3）。実際のプロジェクトを代表するデータ（実在する名前と日付、はみ出しを確認するための長い名前の行を 1 つ含む）を使った Table を含むデータあり画面、「No projects yet」と --primary を使った「New project」Button を含む空の状態、読み込み中用のテーブルに似たスケルトン、そしてエラーカード（「Couldn't load projects — Retry」）を作成します。360／768／1024／1280 でレンダリングし、各状態のスクリーンショットを撮ります。ビジョンレビューで、空の状態の CTA が白地に --muted を使っており、コントラスト比が 2.9:1 であることを発見します。--primary に紐付けて修正します（一時的な個別対応ではなく、トークンを修正します）。再レンダリングすると、コントラスト比は 4.8:1 になります。axe の指摘はありません。結果：レンダリング済みの 4 つの状態がトークンに基づいて WCAG に準拠し、ビルドで成長させられるシードになります。（コントラスト不足はループで検出し、ボタン 1 つだけをトークンから外れた色に変更するのではなく、トークンのレイヤーで修正しています。）

関連項目

• ハイファイテンプレートツール（コンテンツ／テンプレートゲートウェイ）— このスキルが補完する、画面ごとの包括的なセクション構成を提供します。
• agent-browser（＋ playwright-best-practices）— このスキルが操作するループのために、コードをレンダリングしてスクリーンショットを撮影します。操作方法を再度説明することはありません。
• shadcn ＋ ui-ux-pro-max ／ ckm-* — React コンポーネントのテーマ設定とビジュアル実装の指針です。組み合わせて使用しますが、再度説明することはありません。
• ディープリサーチ機能 — ビジュアルとインタラクションに関する判断の根拠を提供します。
• reviewing-hi-fi — 同じ基準を適用します（再レンダリング＋ビジョンレビュー）。作成者とレビュー担当者が同じ基準を共有することで、ずれを防ぎます。
• 上流のワイヤーフレーム（depends_on ドキュメント）— 実現する画面構成です。
• デザインシステム（depends_on ドキュメント）— 使用するトークンとコンポーネントの契約を定義します。コンポーネントごとの a11y 契約はデザインシステムが担い、このスキルはレンダリング結果がそれに準拠していることを確認します。

段階的な情報開示

• references/render-loop-and-tokens.md — レンダリング→ビジョンレビュー→改善のループ手順、スクリーンショット撮影プロトコル（ビューポート × 状態）、DS/DTCG→Tailwind/CSS-var/shadcn のトークンマッピング手順、コードスタックの選択について説明します。ループまたはトークンマップの設定時に読み込みます。
• references/visual-a11y-and-amend.md — 5 つの美的ヒューリスティック（それぞれ「良い状態」の基準）、ビジュアル実装の深さ、数値で示す WCAG 2.2 SC、axe のセットアップ、修正時のトークン波及とバージョン管理の手順について説明します。仕上げや a11y の確認、修正を行う際に読み込みます。
• references/sources.md — 手法と基準の調査根拠です（指針の出典を監査する場合にのみ読み込みます）。

本文の分量

• description は 1,024 文字以下（agentskills.io の上限）です。
• 本文は約 500 行／5,000 トークン（目安です。品質を優先し、700 行／7,000 トークンを継続的に超える場合は警告してください）。
• 多くの内容は references/ に置き、必要に応じて読み込みます。