build-daily-inspiration-sites

日々のインスピレーションサイトを構築する

既存の5項目のインスピレーションパックを、独立したオリジナルのサイトプロジェクト5つに変換します。現在のタスクからオーケストレーションを行い、作成した各タスクが1つの構築、コミット、非公開デプロイを担当するようにします。

このスキルを使用する場面

• 日付付きの *-ui-inspiration-capture 記事と5項目のマニフェストで構成される、完成済みの日次UIインスピレーション収集を、オリジナルのランディングページ5つに変換するようユーザーから依頼された場合に使用します。
• 5項目のUIプロンプトパックを、それぞれが1つの構築、1つのコミット、1つの非公開サイトデプロイを担当する、独立した5つのCodexタスクに変換する場合に使用します。
• 元の項目をコピーするテンプレートではなく、アートディレクションとしてのみ扱い、各項目に実質的に異なる代替ブランド、コピー、画像のアイデンティティが必要な場合に使用します。
• references/thread-brief-contract.md に従い、マニフェストの各項目につき、インラインのローカル全ページ画像を1枚だけ添付した構築ブリーフを1つずつ用意する場合に使用します。
• 構築タスクを振り分ける前に、scripts/validate_capture.mjs を使用してキャプチャフォルダーの manifest.json と content.md を検証する場合に使用します。
• 元のインスピレーション収集のやり直し、既存サイトのビルドへの直接編集、または明確に異なるサイトを5つ以外作成する場合には使用しないでください。キャプチャの作成は、日次UIインスピレーション収集ワークフローに振り分けてください。

境界を守る

• キャプチャは証拠とアートディレクションとして使用し、コピーするテンプレートとしては使用しないでください。
• ユーザーから明示的に依頼されない限り、インスピレーション収集をやり直さないでください。
• マニフェストの各項目につきサイトを1つだけ作成し、各サイトにつきCodexタスクを1つだけ作成してください。
• 1つの構築タスクに複数のサイトをまとめないでください。
• 参考元のブランド、ロゴ、ワードマーク、コピー、人々、企業、お客様の声、数値、日付、プラン、価格、URL、法的文面、インターフェースのスクリーンショット、写真、または独自の商標を再利用しないでください。
• 全ページ画像から確認できる、階層、ペース配分、セクション構成、コントラスト、余白、画像処理といった高レベルのビジュアル表現のみを引き継いでください。
• 各構築タスクには参考画像を1枚だけ添付してください。対象項目の全ページ画像を使用します。代表的な静止画、動画、モーションフレーム、セクションの切り抜きは添付しないでください。
• Codexのアプリ内ブラウザーのみを使用してください。Chromeは決して使用しないでください。

1. キャプチャを特定して検証する

ユーザーから指定された記事パスを使用してください。指定がない場合は、現在のContentワークスペース内で最新の日付付き articles/YYYY-MM-DD-ui-inspiration-capture/ フォルダーを選びます。

次を必須とします。

• itemCount: 5 で、項目がちょうど5つある manifest.json
• content.md
• 各項目に対応する、空でないローカルの fullPageImage が1つ
• ライブサイトの各項目に pageUrl
• 各項目に詳細なビルダープロンプトが1つ

次を実行します。

node <skill-dir>/scripts/validate_capture.mjs <article-dir>/manifest.json

検証に失敗した場合は停止します。全ページ画像が見つからない場合は報告し、別の静止画、動画、フレーム、切り抜き、またはライブページのキャプチャで代用しないでください。

2. オリジナリティマトリクスを作成する

タスクを作成する前に、互いに異なる5つの代替アイデンティティを定義します。各項目について、次を決めてください。

• 新しいブランド名とスラッグ
• 新しいカテゴリに沿ったポジショニングステートメント
• 新しいターゲット層とコンバージョン目標
• 新しいコンテンツ語彙
• 新しい実績、指標、プラン、価格
• コンセプトに適した新しい画像の方向性

新しい名前は、参考元のタイトルと実質的に異なるものにしてください。提案した5つの名前を相互に照合し、意図しない類似がないか確認します。汎用的なAI名を5つ付けたり、色だけを変えたりすることは避けてください。

変換後の内容には一貫性が必要です。新しい統計値は、登場するすべての箇所で一致させてください。価格、お客様の声、所在地、サービス名、製品UI、フッターの詳細は、すべて代替ブランドに合った内容にしてください。

3. 各項目につきビルド概要を1つ作成する

タスクを作成する前に、references/thread-brief-contract.md を読んでください。すべてのプレースホルダーに具体的な値を入力し、NEW_BRAND、TODO、その他の未解決マーカーを含む概要は決して送信しないでください。

各概要には、次の内容を含める必要があります。

• マニフェスト項目の正確なタイトルと作成者
• manifest.json と content.md の絶対パス
• 項目の絶対パス fullPageImage を使用した、インラインのローカル画像添付を厳密に1つ。フェンスで囲まない Markdown の画像構文を使います。![Full-page reference — <REFERENCE_TITLE>](<ABSOLUTE_FULL_PAGE_IMAGE_PATH>)
• 新しいブランド名、カテゴリー、対象者、提供内容、コンバージョン目標
• 独自性に関する明確な境界と、漏れのない置き換え対象のリスト
• sites:sites-building と sites:sites-hosting を使用する要件
• セマンティックな構造を備えた、1ルートの HTML ランディングページ。Sites のスターターを使って app/page.tsx から描画してもかまいません
• レスポンシブ対応、アクセシビリティ、動きの軽減、インタラクションに関するすべての要件
• ビルドの検証、限定的なコミット、非公開デプロイ、最終 URL に関する要件

Markdown 画像は、作成したタスク内で添付ファイルとして表示される必要があります。フルページ画像のパスをプレーンテキストで示したり、ほかの画像や動画を添付したりしないでください。タスク作成画面でローカルの Markdown 画像を表示できない場合は、パスだけを渡す方法に切り替えず、その時点で停止して問題を報告してください。

コーディングを始める前に、添付されたフルページ画像を確認するよう各タスクに指示してください。詳細なプロンプトについては、マニフェストまたは記事の内容を項目ごとの唯一の信頼できる情報源としてください。静的なフルページ画像だけでは、元の動きやインタラクションの挙動、実装手法はわかりません。これらを推測したり、断定したりしないでください。

4. Codex のタスクを5つ個別に作成する

ユーザーが個別のタスクまたはスレッドを明示的に依頼した場合に限り、Codex のスレッドツールを使用してください。

1. 記事の日付に加え、参照タイトルまたは提案するブランド名を使って最近のタスクを検索してください。一致するタスクがすでにある場合は、重複して作成せず、既存のタスクを再利用してください。
2. 新しい独立した Sites プロジェクトには、プロジェクト未割り当ての対象と、一意のディレクトリ名を優先してください。
3. ユーザーが既存のリポジトリ内にソースを置くよう求めている場合は、まずプロジェクトを一覧表示し、各ビルド用に個別のワークツリーを作成してください。
4. 5つのタスクすべてに完全な概要を記載して作成してください。
5. Build <Brand> landing page のように、各タスクにわかりやすいタイトルを付けてください。
6. 5つのタスクがすべてアクティブであることを確認してください。スレッドの待機／ステータスツールを使用し、待機できない場合はタスクリストを確認方法として使用してください。

Content チェックアウトで5つのサイトを同時に編集しないでください。キャプチャファイルは読み取り専用の証拠であり、各ビルドはそれぞれのタスクワークスペース内だけに書き込みます。

5. Sites の引き渡しを完了させる

作成した各タスクには、次の要件を課してください。

• 直ちに Sites を初期化する
• ヒーローのモックアップではなく、1ルートの完全なランディングページを作成する
• セマンティックな構造と、適切なライセンスを持つオリジナルのメディアを使用する
• モデルが生成した SVG イラストを使用しない
• 必須の本番ビルドを実行し、失敗があれば修正する
• 検証済みのサイトソースのみをコミットする
• ビルドの成功後、Sites を通じて非公開で公開する
• 共有アクセスまたは公開アクセスしか利用できない場合は、Sites の承認ルールに従う
• デプロイ URL、ソースの場所、コミット、変更内容の簡潔な概要を返す

これらはバックグラウンドタスクであるため、実際の問題の解決に必要な場合を除き、インタラクティブなブラウザプレビューは省略してください。公開作業と通常の Sites の引き渡しは引き続き行ってください。

6. 起動状況を報告する

参照元と置き換え先ブランド、および現在のタスク状況の対応関係を簡潔に示してください。アプリで必要な場合は、新規タスクごとに作成タスクのディレクティブを1つ出力してください。

5つのタスクがそれぞれ次の成果物を作成することを明確に伝えてください。

• オリジナルのランディングページを1つ
• 分離されたソースワークスペースを1つ
• 検証済みコミットを1つ
• 非公開の Sites デプロイを1つ

タスクからビルドとデプロイの成功が報告されるまで、サイトが完成したと主張しないでください。

完了チェック

• マニフェスト項目がちょうど5件検証されました。
• 各項目について、空でない全ページ画像がちょうど1枚検証されました。
• 置き換え後の固有のアイデンティティがちょうど5種類定義されました。
• 一意のタスクがちょうど5件作成、または意図的に再利用されました。
• 各タスクには、レンダリング済みの全ページ画像が添付ファイルとしてちょうど1枚含まれ、画像のパスだけを渡す方法は使用されていません。
• すべてのブリーフで、ソースのアイデンティティ、言語、数字、画像がすべて置き換えられています。
• すべてのタスクで、Sites のビルド、検証、コミット、プライベートデプロイが必須となっています。
• ユーザーは作成された各タスクを個別に開くことができます。

参照

• 上流のソース：MengTo/Skills — build-daily-inspiration-sites
• references/thread-brief-contract.md — ステップ3で使用するビルドブリーフのテンプレート
• scripts/validate_capture.mjs — ステップ1で実行するキャプチャ検証ツール
• agents/openai.yaml — 同梱のエージェント設定