extract

抽出

公開ウェブサイトから、根拠に基づいた DESIGN.md を作成します。観察できるデザインパターンを抽出してください。実行可能なコードとしてサイトを複製したり、公式のブランドガイドラインだと主張したりしないでください。

コマンドの動作

ユーザーが /extract <url> と入力した場合、このワークフローを直ちに実行するリクエストとして扱います。

ユーザーが /extract のみを入力した場合は、公開 HTTPS URL を尋ね、その URL が提供されるまで抽出を開始しないでください。

デフォルトの出力先：

• エビデンス一式：.blueprint-extractor/<slug>/
• 最終ドキュメント：別のパスを指定されない限り、ユーザーの現在のプロジェクト内の DESIGN.md

ワークフロー

1. 対象 URL を検証します。
2. ユーザーのプロジェクト内に .blueprint-extractor/<slug>/ というエビデンスフォルダーを作成します。
3. 公開ページのデータからエビデンスを収集します。
   • HTML のタイトルとメタデータ
   • リンクされた CSS とインライン CSS
   • 代表的な要素の計算済みスタイル
   • ブラウザツールを利用できる場合は、デスクトップのスクリーンショット（1440x900）
   • ブラウザツールを利用できる場合は、モバイルのスクリーンショット（390x844）
4. 取得した CSS、計算済みスタイル、または記録したスクリーンショットからのみ、具体的なトークンを抽出します。
5. 最終的な文章を書く前に、blueprint.json と sources.json を作成します。
6. references/DESIGN_TEMPLATE.md に記載された正確な 9 セクションの規約に従って、DESIGN.md をまとめます。
7. 最終確定の前に、セルフレビューを行います。
   • 観察したコンポーネントのレシピを使って、実装に役立つ内容にします。
   • スクリーンショットで裏付けられる場合は、テーマの定性的な説明を改善します。
   • 抽出したエビデンス、スクリーンショットから推定した挙動、実装ガイダンスを区別します。
   • 目視できない、または抽出した CSS に存在しない、広範なプロダクトに関する主張を削除します。
   • 対象プロジェクトのドメイン、情報アーキテクチャ、主要なワークフローを維持し、視覚表現のみを適用します。
   • 再利用する前に、元サイトのドメイン固有コンポーネントを抽象化します（たとえば、「プレイリスト」を「コレクションリスト」に、「アルバムアート」を「ビジュアルサムネイル」に置き換えます）。
   • 定性的または推定であると明記されていない限り、裏付けのない例を DESIGN.md に含めないでください。
8. 最終的な Markdown がテンプレートとエビデンスに適合しているか検証します。
9. 最終回答で出力パスと、確度に関する警告があれば報告します。

URL の安全性

URL が安全でない、または対象範囲外の場合は、簡潔に説明してリクエストを拒否します。

• https:// ではない
• localhost、ループバック、プライベート IP、リンクローカル、またはプライベートホスト名
• 認証が必要、または有料コンテンツ
• HTML 以外のレスポンス
• 到達不能、空、またはリダイレクト回数が多すぎる
• ログインの回避、非公開ダッシュボードのスクレイピング、Figma の抽出、または実行可能なコードとしての複製を求めるリクエスト

フォーム、ログインフロー、チェックアウトフロー、破壊的な操作、またはユーザー固有のページには進まないでください。

抽出

scripts/extract-blueprint.mjs が存在し、依存関係を利用できる場合は、最初に実行し、その成果物を信頼できる情報源として使用します。利用できない場合は、利用可能なブラウザ、HTTP、ファイルシステムのツールを使用して、同等のエビデンスを手動で収集します。

視覚的な推測よりも、再現性の高いエビデンスを優先します。

• 色は CSS、計算済みスタイル、SVG 属性、またはサンプリングしたスクリーンショットから取得します。
• フォントファミリーは CSS、計算済みスタイル、または @font-face から取得します。
• ブレークポイントはメディアクエリから取得するか、スクリーンショットからの推定であることを明記します。
• 間隔、角丸、シャドウ、境界線、モーションは CSS または計算済みスタイルを根拠として示します。
• スクリーンショットしかない場合は、観察内容を定性的な記述にとどめ、数値トークンを作り出さないでください。

blueprint.json と sources.json を作成または編集する前に、references/EXTRACTION_SCHEMA.md を読んでください。 抽出が不完全、または妨げられている場合は、references/FAILURE_MODES.md を読んでください。 生成した DESIGN.md を良い例、またはリリース品質の出力として扱う前に、references/QUALITY_CHECKLIST.md を読んでください。

合成ルール

ユーザーが指定した言語を使用してください。言語が指定されていない場合は、DESIGN.md を英語で記述してください。

最終的な DESIGN.md には、次の H2 セクションをこの順序で、正確に含めてください。

1. 1. Visual Theme & Atmosphere
2. 2. Color Palette & Roles
3. 3. Typography Rules
4. 4. Component Stylings
5. 5. Layout Principles
6. 6. Depth & Elevation
7. 7. Do's and Don'ts
8. 8. Responsive Behavior
9. 9. Agent Prompt Guide

DESIGN.md に Sources、Confidence、Appendix セクションを追加しないでください。確信度に関する警告は、最終的なアシスタントの回答またはエビデンスバンドルに記載してください。

DESIGN.md の具体的なトークンはすべて、blueprint.json を根拠として追跡できる必要があります。不確かな所見は、正確な値ではなく定性的な観察として示してください。

最終ドキュメントを、無味乾燥なトークン一覧にしないでください。エビデンスを、再利用可能なデザインガイダンスに変換してください。

• サイトのアーキタイプは、キャプチャしたページから確認できる場合に限り、「ダッシュボードシェル」「エディトリアルランディングページ」「コマースカタログ」「メディアプレーヤー」「ドキュメントサイト」などと記載してください。
• 有名ブランドについては慎重に扱ってください。キャプチャしたページ、CSS、または計算済みサンプルで裏付けられていない限り、よく知られた製品のパターン、ブランドにまつわる情報、公式システムであるという主張を持ち込まないでください。
• 対象アプリのドメインモデル、情報構造、ユーザーワークフローを維持してください。参照サイトが示すのはビジュアル言語であり、対象プロジェクトを参照サイトの製品カテゴリに変える許可ではありません。
• 移用可能なデザイン特性と、移用できない参照元ドメインのオブジェクトを区別してください。色、タイポグラフィ、間隔、情報密度、形状、表面のレイヤー構造、操作感は移用します。一方、ユーザーが明示的にその製品構造を求めていない限り、楽曲、プレイリスト、カート、ドキュメントページ、ダッシュボード、決済フローなどのドメインオブジェクトは移用しないでください。
• 参照元のコンポーネントが役立つ場合は、ドメインに依存しないパターンとして表現してください。「プレイリストサイドバー」ではなく「コレクション／ナビゲーションサイドバー」、「トラック行」ではなく「繰り返し表示されるコンテンツ項目」、「アルバムアート」ではなく「ビジュアルサムネイルまたはアクセントブロック」のように記述します。
• 本文では、観察されたトークン、スクリーンショットから推定されたレイアウト動作、実装ガイダンスを区別してください。
• 繰り返し観察されたコンポーネントを、用途、表面、タイポグラフィ、間隔、角丸、境界線／シャドウ、操作を含む簡潔なレシピにまとめてください。
• 個別の装飾値より、ページ全体に汎用できるパターンを優先してください。
• 抽出されたブレークポイントと、実装上の便宜のためのブレークポイントを区別してください。
• 7. Do's and Don'ts では、誤解を防ぐための簡潔な制約を示してください。アクセントカラーの多用、根拠のないコンポーネントの追加、参照元サイトのドメインモデルの持ち込み、対象プロジェクトの製品カテゴリの変更などを含めます。
• 9. Agent Prompt Guide は実用的な内容にしてください。エビデンスで裏付けられる場合は、色の簡易リファレンス、コンポーネントプロンプトの例、反復改善のガイダンスを記載します。
• 対象サイトのクローンを作るようエージェントに指示するのではなく、参照元の影響を取り入れつつ、実装に使えるガイダンスにしてください。

検証

完了前に、次の項目を確認してください。

• 意図した出力パスに DESIGN.md が存在することを確認してください。
• H2 セクション名と順序が references/DESIGN_TEMPLATE.md と一致することを確認してください。
• すべての16進カラーコード、フォントファミリー、ブレークポイント、角丸、シャドウ、間隔の値が blueprint.json に記載されているか、推定値／定性的な値として明示されていることを確認してください。
• 例またはリリース候補を作成する場合は、出力が references/QUALITY_CHECKLIST.md を満たしていることを確認してください。
• 検証に失敗した場合は、提示する前にエビデンスを修正するか、裏付けのない値をより限定的な表現に変更してください。