art-direction について
art-directionは、生成画像をプロジェクト固有のビジュアルに合わせるスキルです。デザイナーやコーディングエージェントがスタイルアンカーを作り、要件に沿って画像を確認し、素材群の一貫性を保つ手順を示します。
主な機能
- 01プロジェクトファイルからスタイルアンカーを作成
- 02配色、素材、ムードを記録
- 03プロジェクトの根拠に基づく生成ブリーフ
- 04要件に照らして生成画像を確認
- 05確認結果に基づいて編集または再生成
- 06画像セットで共通アンカーを再利用
活用シーン
- 01プロジェクトの画像表現を定める
- 02既存インターフェースに合う素材を作成
- 03生成画像の配色や文字の問題を確認
- 04複数のプロジェクト画像の見た目を統一
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/art-directionを入力して読み込まれたか確認します。
詳細
アートディレクション
何でも描画できるモデルでも、この製品がどのような見た目なのか伝えなければ、ありきたりなものを描きます。基準となるのはブリーフです。プロンプトは、ブリーフをモデルに伝える手段にすぎません。
ユーザーの生のリクエストから生成してはいけません。まず基準を固め、次に生成し、その後で画像を確認します。
1. 基準を探すか、作成する
design/style-anchor.md を探します。存在する場合はそれを使い、手順 2 に進みます。
存在しない場合は、プロジェクトにすでにあるものから導き出します。次のうち存在するものを確認します：tailwind.config.*、app/globals.css または同等のスタイルシート、ルートレイアウトのフォントインポート、ランディングページのコピー、public/ 内の既存画像。
根拠に基づいてすべての項目を埋めます。リポジトリから判断できないことだけを、最大 3 つまで質問します。それぞれに推奨回答も添え、ユーザーが「はい」と答えるだけで済むようにします：
❓ <question>
➡️ my suggestion: <recommended answer, one line on why>
次に design/style-anchor.md を作成します：
# Style anchor
Medium: <photography | 3D render | flat vector | collage | risograph | line illustration — pick one, never mix>
Palette: <3–5 actual hex values lifted from the app, named: background, ink, accent>
Light: <direction, hardness, time of day>
Materials: <surfaces and textures that recur: matte paper, brushed metal, soft fabric>
Mood: <three adjectives, earned from the product, not from a mood board>
Never: <the defaults to refuse: floating particles, glossy pedestals, lens flare,
gradient mesh backgrounds, neon-on-black, handshake stock photos,
anything the app's own UI does not do>
プロジェクト全体で使う表現媒体は 1 種類にします。ヒーロー画像の写真と、フラットなベクター形式の空状態イラストを並べると、別々の製品のように見えます。
2. スロットを選ぶ
各アセットは、最終サイズが決まったスロットです。記載されたサイズで生成してから、最終サイズに合わせてリサイズまたはトリミングします。画像モデルが要求するため、生成サイズは 16px の倍数にしています。また、およそ 0.65 メガピクセル未満の画像は拒否されます。
| スロット | 最終サイズ | 生成サイズ |
|---|---|---|
| og:image / ソーシャルカード | 1200×630 | 1536×800 |
| ランディングページのヒーロー画像 | 16:9 | 1920×1088 |
| 機能またはカード用アート（正方形） | 1:1 | 1024×1024 |
| カード用アート（縦長） | 3:4 | 768×1024 |
| 空状態 / イラスト | 4:3 | 1024×768 |
| アバター / アイコンの元画像 | 512×512 | 1024×1024 |
| ファビコンの元画像 | 512×512 | 1024×1024 |
次のものは生成しないでください。生成すると、プロジェクトが安っぽく見え始めます：
- ロゴとワードマーク。 代わりにテキストとして組みます。モデルは小さなサイズでは文字の形を崩しますし、再現できないものは商標登録できません。
- UI のスクリーンショットとモックアップ。 実際のアプリをスクリーンショットにします。
- グラフとデータ。 実際のデータと実際のグラフを使います。
- プロジェクトに使用権がない、認識可能な人物、ブランド、製品。
3. プロンプトを組み立てる
毎回、次の順番で組み立てます：
- 基準全文をそのまま記載します。
- 被写体 — フレームに実際に何が写るかを具体的に指定します。被写体は 1 つにし、3 つも入れないでください。
- 構図 — トリミングと、余白をどこに置くかを指定します。場所を明示します：「見出しのコピー用に、左 3 分の 1 は空けておく」。この手順は省略されがちで、生成したヒーロー画像の中央に文字が埋め込まれてしまう原因です。
- 光と素材。基準に従います。
Neverリストを、明示的な禁止事項として記載します。
完成版は public/images/<slot>.<ext> に保存します。下書きや中間ファイルは tmp/ に置き、作業後に削除します。
画像内にテキストを入れる場合は、プロンプトに正確な文言を引用符で囲んで記載し、数語にとどめます。長い段落は、どの解像度でもスペルミスが含まれて返ってきます。
4. 画像を確認する
保存しただけでは、アセットは完成していません。作成した画像を開き、ブリーフと比較します。
問題点を修正方法とともに優先順位付けし、次のいずれかを選びます：
- 合格 — そのまま公開します。
- 狙いを絞った修正 — 再生成ではなく既存の画像を編集し、正しくできている部分を維持します。
- 再生成 — 構図自体が間違っている場合に限ります。
次の順で確認します：余白は配置予定のコピーに十分か、見えるテキストにスペルミスはないか、パレットはアプリの配色と合っているか、Never リストにあるものが含まれていないか、ほかのアセットの隣に並べても外部から持ち込んだように見えないか。
再生成に 2 回失敗したら、そこで止めます。問題はプロンプトではなくブリーフにあります。確認した内容を添えて、ユーザーに差し戻します。
5. 一連のアセットの統一感を保つ
以降の画像もすべて同じ基準ファイルを使います。新しいアセットを既存のものに合わせる必要がある場合は、言葉で説明して期待するのではなく、既存画像を参照画像として渡して編集します。
アプリのビジュアルディレクションが変わったら、まず design/style-anchor.md を更新し、影響を受けるスロットをまとめて再生成します。古い基準のアセットと新しい基準のアセットを混在させないでください。
生成
Codex では、画像生成が組み込まれています。GPT Image を利用する $imagegen なら、API キーもセットアップも必要ありません。生成後の画像も確認できるため、ステップ 4 を実際に実行できます。
ほかのエージェントでは、画像を生成できると約束する前に、ユーザーがどの方法を利用しているか尋ねてください。このスキルの残りの部分は、そのまま適用されます。
ブリーフをプロンプトより優先する構成と、合格／対象を絞った修正／再生成の判断フローは、AgriciDaniel/banana-claude（MIT License）を参考にしています。スタイルアンカーとスロットごとのレンダリングマニフェストは、nexu-io/open-design（Apache-2.0 License）の画像テンプレートを参考にしています。