html

HTML

題材をより明確に、使いやすく、理解しやすくする、自己完結型の HTML ファイルを 1 つ作成してください。求められるのは、一貫した見た目ではなく、一貫した丁寧さです。過去の実行で使った配色、タイポグラフィの構成、カードシステム、レイアウトを再現しないでください。

まず依頼の種類を見極める

中心となるレビューの問いを担当する、最も範囲の狭いスキルを使ってください。

• 配色、書体、構成、テーマ、全体的なビジュアルの方向性が定まっていない場合は、選択したワークフローと合わせて design-artifact を読み、内容を組み立ててください。クリエイティブな方向性を示すものであり、忠実性、構成、動作を担当する専門スキルに取って代わるものではありません。
• 構成、情報の階層、ナビゲーション、タスクの流れがまだ定まっていない場合は、html-wireframe を読んで従ってください。目に見えて低忠実度の状態を保ち、レイアウトの方向性を 2、3 種類比較してもかまいません。
• 洗練されたモックアップや、動作するインタラクティブなフローが必要な場合は、html-prototype を読んで従ってください。モックアップは、このスキルにおける静的な忠実度モードです。
• 成果物が主に計画、ロードマップ、実装手順、または展開ドキュメントであり、元の要件を容易に確認できる状態に保つ必要がある場合は、html-plan を読んで従ってください。
• 関係、順序、トポロジー、状態、階層、システムの動作が主な内容の場合は、html-diagram を読んで従ってください。
• レポート、解説資料、プレゼンテーション、ランディングページ、データストーリー、ツール、およびより適切な担当スキルがない複合的な成果物には、html を使い続けてください。

これらの兄弟スキルへのリンクは、コレクションが一緒にインストールされている場合の入れ子構造を担います。専門スキルが利用できない場合は、ここで作業を続け、以下の最も近いリファレンスを読み込んでください。依頼を完了する前に、ユーザーに別のスキルのインストールを求めないでください。

デザインする前に状況を把握する

ユーザーの依頼と、提供された資料を確認してください。リポジトリで作業する場合は、AGENTS.md、CLAUDE.md、デザインシステムのドキュメント、トークン、既存のコンポーネント、近くにある成果物を調べ、そのデザイン言語を把握してください。

優先順位は次のとおりです。

1. ユーザーによる明示的なビジュアルおよび機能上の指示。
2. プロジェクトで確立されているデザインシステムと規約。
3. 成果物の題材、対象者、目的。
4. 自分自身のデザイン上の判断。

コーディングを始める前に、作業メモで次の 5 点を決めてください。

• 対象者と目的： 誰が使い、何を理解したり実行したりする必要があるか。
• 形式： ドキュメント、プレゼンテーション、インターフェース、図解、データビジュアライゼーションのいずれか。
• トーン： 落ち着いた実務的なもの、洗練された編集的なもの、意図的に表現豊かなもののいずれか。
• 忠実度： ユーザーの構成や文言を保つか、より自由に再構成するか。
• インタラクション： 探索、順序づけ、フィルタリング、動きが役立つかどうか。

プロジェクト内ですでにビジュアルに関する問いへの答えが示されている場合は、それに従ってください。そうでなければ、利用可能な場合は design-artifact を読み、内容を組み立ててください。コレクションが兄弟スキルなしでインストールされている場合は、配色、書体、構成、動きを選ぶ前に references/creative-direction.md を読んでください。

成果物に必要なガイダンスだけを読み込む

• レポート、ブリーフ、計画、解説資料、スライド資料では、references/documents-and-presentations.md を読んでください。
• この幅広いスキルの範囲にあるインターフェース、計算ツール、その他のツールでは、references/interfaces.md を読んでください。
• アーキテクチャ、プロセス、順序、状態、階層、概念の図では、references/diagrams.md を読んでください。
• 定量的なグラフ、表、指標、データストーリーでは、references/charts-and-data.md を読んでください。

依頼が複数の形式にまたがる場合があります。実質的に関係するリファレンスをすべて読み込み、成果物全体に一貫した方向性を持たせてください。

ビルド要件

• 重要な CSS と JavaScript をインラインで含む .html ファイルを 1 つ作成します。ビルド手順なしで直接開いて動作するようにしてください。ユーザーが外部依存を許可しない限り、ネットワーク接続は不要にしてください。
• 実際のコンテンツを使用します。目立つ場所をプレースホルダーの文章、装飾的な統計情報、何もしないコントロールで埋めないでください。
• コンテンツに合わせて構成を決めます。順序のある内容は順番に読めるようにし、比較では違いを見つけやすくし、インターフェースでは状態と操作を明確にし、図では関係性を把握しやすくします。
• セマンティック HTML、レスポンシブレイアウト、十分なコントラスト、視認可能なキーボードフォーカス、動きを抑える設定への対応を使用します。インタラクティブ要素はキーボードで操作できるようにします。
• ページの本文に意図しない横方向のオーバーフローが発生しないようにします。意図的に幅の広いコンテンツは、領域内でスクロールまたはパンできるようにします。
• 選んだデザイン方針に合わせて少数の CSS トークンを定義し、一貫して使用します。トークンは実装手段であり、あらかじめ決められたカラーパレットではありません。
• 動きは説明やフィードバックとして扱います。アニメーションをなくしても意味や有用なフィードバックが失われない場合は、削除します。
• ユーザーまたはプロジェクトのテーマ方針に従います。方針がない場合は、使いやすさが向上するなら、長く使える実用的な成果物としてライトテーマとダークテーマを検討します。意図の明確な単一テーマも有効です。

作業を仕上げる

ファイルを指定された場所に書き込むか、現在のワークスペース内で分かりやすいファイル名を選びます。ブラウザツールが利用できる場合は、ファイルを開いて幅の広い画面と狭い画面で確認します。コントロールを操作し、コンソールを確認して、クリッピング、重なり、読みにくいテキスト、壊れた状態、意図しないオーバーフローを修正します。

納品前に、独自性を一度確認します。題材を近接する別のトピックに置き換えても同じビジュアルコンセプトがそのまま通用するなら、方向性が汎用的すぎます。構成、書体、色、画像、インタラクションを見直し、その題材にふさわしいものにします。

絶対パスと、成果物のビジュアル面およびインタラクションの工夫を簡潔に説明した文章を返します。