authoring-wireframes

authoring-wireframes — SKILL.md

バリアント： 標準 · 使用するタイミング： 上流のユーザーフローから、エンジニアが画面構造を構築できる水準の構造的なワイヤーフレーム文書を作成（または修正）するとき。

概要

このスキルは、優れた包括的なワイヤーフレーム文書の書き方、つまりセクション一覧ではなく、作成者が適用する判断基準を扱います。ここでのワイヤーフレームは、低〜中程度の忠実度で構造的なものです。各主要画面について、レイアウト領域（グリッド上の共有アプリシェル内）、コンテンツの階層、コンポーネント、操作の手がかり、コンテンツやマイクロコピーの意図、画面ごとの状態、画面構成のアクセシビリティを、ピクセルモックアップではなく、構造化されたレイアウト説明＋ASCII／Markdownのボックススケッチ＋各要素の注釈として表現します。2つの協力者を想定しています。セクションの構成を提供するテンプレートツールと、確立されたUIパターンに基づいて各画面を設計するためのディープリサーチ機能です。作成者には、各フローでたどる画面と状態遷移を示す上流のユーザーフローと、存在する場合はデザインシステムが渡されます。白紙のページから始めるのではなく、フローで名前が挙がっているすべての画面をレイアウトします。満たすべき水準は、文書が構築可能（エンジニアが画面構造を構築できる）、網羅的（フローで名前が挙がっているすべての画面と状態にワイヤーフレームがある）、そして適切に構成されている（客観的なレイアウト品質の基準を満たす）ことです。

忠実度は、インタラクティブ性、ビジュアル、コンテンツという3つの軸にまたがるスペクトラムです（NN/g）。ワイヤーフレームは、ビジュアルは低〜中程度、構造は中程度、インタラクティブ性は低めです。最終的な色、書体、ピクセル単位の表現は下流のハイファイ工程で扱い、トークンシステムとコンポーネントごとのa11y契約はデザインシステムが担います。このスキルは構造に専念します。この手法は媒体に依存しません。現在の成果物はMarkdownですが、将来デザインツールのバックエンドに変わっても、変わるのは媒体だけで、考え方や基準は変わりません。

有効にするタイミング

• プロジェクトのアイデアと上流のユーザーフローから、新しいワイヤーフレーム文書を作成するとき。
• 一連のユーザーフローで名前が挙がっている主要画面（およびその状態）をレイアウトするとき。
• フロー、画面、領域、参照先コンポーネントが変わった際に、既存のワイヤーフレーム文書を修正するとき（ステップ8を参照）。
• ワイヤーフレームテンプレートに、リサーチに基づき、必要な判断がすべて完了した構造的な内容を記入するとき。

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

• 完成したワイヤーフレーム文書をレビューまたは評価するとき → reviewing-wireframesを使用してください。
• 高忠実度のビジュアルデザイン、最終的なピクセル表現、色、書体、モーションを作成するとき → これは下流のハイファイ工程です。ビジュアルトークンはデザインシステムが担います。
• どの画面や遷移が存在するかを再決定するとき → それは上流のユーザーフローの役割です。このスキルでは各画面をレイアウトします。
• トークンシステムまたはコンポーネントカタログを作成または評価するとき → それはデザインシステムの役割です。
• 別の種類の文書を作成するとき → その種類に対応するスキルを使用してください。

入力

計画で渡されたすべての文書、つまり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：テンプレートツールの構成を使う — アウトラインを独自に作らない

ワイヤーフレームのテンプレートツール（包括版）からセクション構成を取得します。ここでセクションの一覧を再掲してはいけません。このスキルが提供するのは、各セクションを適切に埋める方法です。テンプレートがない場合は、包括的なワイヤーフレーム構成を入手または作成してから進めます。

ステップ 2：上流のユーザーフローから画面一覧を導き出す

ワイヤーフレーム文書はユーザーフローに depends_on します。すべてのフローをたどり、フローで指定されているすべての画面と、フローから暗示されるすべての状態遷移について、ワイヤーフレームを作成します。網羅性を監査できるよう、画面インベントリテーブルを作成します（フローで指定された各画面／状態 → 対応するワイヤーフレームのセクションと、その画面／状態が遷移する状態）。このテーブルは変更の波及範囲を確認するためにも使います（ステップ 8）。フローで指定されている画面に、定義済みの内容がない場合はギャップです。これを記録し（ステップ 7）、黙って内容を作り出してはいけません。

capability_record がある場合は、画面一覧をそのケイパビリティの entry_points／exit_points の範囲内に制限します。exit_points はケイパビリティをまたぐ遷移として示し、その後に何が起きるかは設計してはいけません。システムワイヤーフレーム文書が、シェルとケイパビリティ間のナビゲーションを担当します。

ステップ 3：各画面の根拠となる調査を行う — パターンを作り出さず、忠実度の境界を守る

ディープリサーチを使い、各画面の設計の根拠を、確立された UI パターン（リスト／詳細、マスター／詳細、ダッシュボード、設定、ウィザード、認証、検索結果などの一般的なレイアウトや、標準的な空・読み込み中・エラーの表示）に求めます。構造を独自に考案してはいけません。デザインシステムがある場合は、実際のコンポーネントとトークンを参照し、作り出してはいけません。忠実度の境界を守り、配置するのは構造（領域、グリッドの意図、コンポーネントの選択、アフォーダンス、状態）にとどめます。正確な HEX 値、ピクセル値、書体を指定すると、ハイファイの範囲を超えてしまいます。調査機能が利用できない場合は、パターンやコンポーネント名をでっち上げず、一般的な構造を示して、不確実な点を前提として明記します。

ステップ 4：全体のフレームを定める — グリッド、アプリシェル、レイアウト品質の基準

画面ごとの作業に入る前に、すべての画面で共通する規則を定めます。

• レイアウトグリッド＋間隔のリズム（構造であり、ピクセルではない）： 列構成（例：12 列）と、8pt（または密度の高い画面では 4pt）のリズムを意図として定めます。間隔のリズムを明記し、正確なピクセル値はデザインシステムに委ねます。13px のような生の値はリズムから外れ、ハイファイの範囲を超えます。
• アプリシェル／ページフレーム： 共通のヘッダー／ナビゲーション／コンテナー／最大幅を一度だけ定義し、すべての画面で再利用します。画面ごとに全幅の内容を個別に配置してはいけません。この共通領域が、変更による波及の対象になります。
• 客観的なレイアウト品質の基準（すべての画面が満たすこと。主観的な好みは必要ありません）：主要アクションを視線の走査経路（F／Z）上に置くこと、関連要素をグループ化すること（ゲシュタルトの近接性）、不要な領域や要素を設けないこと、関連する画面間で一貫性を保つこと。

scope=system の場合、入力は has_ui=true のすべてのケイパビリティレコードです。すべての entry_points をナビゲーションに組み込み、すべての exit→entry 接続箇所の遷移仕様を作成します。

ステップ 5：画面ごとの手法を適用する

テンプレートの画面ごとのセクションを、この手法に沿って記入します。主要な画面それぞれについて、次の項目を記載します。

• 目的とフロー内での位置付け — その画面でユーザーができること、その画面が担うフローのステップ、入口となる箇所、および各操作要素の遷移先を1文で記載します。
• レイアウト領域とコンテンツの階層 — 領域（ステップ4の用語）とグリッド上での配置を明記します。主タスクに基づく視覚的な優先度に沿ってコンテンツを並べ、関連項目をグループ化（ゲシュタルト）し、スキャン経路上に主要アクションを配置します。視覚的な検討に入る前に構造を定めます。
• ボックススケッチ — 初期状態／データ表示状態のレイアウトをASCII／Markdownでスケッチし、領域にラベルを付け、凡例は一度定義して再利用します。スケッチと注釈は常に一致させます。
• コンポーネントと操作要素（注釈） — 注目すべき要素ごとに、デザインシステムのコンポーネント（または汎用タイプ）、該当する場合は完全な構成、操作時の挙動（タップ／ホバー／検証／条件付き表示）、遷移先、エッジケース（テキストの省略／オーバーフロー／並べ替え／ページネーション／ドロップダウン）を記載します。注釈によって、静的なレイアウトを実装可能な仕様にします。
• データ表示（データ量の多い画面の場合） — テーブル／リスト／カードのどれを使うかを記載します。テーブルの場合は、列、並べ替え／フィルター／ページネーション／行の密度／固定ヘッダー／行の展開を記載します。段階的開示（主要な情報と、アコーディオン／開示コントロール／ツールチップ／「もっと見る」の背後に置く情報）について記載します。フォームでは、フィールドをグループ化し、構造化された入力を使います（シリアライズ済み文字列を手作業で作成しないでください）。
• コンテンツとマイクロコピー（最終文言ではなく意図） — 各テキスト欄の意図（ラベル／見出し／ボタン／空状態／エラー／プレースホルダー）を記載します。ユーザーの言葉を使います（データモデルの識別子をそのままラベルにせず、人間向けのラベルと1行の説明を付けます）。プレースホルダーとラベルは別のものです。用語の一貫性を保ちます（画面をまたいで、概念ごとに名称を1つに統一します）。i18nのテキスト拡張用の余白と、ローカライズ時のRTLを考慮します（単一ロケールに限定する場合は、その理由を1行で記載します）。
• 画面ごとの状態 — 空状態（理由と、平易な言葉による行動喚起のCTA）、読み込み中（レイアウトが既知の場合、単なるスピナーよりも表示済みレイアウトを模したスケルトン）、データ表示／初期状態、エラー（平易な言葉による原因と復旧方法、表示位置、インライン表示かブロッキング表示か、生のコードは表示しない）、成功／確認（何が変わったかと次のステップ）、およびフローで通過する場合の部分状態を記載します。フローで実際に通過する状態に沿って追跡します。ハッピーパスしか扱わないことは、最大の見落としです。
• レスポンシブ対応の注記（フォームファクターが重要な場合） — 何を縦に積む／折りたたむ（ナビゲーションからハンバーガーメニュー／オフキャンバスへ）／非表示にする／並べ替えるか、その仕組みを記載します。小画面でのコンテンツの優先度の変化（単に積み重ねるだけでなく、優先度を上げる／下げる／非表示にする）と、タッチターゲット用の余白を考慮します。
• アクセシビリティ — 画面構成 — 領域ごとのランドマーク、h1を1つにした見出し順序、読み上げ／フォーカス順序（条件付き表示時を含む）、アイコンのみのコントロールのアクセシブルネーム、キーボード操作への対応（マウス操作のみのステップを設けない）、ターゲットサイズの確保（24×24 CSS px以上、SC 2.5.8）、固定領域でフォーカスを隠さないこと（SC 2.4.11）、色だけに頼らない意図の伝達（SC 1.4.1）を記載します。ピクセル単位のコントラストとフォーカス表示は、デザインシステム（コンポーネントごとの仕様）に委ねます。後工程にデザインシステムや高精細なデザインがない場合は、その委任を前提事項（ステップ7）として記録し、省略しないでください。

Step 6: 引き渡す前に基準を満たしているか自己チェックする

すべて満たしていることを確認します（これは reviewing-wireframes が定める基準です。同じリストを単一の情報源とし、それぞれ画面のアーキタイプに見合ったものにします）。

1. 網羅性 — フローで名前が挙がっているすべての画面と状態遷移にワイヤーフレームがあること（フローに対する孤立や漏れがないこと）。
2. 該当するすべての状態 — 空・読み込み中・データ表示・エラーに加え、状態変化が発生する場合は成功状態、関連する場合は部分表示の状態も含めること。単に存在するだけでなく、品質も確認します。
3. レイアウトと構成 — 領域と階層が明確であること。グリッドに沿い、共有アプリシェル内に配置され、客観的なレイアウト品質基準（視線の流れ／グルーピング／無用な装飾がないこと／兄弟画面との一貫性）を満たしていること。
4. コンポーネント — DS コンポーネントが明示され、一貫性を保って組み合わされていること。新たに作られたものがないこと。
5. アフォーダンスとデータ表示 — 挙動と遷移先が注釈されていること。データ量の多い画面では、テーブル／開示／フォームの構造を指定すること。
6. コンテンツとマイクロコピー — テキスト領域の意図が示されていること。ラベルにデータモデルの詳細が漏れていないこと。ラベルが常に表示され、用語が一貫していること。
7. レスポンシブ — フォームファクターが重要な場合、再配置の仕組みとモバイルでの優先順位を示すこと。
8. 画面構成のアクセシビリティ — ランドマーク／h1 を 1 つにすること／読み上げ順／名前／キーボード操作／ターゲット領域の確保／フォーカスが隠れないこと／色に依存しないこと（ピクセル単位のコントラストは DS に委ねます）。
9. 注釈と引き渡し — 凡例が定義されていること。スケッチと注釈が一致していること。要素が DS コンポーネントに対応していること（引き渡し時の変換）。
10. ギャップの明示 — 未定義の画面やコンテンツ、不足しているコンポーネント、後続の DS／ハイファイ工程に委ねられたコンポーネントのアクセシビリティは、明示的な前提または未解決の質問とすること。
11. 構造を示すものであり、ハイファイではない — 低〜中程度の忠実度とし、最終的なピクセル／色／書体を定めないこと。
12. バージョン管理（修正時） — ドキュメント自身のバージョンと変更履歴に変更を反映すること（Step 8）。

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

フローで名前が挙がっている画面のコンテンツが未定義の場合、デザインシステムに定義されていないコンポーネントが必要な要素がある場合、または DS／ハイファイ工程に後続する工程がないコンポーネント契約上のアクセシビリティ課題がある場合は、未解決の質問または前提として扱います。リストに記載し、不足しているコンポーネントにはデザインシステムの担当者向けにフラグを立てます。ギャップを埋めるために、架空の画面やコンポーネントを作ってはなりません。

Step 8: 修正モード — 描き直さずに編集する（反復時）

既存の wireframes ドキュメントと変更内容を受け取った場合は、再生成ではなく、対象を限定したバージョン管理付きの差分として扱います。

1. 対象範囲と波及箇所 — 変更する画面／状態／領域を特定し、次に波及箇所を追跡します。変更された共有領域（アプリシェル／ナビゲーション／ヘッダー）を再利用するすべての画面、編集または削除する画面を参照するすべてのインベントリ行／フローからの引き渡し、変更または非推奨となった DS コンポーネントを挙げているすべての画面、上流のフロー変更によって追加または削除されたすべての画面を確認します。
2. 描き直さずに編集する — 最小限のインプレース編集とし、変更しない画面はバイト単位で変更しません。共有領域の変更は、その領域を再利用するすべての画面に一度の作業で適用します（これが正当な広範囲の波及です）。画面ごとに適用がずれてはなりません。画面名とコンポーネント名は維持します。
3. バージョンと変更履歴 — ドキュメント自身のバージョンを更新します。MAJOR（画面の削除／改名、または状態の削除 — ビルド／ハイファイ契約に影響する変更）、MINOR（画面／状態／領域／コンポーネントの追加）、PATCH（注釈／表記／コピーの意図の修正）とします。画面／状態単位で Keep-a-Changelog 形式のエントリを追加します。
4. 削除前に非推奨にする — MINOR で画面／状態を非推奨として示し（置き換え先を記載）、MAJOR で削除する前に周知します。削除時には、インベントリ行／フローからの引き渡しに引き続き参照がないことを確認し、インベントリから削除します。

ルール

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

• フロー名の付いた画面／状態ごとに、ワイヤーフレームを1つ作成します。 対象範囲は上流のユーザーフローに基づきます。孤立した画面や欠けた状態がある場合は未完成です。
• 該当するすべての状態を網羅します。 空／読み込み中／データ表示／エラーに加え、状態変更時の成功状態も含めます。正常系だけでは不十分です。真に静的な画面では、該当しない状態を省略します（画面に応じて適切に判断します）。
• 実在するコンポーネントを参照し、新たに作り出さないでください。 デザインシステムの実在するコンポーネント／トークンを明記します。カスタム対応が必要な場合は、黙って作り出すのではなく、ギャップとして明示します。
• 構造を示し、忠実度の高いデザインにはしません。 レイアウト、階層、注釈を示します。最終的なピクセル、色、書体は含めません。それらは忠実度の高いデザイン工程で扱い、トークンはデザインシステムが管理します。
• 構成に関わるアクセシビリティは担当し、コンポーネントの仕様は委ねます。 ワイヤーフレームでは、ランドマーク／見出し／フォーカス順序／名前／キーボード操作／ターゲット用の余白確保／フォーカスが隠れないこと／色以外の手がかりを扱います。デザインシステムでは、ピクセル単位のコントラスト＋フォーカスの視覚的表示＋各コンポーネント固有のターゲットサイズ／キーボード操作を扱います。デザインシステムが保証する項目を改めて判定しないでください。デザインシステムがない場合も項目を省略せず、代わりに前提条件として明示します。
• ユーザーの言葉で記述します。 データモデルの識別子をそのまま画面上のラベルに使わないでください。プレースホルダーはラベルではありません。
• アプリシェルは1つにし、グリッドに沿わせます。 すべての画面を、共通の1つのシェル内でグリッドの間隔に沿って配置します。画面ごとに作り直さないでください。
• 組み合わせて構成し、重複させないでください。 セクション構成はテンプレートツールに従い、別のアウトラインを貼り付けないでください。
• 指定されたフローをレイアウトします。 画面のセットはユーザーフローから決まり、想像で作るものではありません。ナビゲーションを再検討しないでください。
• ギャップを明示し、作り出さないでください。 定義されていない画面／コンテンツ、存在しないコンポーネント、未対応のアクセシビリティは、明示的な前提条件／未解決の質問として記載します。
• 再生成せず、修正します。 反復時はその場で編集し、バージョンと変更履歴を更新します。変更のない画面を描き直さないでください。
• 実装できなければ未完成です。 エンジニアが画面構造を実装できないドキュメントを引き渡さないでください。
• 機能範囲の境界（capability_record が提供されている場合）。 ドキュメントの出力範囲をその記録の境界内に限定します。境界外のコンテンツを作成すること（refs のエンティティを自分たちの担当であるかのように扱うこと、exit_point を越えたフローを設計すること）は、スコープ違反です。仕様にないコンテンツを作り出すことと同等です。

推奨事項（必要に応じて変更可）：

• 「包括的」という指定は目指す水準を示しますが、画面に応じた適切な範囲を保ちます。網羅性とは画面の種類に必要な判断をすべて行うことであり、文章量ではありません。単純な画面では、不要なセクションを省略します。
• ASCII 記法の凡例はドキュメントごとに一度定義し、繰り返し使用します。
• レイアウトがわかっている場合、単独のスピナーより、データ表示時のレイアウトを反映した骨組みを優先します。
• 客観的なレイアウト品質の基準はあくまで客観的なものです。主観的なレイアウトの好みを押し付けないでください。

注意点

• ハッピーパスだけの画面。 空・読み込み中・エラー・成功の状態を省くことが、最もよくある見落としです。実際の UX はこうした状態にこそ現れます。
• コンポーネントの創作。 デザインシステムで定義されていないコンポーネントやトークンに名前を付けると、システムから逸脱し、引き継ぎに支障をきたします。実在するコンポーネントを参照するか、不足を明示してください。
• フローに対するカバレッジの不足。 フローに記載された画面のワイヤーフレームが作成されていません。インベントリ表は、まさにこれを検出するためのものです。
• ハイファイへの逸脱。 正確な色、書体、ピクセル単位の間隔は構造の範囲を超え、ハイファイ／デザインシステムの範囲に踏み込みます。構造にとどめてください。
• アクセシビリティの二重評価。 デザインシステムが担うピクセル単位のコントラストやフォーカスの見た目を再指定するのは、厳密さではなく逸脱です。画面構成のアクセシビリティは担当し、コンポーネントの契約はデザインシステムに委ねてください。
• データモデルがラベルに漏れ出す。 manifest_docs のような生の識別子を表示ラベルに使うのは、スキーマが露出している状態です。人にわかるラベルと説明に置き換えてください。
• 汎用的な内容の流し込み。 どんな製品にも当てはまるレイアウトでは、この製品のフローではなく、テンプレートをレイアウトしたことになります。すべての画面を、フローのステップと実際のコンテンツに結び付けてください。
• 注釈のない静的なレイアウト。 要素ごとの注釈がない箱のスケッチは、仕様ではなく単なる図です。コンポーネント、操作要素、状態を注釈し、スケッチとの整合性を保ってください。
• 修正時の共通領域の不整合。 ある画面のアプリシェルを編集しても、それを再利用する他の画面を編集しないことが、修正時に最もよく起こる回帰です。一度の作業ですべての再利用画面に適用してください。

アンチパターン

• 「入力済みのビューだけで十分です。」 空・読み込み中・エラー・成功の状態が抜けています。該当するすべての状態を記録してください。
• 「このためにコンポーネントを適当に作ります。」 デザインシステムにある実際のコンポーネントを参照するか、不足を明示してください。
• 「画面の構成も作り直します。」 それはナビゲーションを再決定することです（ユーザーフローの役割です）。指定された画面をレイアウトしてください。
• 「アウトラインは自分で書きます。」 テンプレートツールと重複します。構成はツールから取得してください。
• 「具体的にするため、色や正確な間隔も追加します。」 ハイファイの範囲に踏み込みすぎています。構造にとどめてください。
• 「正確なコントラスト比も指定します。」 それはデザインシステムにおけるコンポーネントの契約です。色以外の意図を示し、ピクセル値はデザインシステムに委ねてください。
• 「このフローは曖昧なので、もっともらしい画面を作ります。」 代わりに、前提として明示してください。
• 「小さな変更なので、ドキュメントを再生成するだけにします。」 その場で修正し、バージョンと変更履歴を更新してください。変更のない画面を描き直してはいけません。

出力

ステップ 6 の基準を満たす、包括的で構造的なワイヤーフレームドキュメント（フローに対する完全な網羅、該当するすべての状態、グリッドと共通アプリシェルに基づく明確なレイアウト／階層と客観的なレイアウト品質基準、特定され一貫性のあるコンポーネント、注釈付きの操作要素とデータ表示、コンテンツ／マイクロコピーの意図、必要な箇所でのレスポンシブ対応、画面構成のアクセシビリティ、凡例とスケッチ⇄注釈の同期、デザインからコードへのマッピング、課題の明示、構造に限定しハイファイには踏み込まないこと、修正時のバージョン管理）。各画面には、構造化されたレイアウトの説明、ASCII／Markdown のボックススケッチ、要素ごとの注釈を含めます。抽象的な利用者は、後続のハイファイ工程と UI エンジニアリング（画面構造を構築します）、および同じ基準を満たしているかを確認するレビュー担当者です。このドキュメントの構成はテンプレートツールが担い、このスキルはコンテンツの品質を担います。

関連項目

• ワイヤーフレームテンプレートツール（コンテンツ／テンプレートゲートウェイなど）— このスキルが埋める、画面ごとの包括的なセクション構成を提供します。
• ディープリサーチ機能 — 確立された UI パターンと（存在する場合は）デザインシステムの実際のコンポーネントに基づいて、各画面を構成します。
• reviewing-wireframes — ビルド可能性＋網羅性＋構成＋レイアウト品質について、同じ基準を適用します。作成者とレビュアーが同じ基準を共有することで、基準のずれを防ぎます。
• 上流の ユーザーフロー（depends_on ドキュメント）— ワイヤーフレームが必要な画面と状態遷移を指定します。
• デザインシステム（存在する場合）— 参照する実際のコンポーネント／トークンを提供し、コンポーネントごとの a11y 契約（コントラスト、フォーカスの外観）を管理します。ワイヤーフレームはそれを参照して確保し、再定義はしません。
• 下流の ハイファイ工程 — 最終的なビジュアル／ピクセルを担当します。このスキルは構造までを対象とします。

段階的な開示

• references/composition-and-states.md — グリッド／8pt のリズム、アプリシェル、ゲシュタルト／スキャンの階層、データ表示（テーブル／開示／フォーム）のカタログ、画面ごとの状態品質ルールについて詳しく説明します。データ密度の高い画面を構成する際に読み込みます。
• references/a11y-and-amend.md — 画面構成における WCAG 2.2（SC 2.5.8 / 2.4.11 / 2.4.3 / 4.1.2 / 1.4.1、コンポーネント契約の境界）と、修正の波及／バージョン管理手順について詳しく説明します。a11y の確認や修正の際に読み込みます。
• references/sources.md — 手法と基準の調査出典です（ガイダンスの出典を監査する場合にのみ読み込みます）。

本文の上限

• description は 1,024 文字以下です（agentskills.io の上限）。
• 本文は約 500 行／5,000 トークンを目安にします（厳密な上限ではありません。品質を優先し、700 行／7,000 トークンを一貫して超える場合はフラグを立ててください）。
• 大量のコンテンツは references/ に置き、必要に応じて読み込みます。