ランディングページのアートディレクション

Design Director

自分自身に任せられたモデルは、見たすべてのページの平均と、想像上の顧客のためのデザインを作成します。このスキルは、実際のビジネスとその実際の顧客に関するリサーチから始まり、それをストーリーラインに変え、構築前にその計画を批判し、最も重要な瞬間にデザイナーのセンスを注入し、ブラウザと別の視点で結果を確認します。ここでの優れたデザインは、次の3つを同時に意味します。ビジネスに役立ち、顧客に応え、見た目が適切であること。

<skill> は、このスキルのフォルダを意味します。プロジェクトルートからスクリプトを実行してください。作業ファイルは .design/ に配置されます。スクリプトには Node 18+ と Chromium を使用した Playwright が必要です（必要に応じて CHROME_PATH を設定）。

原則

1. 常にリサーチが最優先。 毎回の実行は、依頼がなくてもビジネス、競合他社、顧客をリサーチし（research/method.md）、すべての決定は調査結果に基づいて行われます。リサーチレポートは、成果物と共にユーザーに返されます。
2. 見た目よりもビジネスと顧客を優先。 戦略は、利益を生むアクションと顧客の質問を特定し、ストーリーラインはそれらに順番に答えます（strategy/method.md）。見た目はストーリーに奉仕し、その逆ではありません。
3. 構築する前に、必ず批判する。 別のエージェントが、4つの視点から計画を攻撃します（roast/method.md）。すべての指摘は受け入れられ対処されるか、理由とともに却下されます。批判は方向性を変える可能性があります。それが批判の役割です。
4. 構築する前に決定する。 すべての決定は、コードの前に .design/ に書き込まれます。コードは仕様に書かれていることのみを使用します。
5. デザイナーが選択します。あなたは提案します。 短いゲート：ブリーフ、戦略、方向性、最終結果。
6. チームのセンスはデータです。 team/taste.md とブランドファイルは、あなた自身の好みよりも優先されます。ブランド要素は brand/method.md から取得します（brand 実行からのキット、または方向性ステップでの簡易キット）。
7. 見た目をコードだけで判断せず、一人で判断もしない。 スクリーンショットで判断します。標準以上の努力では、別の専門エージェントの審査員が判断し（rubric/jury.md）、デザイナーの投票と審査員の投票が組み合わされます。同点の場合は人間が決定し、アクセシビリティに関する拒否権は覆せません。コードも判断されますが、コード独自の条件と責任者によって判断されます。エンジニアリングレビュー（rubric/council.md）です。
8. 既存のものを尊重する。 既存のプロジェクトでは、ページのオーバーライドではなく、トークンとコンポーネントを変更します。
9. 証拠を捏造しない。 偽の推薦の声、クライアントのロゴ、統計、賞、報道は作成しないでください。
10. ステップに必要なものだけを読む。 各ステップは、そのファイルを指定します。スキル全体をロードしないでください。
11. 5つの責任者がすべてのジョブを承認する。 プロダクト（ビジョン、成果、指標、スコープ）、ビジネス（市場洞察）、デザイン（構成、システム、アクセシビリティ）、クリエイティブ（アイデア、ブランド、シグネチャー、モーション）、エンジニアリング（コード）の各責任者がそれぞれの部分を担当します（rubric/council.md）。4つは、既に実行されている批判と審査員の中で演じられます。エンジニアリングはゲート後にコードをレビューします。仕様は、## Council の承認で終わります。

すべての実行を開始する

1. モード。 リクエストとプロジェクトから1つを選択します。不明な場合は、自分の解釈を1行で述べて続行します。

   モード	いつ	ファイル
   create	新しいページ	modes/create.md
   site	複数ページ、または段階的なフロー（サインアップ、チェックアウト、オンボーディング）	modes/site.md
   section	既存のデザイン内の1つのセクションまたはコンポーネント	modes/section.md
   review	「レビュー」「監査」「なぜ見た目がおかしいのか」（コード変更なし）	modes/improve.md
   restyle	見た目を改善し、レイアウトを維持	modes/improve.md
   redesign	構造を再構築し、コンテンツ、スタック、動作を維持	modes/improve.md
   brand	ブランドキット（要素、色、タイプ、形状、モーション、プレースホルダーワードマーク）を、ページの有無にかかわらず、事前にボードに表示	modes/brand.md

   画面が（ダッシュボード、管理、設定、受信箱、エディターなど）読み取り専用ではなく、操作対象である場合、modes/app-screen.md を追加します。合意されたデザインシステムやコンポーネントライブラリがない管理パネル、ダッシュボード、バックオフィスは、ユーザーが別のものを承認するまで shadcn/ui（React + Tailwind）で構築します。その理由をユーザーに伝えます（rules/stack.md）。方向性ステップでは、ユーザーが2～3のスタイルバリエーション（サイドバー、モーダルなど）を見たいかどうかを尋ね、パネルが汎用的に見えないようにします。ユーザーは adminoptions.mjs のページから選択するか、AIを信頼します（admin/method.md）。レコードをリストする画面（3行以上）は、admin/table.md のデータテーブルルールに従います。数値は右揃え、選択時に一括操作バー、ワイドテーブルでは固定された識別子とアクションなど。それぞれに理由と、適用しない場合の条件があります。

2. 努力レベル。 quick はセクションや小さな修正用、standard はページ用（デフォルト）、thorough はピッチ用、フラッグシップページ用、またはサイト全体用（主要セクションごとにベスト・オブ・3）。実行あたりのサブエージェント予算（実際の数を測定してログに記録し、成果報告書に記載）：

   努力レベル	サブエージェント	予算
   quick	1人の批評家（メインセッションが演じる5つの責任者。独立していない）	約70k
   standard	理由ロースト係 + 2人の合同審査員 + 後半ラウンドごとに1人の検証者 + 1人のエンジニアリングレビューアー	約320～430k
   thorough	4人の責任者ロースト係 + 理由ロースト係 + ヒーロー審査員（2人） + 完全な外観パネル（5～6人、責任者ごとにグループ化） + 1人のエンジニアリングレビューアー + 後半ラウンドごとに2人	約850k～1.15M

   測定済みの部分：理由ロースト係 93k（WO run-2ページ、67要素、9コール）。審査員 59～94k ずつ。未測定（推定）： エンジニアリングレビューアー 約70～110k（固定オーバーヘッド53k + 1ページのソースファイル）。thorough での追加の責任者ロースト係 約60～80k（オーバーヘッド + ブリーフ、リサーチ、戦略）。次の実際の実行で測定し、これらの数値を置き換えてください。メインセッションは別途かかります。Run 2（standard、これらの制限前）は、サブエージェントだけで約630k費やしました。そのほとんどは、2つの5人審査員パネルでした。

3. ゲートスタイル。 guided（デフォルト）：3つの方向性カード。quick：1行の理由と「続行しますか？」を含む1つの推奨事項。「どちらでもいい」/「お任せします」と言ったユーザー向け。autopilot：人間の介入なし（バッチ実行、評価）。すべての選択は理由とともに記録されます。designers/<name>.md に保存された好みを確認します。

4. ガイドし、ユーザーに早期に選択させる。 リサーチの前に、ユーザーが1つの短いメッセージ（rules/brief-interview.md）で欲しいものを表現できるように支援します。誰が、何のために、その背後にあるプロダクト（ビジョン、成果、1つの指標、スコープ内外：プロダクト責任者の質問、rubric/council.md）、好きなサイト1～3つと嫌いなサイト1つ（dials.mjs によってダイヤルに変換）、3つの感覚的な言葉、存在するもの（写真、プロダクトUI、ブランドアセット：rules/brief-interview.md → マテリアル）、除外するもの。写真がない場合は、どの代用画像を希望するかを尋ね、5つの選択肢を提供します（ユーザーが選ぶかあなたが検索するストック写真、無料のAI生成ドラフト、描画によるデザインされたプレースホルダー、または写真なし：rules/illustration.md）。使用するパスと、その結果がどのように見えるかをすぐに伝えます。方向性ゲートでは、ユーザーは各方向性のファーストスクリーンスケッチから選択します。その選択が構成を決定するため、standard の努力ではヒーロー・ベスト・オブ・3は必要ありません。全ページバリエーション（2～3ページ全体、--variants）は、thorough の努力またはユーザーが要求した場合に使用します。ユーザーは compare.mjs で選択し（--choose user）、審査員は autopilot でのみ選択します。

5. node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury] を実行します。

6. team/taste.md、ブランドファイル（存在する場合 brands/<client>.md またはプロジェクト内の .design/brand.md）、ユーザーが名前付きの場合は designers/<name>.md、および rules/precedence.md を読みます。

7. モードファイルを開き、ステップごとに従います。

すべてのステップのルール

• ステップの前に progress.mjs check <step> を実行します。ステップの後に progress.mjs done <step> を実行します。スクリプトが拒否した場合は、メッセージの指示に従います。.design/progress.json を手動で編集しないでください。
• ゲート。 ゲートを表示し（以下の形式）、ユーザーの応答を待ちます。明示的な返信があった場合のみ progress.mjs approve <gate> --note "<the user's words>" を実行します。--gates autopilot で実行が開始されていない限り、ユーザーに代わって承認しないでください。
• サンプルコンテンツは、ブリーフが残したギャップを埋めることができます（料理名、客室料金）。.design/copy.md で [SAMPLE] とマークし、最終レポートにリストします。証拠（引用、ロゴ、顧客に関する数字）は決してサンプリングしません。そのセクションを省略するか、実際のものを依頼します。
• 参考文献は rules/copyright.md に従います。少なくとも3つのソース、それぞれ1つの役割、アセットのコピーはありません。
• 2つのルールが競合する場合、rules/precedence.md が決定します。競合をレポートに記載します。
• 長いセッションでは、各セクションを構築する前に .design/spec.md を再読み込みします。
• 実行しなかったチェックを報告しないでください。ブラウザまたはサブエージェントが利用できない場合は、その旨を伝えます。
• すべての主要な決定を説明します。 UXの理由、トレードオフ（間違っている場合）、可能な場合はソースを、中立的な言葉で説明します（「ほとんどのガイダンスでは…を推奨しています。なぜなら…。例外は…」）。これにより、ユーザーは別のAIのデザインと比較して自分のデザインを守ることができます（rules/rationale.md）。

ゲートの形式

ブリーフゲート（approve brief）。最大10行のカード：それが何か、誰のためのものか、その状況、1つのアクション、プロダクト部分（ビジョン、成果、1つの指標、スコープ内外：rubric/council.md）、存在する実際のコンテンツとアセット（ブリーフの ## マテリアル セクション：写真、プロダクトUI、ブランドアセット、不足しているものの計画）、ブランドの制約、避けるべきこと、不明な点に関する1行の解釈。作業を妨げる事実についてのみ、最大5つの質問をします。

戦略ゲート（批判後、approve strategy）。ここでユーザーは初めてリサーチを見ます。次の順序で表示します。

1. リサーチの要約：デザインを変える3～5つの調査結果、カテゴリーの決まり文句、顧客の言葉でのトップの質問、読まれたソースの数。
2. 戦略：利益を生むアクション、顧客とその認識レベル、メッセージハウス（約束、3つの柱、異論）、ビートのリストとしてのストーリーライン。
3. 批判によって変更された点、および却下した深刻度の高いポイントとその理由。
4. クライアントへの未解決の質問と、不足している証拠。

方向性ゲート（approve direction）。

• ガイド付き： draw.mjs からの3つのカード。それぞれ、アイデアの文、構成（1行）、タイプとカラーのアプローチ、そしてこの主題に適合する理由。あなたの推奨とその理由を述べてください。ユーザーは1つを選ぶか、混ぜることもできます（「タイプはAから、レイアウトはBから」）。混ぜた内容を仕様に書き込みます。 カードの下に、ビジュアルダイヤル（rules/visual-dials.md）。それぞれをあなたの推奨に設定し、1つの理由とクライアントから必要なもの：カラーエネルギー、タイプ表現、画像、モーション、価格。チームの参照をプリセットとして指定します（「Swehlのような色」）。曖昧な言葉をダイヤル値に変換し、変換結果を表示します。回答は .design/targets.json に保存されます。
• Quick： 推奨カードのみ。「他の2つは .design/directions/ にあります。必要ならどうぞ」。"ok"、"lanjut" などで続行します。

ユーザーが3回連続で「どちらでもいい」と答えたり、推奨を受け入れたりした場合は、Quick ゲートに切り替えることを提案し、同意した場合は designers/<name>.md に書き込みます。

最終ゲート（approve final）。モードファイルからのパッケージ。.design/deliver.md に書き込みます。構築されたもの、デスクトップとスマートフォンのスクリーンショット、サンプルコンテンツ（[SAMPLE] コピー、data-sample とマークされたサンプルUI、すべての代用画像：クレジット付きの見つけた写真、AI生成ドラフト、デザインされたプレースホルダーと図面、ショットリスト付き）、未解決の問題（エンジニアリングレビューの判定、測定された予算、未解決の調査結果）、「Alasan desain」：少なくとも3つの主要な決定。それぞれにUXの理由、トレードオフ、ソース、およびそれが役立つ場合の責任者（rules/rationale.md、rubric/council.md）、「Supaya lebih bagus」：ユーザーが結果を向上させるために実行または決定できる具体的な事項（最大5つ）（提供する写真とショットリスト、収集する実際の証拠、回す価値のあるダイヤル、より高い努力レベル、モーション仕様が動かすメッセージを見つけられなかった場合のシグネチャーモーション）。それぞれに何が変わるかを記載します。

ユーザーが考えを変えた場合

すべてのステップは、前のステップに依存します。 ブリーフ → リサーチ → 戦略 → 批判 → 方向性 → スケルトン → 仕様 → コピー → 構築 → 理由 → ゲート → 外観 → 納品。

1. 変更された最も早い決定を見つけます（「方向性Bに戻る」→ direction、「今のオーディエンスは学生」→ brief、「本当の問題は恐怖ではなく価格」→ strategy）。
2. 何かをする前に、影響を1行で述べます。何をやり直し、何をそのままにするか。
3. progress.mjs back <step> --reason "<what changed>" を実行し、そのステップからやり直します。
4. 以前の作業は保持します。処理済みの方向性は .design/directions/ に、古いスクリーンショットは .design/snapshots/ に残します。古い決定のために構築されたものの上に、新しい決定をパッチしないでください。

小さな変更（1つの色、1つのサイズ、1行のコピー）は、戻る必要はありません。トークンまたはコピーを変更し、progress.mjs log でログに記録し、再度検査します。

フィードバックが曖昧な場合

「あまりワクワクしない」「何かがおかしい」「十分にプレミアムではない」：推測してページを再描画しないでください。

1. 2～3の具体的な仮説を書きます（「ヒーローに単一の焦点がない」「タイプサイズが近すぎる」「写真が一般的すぎる」）。
2. 影響を受ける領域のみの小さなバリエーションを作成し（ヒーローのクロップ A/B/C）、並べて表示します。
3. ユーザーが選択します。選択した内容を、ページの残りの部分のルールとして仕様に書き込みます。

学習

最後に、1文のフィードバックを求めます。それを、実行中にユーザーが修正した内容とともに、team/taste.md（または個人の好みの場合は designers/<name>.md）への提案された変更に変換し、ソース（プロジェクト、日付、誰）を含む差分として表示します。

[翻訳のために省略]

（翻訳注：原文が途中で切れています。そのまま残します。）