product-match

/as:product-match — 製品マッチ

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

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

実際のホスト配信ガイダンスを読みます。利用可能なネイティブの調査、画像、ファイルのツールを使います。操作名は意味上の作業を示すものであり、インストール済みの実行ファイルを示すものではありません。

ネイティブの根拠と権限

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

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

「これに似たものを探して」。名前、画像、説明をもとに製品を指定すると、ウェブ上で似た代替品を検索します。仕様、価格、リンクを含む5～10件の候補を返します。

使用する場面

• デザイナーが気に入った製品があるものの、予算オーバー、廃番、または納期が合わない場合
• クライアントが製品を指定し、異なる価格帯の代替品が必要な場合
• 別のメーカーや地域で、類似製品を調達する場合
• 住宅用製品に相当する業務用製品、またはその逆を探す場合

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

デザイナーは、どのような形式でも製品の情報を提供できます。

名前で指定：

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

名前と条件で指定：

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

画像で指定：

/as:product-match ~/Downloads/chair-photo.jpg

説明で指定：

/as:product-match mid-century lounge chair, molded plywood shell, leather cushions, swivel base

URLで指定：

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

ステップ2：元の製品を特定する

名前またはURLが指定された場合は、製品の主な属性を調べます。

• カテゴリとサブカテゴリ
• 寸法（W、D、H）
• 素材と仕上げ
• 価格帯
• デザイナー／デザインされた時代
• 主な視覚的特徴（シルエット、プロポーション、ディテール）

画像が指定された場合は、利用可能なホストの画像検査機能を使って、次の内容を説明します。

• 製品の種類とカテゴリ
• 形状、プロポーション、シルエット
• 目視できる素材（木材の種類、金属の仕上げ、張り地）
• デザインの時代とデザイン言語
• カラーパレット
• 推定サイズ

説明が指定された場合は、同じ属性をテキストから抽出します。

元の製品を明確に記録します。

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

ステップ 3：類似商品を検索する

異なる切り口で、ウェブ検索を3～5回行います。

1. 直接的な代替品：lounge chairs similar to Eames
2. カテゴリー＋スタイル：mid-century molded plywood lounge chair
3. 価格を指定（予算が明記されている場合）：modern lounge chair under $3,000
4. 素材を指定：leather and walnut lounge chair swivel
5. 業務用・コントラクト向け情報源：contract lounge chair molded wood specification

見つかった候補ごとに、製品ページを取得して詳細仕様を確認します。

目標： 元の商品に実際によく似た候補を5～10件見つけます。数より質を重視します。

ステップ 4：候補を採点して順位付けする

候補ごとに、次の観点で類似度を評価します。

• 外観の類似度（0～5）：元の商品に似ているか？
• 素材の一致度（0～3）：同じ、または類似した素材か？
• 価格の近さ（0～3）：元の価格または明示された予算の妥当な範囲内か？
• 寸法の一致度（0～2）：サイズ感が似ているか？
• 入手可能性（0～2）：在庫があるか、妥当な納期か？

合計15点満点で採点し、点数の高い順に提示します。

ステップ 5：結果を提示する

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

提示ルール

• すばやく比較できるよう、最初に比較表を掲載します
• 各候補について、「理由」を記載します。適した候補である理由と相違点を説明します
• トレードオフに印を付けます：「無垢材ではなく突板」「回転機能なし」「サイズが大きい」など
• 有用であれば、グループ分けします：「最も近い候補」「予算重視の代替品」「コントラクト向け候補」

ステップ 6：保存する

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

• Tags：照合元を追跡できるよう、match:{source-product-name} を追加します
• Notes：Matched from {source product}. {Why reasoning}
• Status：saved
• Source：product-match

併用する機能

• /as:product-research — リサーチでは概要から製品を探し、照合では特定の製品の代替品を探します
• /as:product-enrich — 照合した製品にカテゴリーとタグを追加します
• /as:product-pair — 照合後に、組み合わせに適した製品を探します
• /as:product-data-import — 受け入れ済みデータの取り込みを準備します。別途承認された採用はマスタースケジュールが担当します

元の製品情報の根拠

タスクに必要な、選択されたメーカー、製品、バリエーションに関する正確な事実を、元の文書から取得します。データ例は合成データであり、根拠としては使用できません。製品の事実、認証、価格、またはベンダーの形式定義を、再利用可能な参照知識としてプラグインにコピーしてはいけません。未解決の値はそのまま保持し、代表的な画像と、実際に選択されたバリエーションの画像を区別します。

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

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

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

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