frontend-art-direction

フロントエンドのアートディレクション

プロセスを高コストで曖昧、あるいは大げさなものにすることなく、目に見えるプロダクトを改善します。基本的な成果物は、明確な視点を持ち、すべての状態が揃い、有用なモーションと視覚的な根拠を備えた、動作する UI です。

運用上の取り決め

• スタイル、ライブラリ、フォント、アニメーション、ヒーローレイアウトを選ぶ前に、プロジェクトを調査してください。
• ユーザーのワークフロー、コンテンツ、デバイス、既存システムを信頼できる情報源として扱ってください。外部の参考資料は明示された不足を補うものであり、プロダクトへの理解に取って代わるものではありません。
• コンテンツやメディアが弱い場合は、抑制された表現を用いてください。強い表現は、実在する被写体、制作された素材、意味のあるデータ、メディア、または空間的な関係性によって裏付けられる必要があります。プロダクトのテンプレートにする必要はありません。
• アセットの優先順位は、ユーザー提供のもの → 既存／公式のもの → 検索で見つけた高品質のもの → 生成したもの → 意図的にアセットを使わない構成です。プレースホルダー、解像度の低い埋め草、無作為なストック素材、明らかに不自然な生成メディアを決して引き渡さないでください。
• メディアは、ファイルの寸法や出典の知名度だけでなく、想定する閲覧距離で実際に見える被写体に基づいて評価してください。大きな画像でも、被写体が小さすぎたり、判別できなかったりすることがあります。各ファイルの正確な記録とクレジットを確認してください。アーカイブ名だけでは、そこに含まれる素材の種類、作者、権利は特定できません。
• 重要な各サーフェスには、仕上げの品質を高める工程を設けてください。グレースケールの階層、光学的な配置、文字の上限、マテリアルのレイヤー、具体的な文言、そして控えめに作り込んだディテールを確認してください。「プレミアム」とは、グラデーション、ガラスのレイヤー、大きな見出し、空白だけを意味するものではありません。
• まずローカルのプリミティブを再利用して修正してください。一般的なコントロールには成熟したコンポーネントを使い、デフォルトの見た目のまま出荷するのではなく、トークン、密度、状態を調整してください。
• 雰囲気づくりのために依存関係を追加しないでください。不足している機能を特定し、現在のライブラリやドキュメントを調べ、インストール前に互換性のある最も軽量なリソースを選んでください。
• 重要な各工程には、少なくとも1つの意味のある状態遷移と、視差を抑えた動きまたは静的なフォールバックを設けてください。
• コードを書く前に、Visual Direction Contractを出力してください。これには、構成の文法、領域ごとの配置／テキストの整列／寸法と隣接関係、占有率、ビューポートのフィールド、サーフェスの境界、間を置く目的、ジオメトリのトークン、主役とカウンターウェイト、文字の上限、間隔のリズム、サーフェスの予算、エッジの特性、角の階層、分離と線の方針、視覚的な処理、シグネチャーデバイス、権威ある情報源、AIのデフォルト設定に関する助言的なチェックを含めます。リゾルバーは、中核となる領域に加えて破棄可能な任意候補と、独自にレンダリング可能な領域マップ、構成予算、空間予算、空間の目的、および作成済みのマップがない場合のワイド／中間／ナローの判断を備えた、差し替え可能な3つの構造仮説を生成する必要があります。空間予算では、有効なカウンターフィールド、自然な占有率、狭いガター、連続するフルブリードのリスクを明示します。これらは差し替え可能なレンダリング候補として扱い、ページテンプレートとして扱わないでください。ローカルの方向性を示す記録は、実際の被写体に即した主張が定まるまでは候補として扱ってください。大規模なレイアウト作業では、references/visual-composition.mdを参照してください。ローカルの整列軸がページ全体を決めるわけではありません。
• 厳守すべき不変条件と、視覚上の好みを分けてください。アクセシビリティ、該当するタスク／状態または制作した体験の完全性、レスポンシブな使いやすさ、アセットの信頼性、動きのフォールバック、ランタイムの完全性、レンダリング結果の検証は必須です。ローカルのAI対策チェックは助言であり、プロジェクト独自のDESIGN.md、調査済みの参考資料、採用されたコンセプト、ユーザーの明示的な指示、またはオーバーライドの記録を伴う強力なモデル提案によって上書きできます。
• 実装前にクリエイティブ・ダイバージェンス・チェックを行ってください。重要度の高い自由度のある作業では、実際の対象、コンテンツ、タスクに基づく、構造的に異なる2〜3案を作成します。読み取り順、主役となるオブジェクト、シルエット、文字とメディアの関係、インタラクションモデル、レスポンシブ対応の実現性を比較し、ローカルの候補との一貫性を保つのではなく、最も筋の通った主張を採用してください。
• 重要な作業では、references/design-production-loop.mdを実行し、20のチェックポイントすべてを、機械的な書き直しではなく、判断と証拠をもって完了してください。
• レンダリングされた画面を反復して改善してください。キャプチャ条件を確認し、目に見える欠陥を調べ、コードまたはアセットを変更してから、再度キャプチャして比較します。デフォルトのスクリーンショットだけでなく、実際のコンテンツと連続したワークフローを検証してください。操作によって視覚状態が変化する場合は、変更後のオブジェクトまたは結果を表示したままにし、関連する最も深いスクロール位置からその操作を試してください。モバイルでは重要な遷移先を保持するか、同じくらい直接的な代替手段を用意してください。キャプチャを承認する前に、フォント、画像、表示開始時の動きを確定してください。実際の反復回数は20のワークフローチェックポイントとは別に数えてください。静的なコードやビルドの成功だけでは、視覚的な合格とはなりません。利用可能な接続済みブラウザー、または対象のPlaywright/Puppeteerを使い、ワイド、標準、中間、ナローの各幅でジオメトリの証拠を取得してください。references/verification.mdのスナップショット手順には、追加のブラウザー依存関係は不要です。オーバーフロー、各サーフェス内側の余白、読みやすい幅の制限、ローカルの整列の組み合わせを確認してください。監査結果はスクリーンショット批評の手がかりとして扱い、好みの判定として扱わないでください。
• 事実、仮定、不足している証拠、ブロッカーを明示してください。一般的な称賛や長いデザイン論に、ユーザーのトークン予算を費やさないでください。

リクエストのルーティング

リクエストに回答できる最小のモードを使い、現在の画面を Persuade、Operate、Read、Experience のいずれかに分類します。これは製品単位ではなく、ルート単位で行います。

1. すばやく磨き上げる：コンポーネント、状態、または局所的な余白・文字組み・色の問題が1つだけの場合です。局所的なパターンを確認し、目に見える最小限の変更を加えて、その状態を検証します。
2. 製品 UI：アプリ、ダッシュボード、エディター、設定、コマース、開発者向けツール、または埋め込み画面の場合です。タスクの明確さ、情報密度、信頼性、状態の網羅性、レスポンシブな入力動作を最適化します。
3. メディア主体：ランディングページ、ポートフォリオ、ローンチページ、製品紹介、モデルビューアー、または空間的な画面の場合です。最初の画面では、実際のメディアや意味のあるオブジェクトを主役にします。どちらも適さない場合は、同じ訪問者の意図に応えるため、タイポグラフィ、素材、またはコンテンツを主役にした構成を検討します。
4. 参考サイトに基づく実装：ユーザーが「像/类似/参考某个网站」と言う、または URL を指定して動作する成果物を期待している場合です。ムードボードの依頼ではなく、実装作業として扱います。
5. 方向性のみ：ユーザーが実装なしで選択肢、計画、または分析を求めている場合です。簡潔な方向性の決定と実装の取り決めを返します。

作業規模が大きい場合、要件が曖昧な場合、または複数の画面に影響する可能性がある場合は、references/operating-modes.md を読みます。surface-mode と design-operation を使って、ページの意図とフィードバックを明確な次のアクションに変換します。

4つのパス

1. 調査

フロントエンドに関するすべてのリクエストで、まず判断パイプラインを実行します。小規模な局所修正ではスキャンと回答を簡潔にしますが、機能の確認は省略しません。<skill-root> はこの SKILL.md を含むディレクトリを指します。インストーラーがその場所を直接公開しない場合は、コマンドを実行する前にディレクトリを特定してください。

node <skill-root>/scripts/audit.mjs <project-root> \
  --query "<product, screen, or implementation question>" --format md

このコマンドは、大規模なパスを実行するたびに、ローカルの根拠、依存関係グラフ、決定論的なビジュアル lint、デザインインテリジェンス、保存済みのすべての参照レンズ、リソースの出所、参照／実装の取り決め、内部の Transitions.dev モーションレビュー、および簡潔な Decision / Changed / Proof / Open の取り決めを含む、ローカルパイプライン全体を実行します。モーションはデフォルトで有効です。プライベートなモーションキャッシュを更新してはならない場合にのみ、--offline を追加してください。

より範囲を絞って確認するには、ローカルスキャナーを直接実行します。

node <skill-root>/scripts/inspect-project.mjs <project-root> --format md

リポジトリが大きい場合や、質問が具体的な場合は、広く読み始める前にローカルマップを検索します。

node <skill-root>/scripts/project-map.mjs <project-root> \
  --query "where is the settings form and its validation state?" \
  --format md

根拠がある内容だけを記録します。フレームワークとスクリプト、ルート、コンポーネント、トークン、アセット、既存のデザインメモリ、脆弱なプリミティブ、制約を確認します。長期的な対象者、主題、目的についてはルートの PRODUCT.md を読み、ビジュアルの方向性を記した DESIGN.md とは別に扱います。現在のページ要件を優先します。任意のセットアップについては、references/design-system.md に記載されています。プロジェクトを実行できない場合はその旨を伝え、静的なスキャンにとどめます。

ファイル間の関係が重要な場合は、パス名だけに頼らず、リポジトリグラフを検索します。

node <skill-root>/scripts/project-graph.mjs <project-root> \
  --query "where is the settings form and its validation state?" \
  --format md

外部の参考資料を使う場合は、スキャン後にローカルの参照資料一覧をすべて読み込み、役割の異なる実装レンズを最大2～4個選びます。具体的な依頼では、ドメイン／コンポーネント／モーションのレンズに加えて、ページ全体の構成とレスポンシブ対応の候補も必ず確認します。すべての参考資料を検討し、根拠があり、重複しない判断だけを適用します。取り入れる点、採用しない点、変換する点を記録します。

node <skill-root>/scripts/reference-composition.mjs \
  --query "<product, screen, or implementation question>" \
  --profile "<product profile>" --style "<candidate stance>" \
  --motion "<motion intent>" --format md

ロールモデルについては、references/reference-composition.md をお読みください。Siteinspire、Awwwards、MUUUUU、Behance、Dribbble、Mobbin、Pinterest、Huaban、Muzli、Eagle Blog は、ページ全体の構成、素材、コンポーネント、ワークフロー、レスポンシブ対応を検討するための発見の手がかりです。参考にする前に、元のページをたどってください。Rare UI、Rewamp UI、Beautiful UI、beUI、Magic UI、React Bits、Aceternity UI、Obsidian UI は、ビジュアルや実例を探す手がかりです。Rewamp UI は、コンポーネントに焦点を当てたワークベンチです。Bencho と Design Spells はマイクロインタラクションの調査に、Transitions.dev はモーションのガバナンスに、shadcn/ui はソース管理下にある基盤に役立ちます。どれを使うかは、この仕事に必要なものをセレクターで判断し、固定の一式を強制しないでください。

ユーザーがプロダクトの種類だけを示し、具体的なケースを示していない場合は、クエリとローカルの根拠から暫定的なプロファイルを推定し、ページ全体とレスポンシブ対応の調査を開始してください。確信度と未解決の根拠を明示し、ドメインやコンポーネントの手がかりは追加の情報として扱います。依頼が「做一个网站」またはそれに相当する内容だけの場合は、適応型のデフォルトを使用し、コマース、ダッシュボード、エディトリアルの構成を推定しないでください。保存済みの例からビジュアルの方向性を作り上げないでください。

具体的なケースの指定がない重要な作業では、scripts/reference-scout.mjs を実行し、references/reference-discovery.md をお読みください。このスクリプトは、未決定の事項に応じた調査チャネルを提示し、対象がローカルカタログにない場合も調査を継続できるようにします。ギャラリーで見つけた候補は、元のウェブサイトまたは完成したプロジェクトまでたどってください。参考にする前に、構成、全体の範囲、レスポンシブ時の挙動を確認してください。地理、人気、固定のページジャンルではなく、タスクへの適合性と実証された品質で選びます。ハードウェアの候補が役立つのは、実際の対象がハードウェアの場合に限ります。ページ全体の関係性を決めてから、特定の用途にコンポーネントとモーションの手がかりを加えてください。

ビジュアル主導の画面では、references/creative-direction.md と references/visual-iteration.md をお読みください。未解決の構成や表現手法を検討するため、コーディング前に利用可能な画像生成を活用してください。あるいは、最初の描画が平凡な場合は、確認済みのブラウザーのスクリーンショットを編集してください。image-proposal で案を記録し、明示的に選択してから、ビジュアルの差分をコードと利用可能なアセットに反映し、新たに実際の描画と比較してください。ローカルな修正や方向性が決まっているデザインでは、画像生成を省略してください。コンセプトによってローカルの方向性を全面的に置き換えてもかまいません。

表示するメディアが重要な場合は、references/assets.md をお読みください。ユーザー提供のアセットを優先し、それ以外の場合は、出典を明示できる高品質なソースを探すか、用途に合わせたメディアを生成してください。品質基準を満たすものがない場合は、プレースホルダーを挿入せず、アセットを使わない完成した構成にするか、阻害要因を報告してください。

依頼で参考ウェブサイトが指定されている場合、または「これに似たものを作って」と言われた場合は、編集前に実装契約を作成してください。

node <skill-root>/scripts/reference-build.mjs \
  --query "<one-sentence request>" --project <project-root> --format md

references/reference-build.md をお読みください。この契約は構築の入力となります。含める内容は、ビジュアルの特徴、最初のビューポート、ページ計画、主要／任意の領域、構成と空間の予算、コンポーネントの文法、状態／モーションの契約、レスポンシブ時の再配置、アセットのフォールバック、構築順序、受け入れ基準です。対象プロジェクトのコード作成とブラウザーでの検証も続けて行い、ビジュアルの最終確認前に layout-audit を実行して、シェルのリズム、ビューポート帯域、狭いガター、ローカルアンカーの根拠を確認してください。

重要な依頼では、短いフレームを作成してください。

Goal / workflow:
Surface / device / input:
Density / frequency:
Real content, data, and media:
Critical states:
Top visible problems:
Risk if wrong:

2. 選定する

ローカルのブリーフ生成ツールは候補を得るために使い、絶対的な基準として扱わないでください。

node <skill-root>/scripts/design-brief.mjs \
  --query "<product and screen>" \
  --project <project-root> \
  --format md

タイポグラフィ、色、コンポーネントの形状、コンテンツの準備状況、または永続的な DESIGN.md を選ぶ際は、references/design-system.md を読んでください。ブリーフには、次の項目を明記する必要があります。

• プロダクトのプロフィール、訪問者向けサーフェスのモード、デザインの方向性
• デザインのスタンスと、特徴となるひと工夫
• タイポグラフィの上限と役割
• コンポーネントの形状表現、ジオメトリーの階層、カードの予算
• ビジュアルディレクション契約：ファーストビューの構成、各領域の配置／テキストの揃え方／寸法、隣接要素との関係、画面幅に応じた再配置、主役／対比要素、間隔のリズム、サーフェスの予算、エッジの特性、角の階層、区切り線の方針、ビジュアルのスタンス／シグネチャーデバイス、権威ある根拠、参考情報としての AI のデフォルト設定チェック
• モーションの目的とフォールバック
• 意図的に使用しないもの
• 確信度と根拠の不足
• シーンの調整項目、品質ゲート、アンチパターンの監視リスト、実装チェック
• 役割に基づく参考構成と、取り入れる／却下する／翻案する判断

大規模な汎用ビルドを行う前、または結果が四角張っている、硬い、細かく分断されている、あるいは鋭すぎるというフィードバックがあった場合は、references/geometry-language.md を読んでください。あらゆる場所に角丸カードを使うのではなく、構造を和らげたジオメトリーと、枠線に頼らないグルーピングを基本としてください。プロダクトまたはより強い権威ある根拠が正当化する場合は、鋭いジオメトリーを維持してください。

プロジェクトに DESIGN.md がある場合、ユーザーが明確なビジュアルの方向性を示す場合、または参考資料がローカルのデフォルトと矛盾する場合は、references/constraint-authority.md を読んでください。自由度の高い再デザインや独自の提案では、references/creative-direction.md を読んでください。最も強い根拠に基づく方向性を基準とし、デザインを画一化するのではなく、不足を補うためにローカルのデータセットを使ってください。

ユーザーが高級感、プレミアム感、洗練、ラグジュアリー、高級、質感を求める場合、または最初のレンダリングがありきたりに見える場合は、references/premium-finish.md を読んでください。別の参考資料や依存関係を追加する前に、仕上げのパスを実行してください。タイポグラフィと画像の関係、読み進めるリズム、素材感、情報の順序、または表現力のあるモーションをさらに強化するには、references/design-methods.md を読んでください。ソースが明示された手法は、対象に合わせて組み合わせ、拡張、置き換えができます。マッチャーに結果がない場合は、独自の提案を行うこともできます。

方向性が本当に曖昧で、後から変更するコストが高い場合に限り、方向性を確定するまで作業を止めてください。それ以外の場合は、方向性に関する仮定を記録して作業を続けてください。選択肢を提示する際は、構造的に異なる案にしてください。同じありきたりなスタイルの見た目だけを変えた案を3つ提示してはいけません。

3. 構築

大規模な作業では、references/implementation.md を読んでください。装飾的なスタイリングの前に、構成とインタラクションのモデルを構築します。

• まず references/product-prototype.md を適用し、作業に適したエビデンスモードを選びます。機能的なプロダクトでは、実用可能な縦断スライスが必要です。ナラティブ、アートディレクションを重視したもの、実験的な作品では、主題、主張、注意を導く経路、作り込まれた根拠、意図的な結末が必要です。具体的な依頼で needs-target-proposal または汎用的な目的フィールドが返された場合は、references/creative-direction.md に沿って productSignal、ビジュアル上の主張、完全なスコープを内部で作成してから実装します。ユーザーにスキーマの補完を求めたり、提案の段階で止めたりしないでください。ページのジャンルは指定されていません。

• 磨き込みに入る前に、完了させる範囲全体を明示します。最初のビューポートは受け入れ基準の基点であり、完了の定義ではありません。意図したすべての領域、状態、レスポンシブ対応、アセット、遷移先、結末を仕上げてください。

• 最初に読む内容、主要なアクション、情報の階層、レスポンシブ時の再配置

• 関連する場合は、ローカルまたは成熟したプリミティブを使い、ホバー、フォーカス、押下、無効、読み込み中、空、エラー、成功、選択済み、一部データの各状態を完全に実装する

• 現実的なコピーやデータと、選択したモードにある場合は、実際の主題、プロダクト、成果物、またはワークフローの対象

• 装飾的なループではなく、実際の状態に結び付いた独自のインタラクションを1つ

• アクセシブルなキーボード／タッチ操作と、動きを抑える設定への対応

リファレンスを基に構築する場合、対象にコンテンツ、作者、ワークフローがあるときは、それらを維持しつつ、リファレンスのビジュアル表現を取り入れます。ロゴ、ブランド名、プロプライエタリアセット、ソースコード、完全に同じコピー、または見分けがつかないページ全体の複製は避けてください。「似ている」とは、階層、素材感、リズム、見本の挙動、シーケンス、動きの目的を同程度に保ち、それらを対象の作品に合わせて翻案することを意味します。

コンポーネント、動き、チャート、アイコン、メディア、または3Dの依存関係を追加する前に、references/resources.md を読んでください。実行可能なカタログを使って選択肢を絞り込みます。Bencho と Design Spells は、ソース、ライセンス、実装の根拠が別の判断を示さない限り、インスピレーションの参考に限ります。Rewamp UI、Magic UI、React Bits、Aceternity UI、Obsidian UI は、コピーして調整する候補として扱い、デフォルトのスキンとして使用しないでください。

node <skill-root>/scripts/resource-catalog.mjs \
  --query "<missing technical job>" --stack <detected-stack> --format md

完全な監査では、必ず内部のモーションブリッジを開きます。実装で動き、スクロール、ルート間の連続性、GSAP、3D、またはモデルの挙動に関する詳細なルールが必要な場合は、references/motion.md を読んでください。レビューした状態の関係性からアニメーションが妥当でないと判断した場合は、最終的な画面を静的なままにしてもかまいません。

大規模な作業では、最終的に状態を静的に保つ判断をする場合でも、編集前に必ず内部の Transitions.dev ブリッジを実行してください。必要に応じて、固定された上流 Skill をプライベートキャッシュに取得し、レシピのソースと Review -> Apply -> Polish の契約を返します。ユーザーが別のスキルをインストールしたり、実行したりする必要はありません。

node <skill-root>/scripts/transitions-adapter.mjs \
  --intent "<state or relationship>" --project <project-root> --phase all --format md

適用する前に、返された上流リファレンスを読んでください。必要なレシピだけを対象プロジェクトにコピーし、クリーンアップと再生の挙動を維持して、動きを抑える設定へのガードを残し、静的表示または最終状態のフォールバックを用意します。レシピを再現するだけのために、モーション依存関係を追加しないでください。

4. 検証

references/verification.mdを読みます。対象を実行し、キャプチャの実際のビューポート、読み込み済みアセット、フォントとアニメーションの安定状態、状態、スクロール位置を確認してから、宣言されたスコープ全体をデスクトップおよび対象のモバイル／デバイスのビューポートで検査します。関連するデフォルト以外の状態、または作成された終了状態を、実際の操作位置から実行し、変更後の結果を表示したままにします。狭い幅でも主要なルートパス全体を維持し、アーティファクトを生成する場合は、実際に保存／ダウンロードされた成果物を検査します。コンソール／ビルド出力を確認します。対象にすでに Playwright または Puppeteer がある場合、scripts/browser-capture.mjsはブラウザーをインストールせずに、比較可能なローカルキャプチャと証拠マニフェストを保存します。静的証拠、実行時証拠、視覚的証拠は分けて扱います。

大規模な作業では、リサーチアトラス、視覚的な反復、20ラウンドのデザイン制作ループに従います。セッションを開始し、実際の参考資料とスクリーンショットを調査し、セクションごとの最良案と統合内容を記録し、重大な欠陥を修正して、新しいキャプチャを比較します。ラウンド15～20ではローカルキャプチャが必須です。ラウンド16～19では、修正前後のキャプチャ、比較アーティファクト、最大の差異に対する修正記録が必須です。ラウンド19では、利用可能な場合、新鮮な視点による構造化された批評が必須です。大規模なセッションではラウンドを省略できず、ラウンド20ではCURRENT WINSが必須です。critiqueを使って、重大度、領域、影響、証拠、修正、確信度、判定を記録します。完全なジャーナルはラウンド19の--critiqueとして渡すことができ、ラウンドの判定と照合されます。design-loop startは連携したアトラスを作成します。品質、スコープ、アクセシビリティ、実行時、レンダリング証明の各ゲートを通過してから、両方を終了します。視覚的な主張を作り直す必要がある場合は、画像生成を行うimage-proposalジャーナルを使います。ベースラインと提案を記録し、それを採用または却下し、ソースの翻訳を記録してから、実際の修正後キャプチャが存在する場合にのみ終了します。生成画像は実装の完全性を証明するものではありません。実行中の開発対象がある場合は、live startとlive closeを使って、ベースライン、バリアント、採用、ソース差分、修正後キャプチャの証明をジャーナルに記録し、ゲートで検証します。

このスキル自体については、次を実行します。

npm test

参考資料との連携機能は、名前だけのドキュメントではなく実行可能です。デザインインテリジェンス（brief）、訪問者／アクションのルーティング（surface-mode、design-operation）、証拠に基づくソースのリンティング（visual-lint）、調査証拠とセクションの統合（research-atlas）、20ラウンドの制作契約と永続化された品質ゲート（design-loop）、視覚的な方向性（direction）、リポジトリグラフ（graph）、役割別の参考資料の構成（reference）、一文の実装契約（reference-build）、簡潔な応答パイプライン（audit）、厳選されたリソース（resource）、実行中のバリアントのジャーナル記録と証明ゲート（live）、画像提案からコードまでのジャーナル記録（image-proposal）、構造化された独立した視覚的批評（critique）、内部モーションブリッジ（motion）を備えています。

出力契約

デフォルトでは、短く、判断を重視した応答にします。

Decision: <what changed and why>
Changed: <files or surface>
Proof: <commands, screenshots, states, or runtime evidence>
Open: <only real blockers or unverified claims>

長めの概要は、ユーザーが求めた場合、方針のリスクが高い場合、またはアーティファクトを別のエージェントが再利用する場合にのみ使います。簡潔モード／詳細モードについてはreferences/response-contract.mdを読んでください。

厳守すべき不変条件と推奨バイアス

厳守すべき不変条件を、スタイルのために犠牲にしてはいけません。意味的なアクセシビリティ、関連するタスク／状態または作成された体験の完全性、レスポンシブな使いやすさ、アセットの正確性と権利、モーションのクリーンアップ／視差効果の低減／フォールバック、ランタイムの整合性、そして正直なレンダリング結果の証明を保ってください。

以下は、あらゆるスタイルに一律に適用する禁止事項ではなく、推奨バイアスの確認項目です。過度に大きな文字、均一なカードが並ぶレイアウト、中央揃えのヒーローテンプレート、ライブラリのデフォルトスキン、エフェクトの重ねすぎ、ありきたりな高級感のある配色、弱いメディア、装飾的なモーションが該当します。プロジェクト独自の DESIGN.md、調査済みの参考資料、承認済みのコンセプト、明示的なユーザーの指示、または根拠に裏付けられたモデルの提案によって、意図的にこれらを覆してもかまいません。方針の契約には、根拠の出所、理由、証拠、リスク、維持する不変条件、レンダリング結果の証明を記録してください。

フィードバックで結果が醜い、凡庸、ありきたり、静的、または高コストだと言われた場合、前の試みを擁護してはいけません。Inspect を再実行し、弱い判断を置き換え、目に見える結果をもう一度検証してください。

作成した方針を適用するには、direction、brief、reference-build、または audit で --direction-file <path> を使用してください。JSON は部分的な契約です。指定された構成、形状、処理、ビルドの各フィールドが優先され、省略されたフィールドはローカルの根拠で補われます。詳しくは references/creative-direction.md を参照してください。