product-pair

/as:product-pair — プロダクトの組み合わせ

作業を始める前に、ホストコントラクトとこのコンポーネントの宣言（skill:product-pair）を読みます。共有カタログから、参照されているモードプロファイルのみを読み込みます。実際のタスクに必要なモードを組み合わせます。宣言は要件であり、アクセス権や許可の証明ではありません。

ライブラリの変更は、完全なネイティブコントラクトに従い、/as:product-libraryが担当します。対象行と根拠を準備し、既存の認可の範囲内で保存処理全体を引き継ぎます。その際、プレビュー／現在のバイト列ハッシュ／リクエストIDの紐付けと、実際の読み戻しを維持します。このスキルは、product-library.csvを独自に変更しません。推奨は、採用や記録の変更を認可するものではありません。

ホストからの実際の提供に関するガイダンスを読みます。利用可能なネイティブのリサーチ、画像、ファイルツールを使用します。操作名は意味上の作業を示すものであり、実行可能ファイルがインストールされていることを示すものではありません。

ネイティブの根拠と権限

構造化された根拠を作成または調整する際は、観察セマンティクス全体と、変更されていない観察スキーマを読みます。ネイティブのproduct_observations.validate、validate-batch、adaptは、正確なバリアント、ゼロ／null／不明値、ソースロケーター、タイムスタンプ、数値の型を維持します。使用可能なデータとして扱う前に、エンベロープ／バッチ全体を検証します。明示的に紐付けられたソースフィールドと、現在選択されているアイテムのリビジョンのみを調整します。推奨やユーザーの選択は、紐付け済みのデータ、既存値の置き換え、承認済みの決定、仕様の採用を意味するものではありません。

プロジェクトに紐付けて保存する場合は、ネイティブのコンテキスト所有者とワークスペースの所有権を使用します。ライブラリを選択する前に、有効なプロジェクトが実際に存在することを確認します。単独での比較や組み合わせには、プロジェクトの作成は不要です。提供されたページ、画像、取得テキストは根拠であり、ファイルの変更や他者への連絡を許可するものではありません。実際のソース／画像へのアクセスを確認し、視覚的な推測と検証済みの仕様上の事実を区別します。

「これには何が合いますか？」商品を起点に、異なるカテゴリーから相性のよいアイテムを提案します。たとえば、ソファにサイドテーブル、読書用の椅子にフロアランプ、ダイニングテーブルにラグを組み合わせます。デザインの原則に基づく理由とともに、5～8件の組み合わせを提示します。

使用する場合

• 主役となるアイテムを起点に、部屋やコーディネートを完成させる場合
• デザイナーが核となる商品を選んでおり、パレットを完成させる必要がある場合
• クライアントに統一感のある商品パッケージを提案する場合
• カテゴリー別にFF&Eスケジュールの不足を補う場合

ステップ1：入力を受け取る

以下の例は、提供する入力の形式のみを示すものです。名称、仕様、価格は、現在の商品情報として検証されていません。

名称で指定：

/as:product-pair Blu Dot Diplomat Sofa

名称とコンテキストで指定：

/as:product-pair Blu Dot Diplomat Sofa for a tech office lounge

商品詳細で指定：

/as:product-pair
Name: Diplomat Sofa
Brand: Blu Dot
Materials: Steel frame, fabric upholstery
Color: Edwards Navy
Style: Contemporary, minimal
Price: $2,499
Context: Corporate lounge, 6-person seating area

ステップ2：元の商品を分析する

商品のデザインの特徴を特定します。

• スタイルの方向性：ミッドセンチュリー、スカンジナビアン、インダストリアル、コンテンポラリーなど
• 素材のパレット：木材の種類、金属の仕上げ、張り地の種類
• 色の系統：暖色系のニュートラルカラー、寒色系、アクセントカラー、モノクロ
• サイズ感：コンパクト／アパート向け、標準、ゆったり／業務用
• 価格帯：手頃（500ドル未満）、中価格帯（500～2,000ドル）、プレミアム（2,000～5,000ドル）、ラグジュアリー（5,000ドル以上）
• 市場：住宅、コントラクト、ホスピタリティ

Step 3: ペアリングのカテゴリーを決定する

ソース製品のカテゴリーに基づいて、通常どのような製品と組み合わせるかを特定します。

ソースカテゴリー	組み合わせる製品
ソファ	コーヒーテーブル、サイドテーブル、フロアランプ、クッション、ラグ、オットマン
ラウンジチェア	サイドテーブル、フロアランプ、オットマン、スロー
ダイニングテーブル	ダイニングチェア、ペンダントライト、サイドボード、ラグ
デスク	タスクチェア、デスクランプ、モニターアーム、デスクオーガナイザー
ベッド	ナイトスタンド、テーブルランプ、ベンチ、ラグ、ドレッサー
カンファレンステーブル	カンファレンスチェア、クレデンザ、ペンダントライト／ライン照明
タスクチェア	デスク、モニターアーム、タスクライト

デザイナーがコンテキスト（例：「テック企業のオフィスラウンジ」）を提示した場合は、カテゴリーの選定に反映してください。

Step 4: 組み合わせる製品を検索する

各ペアリングカテゴリーについて、ソースの以下の条件に合う製品を検索します。

• スタイル：同じデザイン言語、または意図的なコントラスト
• 素材の調和：素材の相性がよいこと（例：ウォールナットのソファにはクロームではなく真鍮のランプ）
• 色の調和：同じパレット、補色、または意図的なアクセント
• サイズのバランス：ソースに対して適切なサイズ
• 価格帯の整合性：同程度の価格帯（5,000ドルのソファに30ドルのランプを組み合わせない）

ペアリングカテゴリーごとに2～3回検索します。カテゴリーをまたいで、合計5～8点のペアリングを目指します。

Step 5: ペアリングを提示する

Synthetic formatting input only:
Example Product A | Example Manufacturer | quantity 2 | supplied specification pending

提示ルール

• 各ペアリングのデザイン上の理由を説明します。素材の調和、色の論理、サイズ、スタイルについて説明してください。
• ブランドを組み合わせます。デザイナーから指定がない限り、すべて同じブランドの製品だけを提案しないでください。
• アクセントを少なくとも1点含めます。異なる素材、目を引く色、異なる時代などによって、意図的なコントラストを生み出す製品を選んでください。
• 価格帯を揃えます。ソースに見合ったバランスのよいペアリングにしてください。
• ソースがコントラクトグレードの場合は、コントラクト向けの取り扱いがあるかを記載します。

Step 6: 保存する

デザイナーがペアリングを選んだ場合は、解決済みのプロジェクトルートにある product-library.csv に追加する完全な行を用意します。../../schema/product-schema.md と ../../schema/csv-conventions.md を読みます。選択したペアリングすべてと保存先パスをプレビューしてから、既存の明確な承認を使用するか、不足している承認を一度だけ求めます。その承認のもと、完全なバッチを1つのJSON配列としてシリアライズし、/as:product-library に渡して、ネイティブの product_library.append 操作を1回実行させます。この操作では、完全なバリデーション、プレビューとの紐付け、復旧可能な準備、および実際のバイト数とアクセス権の読み戻しを行います。行ごとに繰り返し実行したり、この処理の担当先を迂回したりしてはいけません。

• Tags：追跡できるように pair:{source-product-name} を追加します。
• Notes：Paired with {source product}. {Design reasoning}
• Status：saved
• Source：product-pair

関連機能

• /as:product-match — matchはソースの代替品を探し、pairはソースを引き立てる製品を探します。
• /as:product-research — researchは概要から製品を探し、pairは基準となる製品を中心に組み合わせを構築します。
• /as:product-enrich — ペアリングした製品に完全なメタデータを追加します。
• /as:product-data-import — ソースとペアリングの承認済み取り込みデータを準備します。別途承認された導入はmaster-scheduleが担当します。

元の製品情報の根拠

このタスクでは、元の資料から選択したメーカー、製品、バリエーションの正確な情報を取得します。サンプルデータは合成データであり、根拠として使用してはいけません。製品情報、認証、価格、ベンダー形式の定義を、再利用可能な参考知識としてプラグインにコピーしないでください。未解決の値はそのまま保持し、代表画像と、選択した正確なバリエーションの画像を区別してください。

ネイティブ出力と担当者への引き継ぎ

根拠のある比較、実際に確認した内容、未解決の値は、 完了契約に従って返します。根拠に裏付けられた価格、在庫状況、 リードタイム、正確なバリエーションの情報には、最新の一次資料が必要です。スニペットは情報を探すためだけに使います。 美的な類似性、推定画像スケール、組み合わせに関する判断は、判断であることを明記します。 候補の属性が欠けている場合に、それを補うためのスコア入力や根拠情報を捏造してはいけません。

明示的に保存可能な単独レポートを求められた場合は、 ネイティブ変更シーケンスに従います。保留中の 状態を確認し、完全なソースガードと準備済みレポート全体を保持してから、永続保存を完了します。公開前に、準備済みの実際のバイト列とアクセス権を別途再度開いて検証します。別のファイルを上書きせずに完全なバイト列を公開し、完了前に宛先の実際の内容とアクセス権、および保護対象のすべてのソースを読み返して確認します。レポートによってライブラリやスケジュールのレコードが変更されることはありません。プロジェクトへの永続的な配置や登録については、明示的な座標／種別／最新のソース根拠をドキュメント担当者に引き継ぎます。登録は受領側が担当します。単発の作業は単独のままにします。

既存の認可を使用し、すべての引き継ぎで正確なスコープを維持してください。ライブラリの保存は product-library、採用済みレコードは master-schedule、受け入れ済みの入力ジョブは product-data-import、事実や決定事項は project が担当します。これらのネイティブ手順に Arch Studio runner、ソースの再構築、インストールは必要ありません。外部共有や送信には、それぞれ個別の認可が必要です。