frontend-design

フロントエンドデザイン

汎用的な「AI っぽさ」を避けた、独自性のある本番品質のフロントエンドインターフェースを作成します。意図的な美的選択を反映した、実際に動作するコードを実装します。

使用するタイミング

ユーザーから次の依頼があった場合に、このスキルを使用します。

• UI コンポーネント、ページ、またはフロントエンドアプリケーション全体の構築
• フロントエンド機能（ナビゲーション、フォーム、データテーブル、ダッシュボードなど）の設計または実装
• 美しさや使いやすさを高めるための既存インターフェースの再設計
• モックアップ、ワイヤーフレーム、または仕様の動作するコードへの変換

手順

1. 明示された依頼内容を記録します。ユーザーが示したスタイルの好み、カラーパレット、ブランドキット、またはスタイルの方向性を記録してください。指定がない場合は、デフォルトのスタイルガイドを適用します。
2. 依頼に目的と対象ユーザーが明記されていない場合は、コードを書く前に確認します。
3. 既存のコードベースを拡張する場合は、提案する前に、そのフレームワーク、CSS 変数、コンポーネントのパターンを確認します。
4. 美的な方向性（デザイン思考）を提案します。既存のコードベースでは、作成または変更するファイルも列挙します。デザイン思考ステップのレポートを出力します。
5. コードを書く前に、ユーザーの承認を待ちます。変更を求められた場合は、改めて提案します。「そのまま作って」と依頼された場合は、方向性を一行で示してから続行します。承認されないまま実行が終了した場合は、最終レポートをBLOCKEDで終了します。
6. references/aesthetics-guide.mdとreferences/usability-guide.mdのクイックルールを読みます。編集前のリポジトリ同期を実行してから、コードを実装します。フォントの組み合わせ、パレットの割り当て、アニメーションのタイミングなど、判断が明白でないデザイン上の決定には、それぞれ短いコメントを追加します。
7. 検証チェックを実行します。
   • **レスポンシブ対応：**ブラウザツールが利用できる場合は、幅375、768、1280 pxで表示し、横方向のはみ出しがないか確認します。利用できない場合は、CSS のブレークポイントを確認し、レスポンシブ表示は未テストとして記録します。
   • **コントラスト：**テキストと背景の色の組み合わせごとにコントラスト比を計算します。それぞれ4.5:1以上、24 px以上（太字の場合は18.66 px以上）のテキストでは3:1以上である必要があります。
   • **品質と使いやすさ：**デフォルトの品質基準チェックリストと、使いやすさの6つのクイックルールを確認します。
   • **ビルド：**プロジェクトにビルド、Lint、またはテストコマンドがある場合は実行し、終了結果を記録します。ない場合はbuild: not run (no command)と記録します。
8. チェックに失敗した場合は修正し、そのチェックを再実行します。2回目の修正サイクルの後は修正を終了し、残っている失敗を最終レポートに列挙します。
9. 実装ステップのレポートを出力し、その後に最終レポートを出力します。

編集前のリポジトリ同期（必須）

手順6で最初にファイルを書き込む前に、一度だけ実行します。同期対象はコードを書き込むディレクトリです。

1. repo="$(git -C "<target dir>" rev-parse --show-toplevel)"を実行します。失敗した場合は同期をスキップし、sync: skipped (not a git repo)と記録します。
2. git -C "$repo" remote get-url originを実行します。失敗した場合は手順3～7をスキップし、sync: skipped (no origin)と記録します。
3. branch="$(git -C "$repo" rev-parse --abbrev-ref HEAD)"を実行します。出力がHEADの場合は手順4～7をスキップし、sync: skipped (detached HEAD)と記録します。
4. git -C "$repo" status --porcelainを実行します。出力が空の場合は、git -C "$repo" fetch origin && git -C "$repo" pull --rebase origin "$branch"を実行します。
5. 出力が空でない場合は、git -C "$repo" stash push -u -m "frontend-design pre-sync"を実行してから、同じfetchとpullを実行し、その後git -C "$repo" stash popを実行します。
6. リベース開始前にfetchまたはpullが失敗した場合（ネットワーク、認証、リモートブランチがない場合など）は、再試行しません。手順5でstashした場合はgit -C "$repo" stash popを実行し、sync: failed (<first error line>)と記録して続行します。
7. リベースで競合が発生した場合は、git -C "$repo" rebase --abortを実行します。手順5でstashした場合は、その後git -C "$repo" stash popを実行します。stash popで競合が発生した場合は、stashを残します。いずれの場合もファイルを書き込まず、今後の進め方をユーザーに確認します。回答がない場合、ステータスはBLOCKEDです。

このスキルではコミットを行いません。

デザイン思考

コーディングを始める前に、適用するスタイルの出典を特定し、明確な美的方向性を決めます。

• ブリーフの優先順位：明示的なブリーフがある場合は、それに従います。ない場合は、以下のデフォルトスタイルガイドが適用されます。4つの基本色（ステータスカラーをテキストのみに使用する例外を除く）と、洗練され、明快で、すっきりとしたプロフェッショナルな表現を維持し、基本色を増やすのではなく、構成、タイポグラフィ、余白、奥行き、動きによって個性を出します。
• 目的：このインターフェースはどのような問題を解決しますか？誰が使いますか？
• トーン：明示的なブリーフがある場合は、その方向性を尊重します。ない場合は、極端にミニマル、マキシマリスト、レトロフューチャー、オーガニック／ナチュラル、ラグジュアリー／洗練、遊び心のある表現、エディトリアル／雑誌風、ブルータリスト／生々しい表現、アールデコ／幾何学的、ソフト／パステル、インダストリアル／実用重視などから選びます。ただし、その方向性がデフォルトスタイルガイドと矛盾しない場合に限ります。
• 制約：技術要件（フレームワーク、パフォーマンス、アクセシビリティ）。
• 差別化：このインターフェースについて、誰かが覚えているであろう特徴を1つ挙げます。

大胆なマキシマリズムも洗練されたミニマリズムも、適用するスタイルの出典に合っていれば有効です。重要なのは強さではなく、意図が明確であることです。

デフォルトスタイルガイド

ユーザーから明示的なブリーフがない場合は、このスタイルガイドを適用します。

1. カラーパレット（厳格に限定）：基本色は4色のみとします。黒（#000000）、白（#FFFFFF）、グレー（#6B7280）、ブライトグリーン（#22C55E）です。
2. 美的表現：洗練され、明快で、すっきりとしたプロフェッショナルなデザイン表現を保ちます。
3. 視覚的な奥行き：カード、線、枠線、控えめな影などの要素を使って、視覚的な奥行きを加えます。
4. ブライトグリーンの使用制約：ブライトグリーンは強調表示（テキスト、枠線、線）にのみ使用します。背景色としては決して使用しないでください。
5. システムステータスカラー：危険（#EF4444）、警告（#F59E0B）、情報（#3B82F6）は、背景や主要な UI コンポーネントではなく、テキスト要素にのみ使用できます。

明示的なブリーフで上書きできるのは、パレットと美的表現のデフォルトのみです。アクセシビリティ要件と、システムステータスカラーをテキストのみに使用するルールは上書きできません。

デフォルトの品質基準

最終的なデザインはすべて、依頼の有無や美的方向性にかかわらず、プロフェッショナルで、本番環境に対応でき、洗練され、上質でなければなりません。ブリーフはスタイルを定め、この基準は仕上がりを定めます。上質さは、references/aesthetics-guide.md の Avoid に記載されたありきたりな表現ではなく、技術と実行によって生まれます。納品前に以下を確認します。

• 余白のリズムと文字サイズの階層に一貫性があり、エッジがピクセル単位で整列している
• パレットに意図があり、角丸、枠線、影に統一感がある
• すべてのインタラクティブ状態に対応している：ホバー、フォーカス、アクティブ、無効、さらに必要に応じて読み込み中／空／エラー
• プレースホルダー、lorem ipsum、TODO、壊れたアセットがなく、下書きに見える箇所がない
• 明示的なブリーフで指定されている場合を除き、Avoid に記載されたデフォルトの表現を使用していない

ユーザビリティと美的表現に関する参考資料

• ユーザビリティ：すべてのデザインで references/usability-guide.md の6つのクイックルールを適用します。その後に、手順を追った完全なガイドラインが続きます。
• 美的表現：references/aesthetics-guide.md には、タイポグラフィ、色、動き、構成、背景に関する指針と Avoid リストがあります。

ブリーフと承認の段階でコンテキストウィンドウを小さく保つため、両方ともステップ6で読みます。それより前には読みません。

期待される出力

1つ以上のファイルとして提供される、本番環境で使用できるフロントエンドコード。ランディングページを依頼された場合の例：

• index.html — CSS と JS を埋め込んだ、完全に自己完結した HTML（または、フレームワークを使用する場合は別ファイル）
• 実装する機能：ヒーローセクション、CTA ボタン、レスポンシブナビゲーション、機能紹介グリッド
• タイポグラフィ：特徴のある見出し用／本文用フォントの組み合わせ（例：Playfair Display + DM Sans）。Inter/Roboto は使用しないでください
• カラーパレット：デフォルトスタイルガイドで定められた4色のみ、または明示された依頼内容のパレットを使用
• インタラクション：ボタンのホバー状態は CSS のみで実装し、ページ読み込み時に順番に表示されるアニメーションを適用
• すべてのテキスト要素で WCAG AA のコントラストを確保
• 375px、768px、1280px でモバイル対応レイアウトを確認

最終レポート

停止時も含め、毎回最後にこの簡潔なテキストブロックを出力します。ステータスは COMPLETE（コードが記述され、チェックに失敗なし）、PARTIAL（コードは記述されたが、2回目の修正サイクル後もチェックが失敗）、または BLOCKED（コードは未作成）です。ユーザーの回答待ちの質問がある場合、実行は終了しません。回答がないままユーザーが実行を終了した場合、ステータスは BLOCKED です。記入ルール、PARTIAL と BLOCKED の例、および読み手によるチェックについては、references/final-report.md を参照してください。例：

Result: COMPLETE. Wrote index.html (landing page: hero, CTA, nav, features grid).
Evidence: Contrast lowest 4.8:1 (Gray on White). Quality Bar and usability Quick rules passed. build: not run (no command). sync: skipped (not a git repo)
Uncertainty: Responsive rendering untested: no browser available; breakpoints at 375/768/1280 px inspected in CSS. Assumed a developer audience; the brief did not say.
Decision: No approval needed. Replace the placeholder logo with your own asset.

受け入れ基準

次のすべてを満たした場合、実行は合格です。

• コードを記述する前に、ユーザーがデザインの方向性を承認するか、「そのまま作ってください」と伝えている。
• 提供したコードが対象のフレームワーク（HTML/CSS/JS、React、Vue など）でエラーなく動作する。ビルドコマンドがある場合は、実行に成功している。
• 375px、768px、1280px でレイアウトに横方向のオーバーフローがない。または、最終レポートにレスポンシブ表示が未テストであることを記載している。
• アクセシビリティの基本要件に対応している：セマンティック HTML、テキストのすべての組み合わせで WCAG AA のコントラストを確保、キーボードフォーカス状態、該当する場合は alt/aria-label を設定。
• 明示的な依頼内容がない場合、デフォルトスタイルガイドの色のみを使用し、ブライトグリーンを背景色に使用していない。
• デフォルト品質基準のすべての項目と、ユーザビリティのクイックルールのすべてを満たしている。または、最終レポートに未達項目を記載している。
• 最終レポートは Result: とそのステータスで始まり、Evidence:、Uncertainty:、Decision: の各行を含む。Evidence: には実行したチェックのみを記載する。
• 最終レポートが references/final-report.md の読み手による4つのチェック（結果が見つけやすい、事実と仮定が分けられている、主張を根拠までたどれる、次の判断が明確）を満たしている。人間のレビュー担当者から回答がない場合、人間が内容を理解したかどうかは未確認。

エッジケース

• スタイル上の制約が矛盾する場合（例：「ミニマルに」と「アニメーションを多用して」の両方をユーザーが指定）：矛盾点を示し、どちらを優先するか確認してください。黙って一方を選んではいけません。
• 既存のコードベースを拡張する場合：手順3で確認したデザインシステムと併存する、2つ目のデザインシステムを新たに導入してはいけません。
• フレームワークが一致しない場合（例：ユーザーは「React」と指定しているが、リポジトリでは Vue を使用）：生成前にフレームワークを確認してください。Vue プロジェクトに React JSX を出力してはいけません。
• 異なるページセクションが5つを超える場合：1つの巨大な成果物として一括で作成するのではなく、まず基本レイアウト、次に二次的なセクションという段階的な提供を提案してください。
• アクセシビリティとデザインの方向性が矛盾する場合：デザイン上の理由で WCAG AA のコントラストを下回ってはいけません。代わりに色の組み合わせを変更してください。
• デプロイ先でインターネット/CDN にアクセスできない場合：ユーザーがオフライン環境またはエアギャップ環境であることを示した場合、CDN リンクではなく、ローカルにバンドルしたアセットか、インラインのクリティカル CSS/JS を使用してください。

ステップ完了レポート

ステップ4でデザイン思考レポート、ステップ9で実装レポートを出力し、その後に最終レポートを出力してください。テンプレート、記号の凡例、フェーズごとのチェックについては、references/step-reports.md を参照してください。エージェントのコンテキスト予算を保つため、これらのレポートは簡潔にしてください。