{"id":13005,"plugin_id":"plugin_asdk_app_6a392c6f607081919c2316c958269023","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:02:40.174Z","digest":"41d2652344194c5db6ccf196784751dcc301559fd22d113274dd1b30554bccf5","against":null,"payload":{"name":"vestiaire-shopping-planner","description":"Build coordinated, multi-item shopping plans with Vestiaire Collective catalog tools. Use for outfits, capsule wardrobes, gifts, or other pre-loved luxury shortlists that need several product searches or a shared budget. Do not use when the primary goal is a simple one-item search, one-product details, checkout, order support, or trend research.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":491}],"skill_md_contents":"---\nname: vestiaire-shopping-planner\ndescription: Build coordinated, multi-item shopping plans with Vestiaire Collective catalog tools. Use for outfits, capsule wardrobes, gifts, or other pre-loved luxury shortlists that need several product searches or a shared budget. Do not use when the primary goal is a simple one-item search, one-product details, checkout, order support, or trend research.\n---\n\n# Vestiaire Shopping Planner\n\nCreate a coordinated shortlist with the Vestiaire Collective MCP tools `search`\nand `getProduct`. Treat their current descriptions and schemas as the source of\ntruth for catalog fields, filters, and tool-level limitations.\n\n## Build the shopping brief\n\nExtract the information that the user already gave:\n\n- The goal, occasion, or recipient.\n- Two or more concrete item types and the requested quantity of each.\n- The total budget, per-item limits, and currency.\n- The buyer's market or shipping country.\n- The relevant universe and stated sizes.\n- Hard requirements and optional preferences.\n\nDo not ask again for established information. Ask one concise follow-up question\nwhen a missing value prevents a useful search. An open-ended styling request that\ndoes not name an item type needs the item types, recipient or universe, and budget\nbefore searching.\n\nWhen the user gives only a total budget, create provisional per-item maximums\nwhose sum respects it. For \"under\" or \"below,\" keep the sum strictly lower. For\n\"up to\" or \"at most,\" the sum can equal the limit. State the allocation before\nthe searches. Ask for confirmation only when the allocation could conflict with\na stated priority.\n\n## Search by item type\n\n1. Call `search` separately for each concrete item type. Do not combine unrelated\n   categories into one query. When the user wants more than one of the same item\n   type, use one search to produce enough candidates for the requested quantity.\n2. Preserve the market, currency, and unchanged hard requirements across\n   searches. Apply each size only to its relevant item type. Never carry a\n   clothing size into shoes, bags, or accessories. Apply each provisional or\n   user-supplied per-item maximum.\n3. Follow the `search` tool description for query construction and typed fields.\n   Do not invent filter values or sizing conversions.\n4. If a result needs clarification, relay its question and pause that part of the\n   plan. If a size is unresolved, state that the results are not size-filtered.\n   A verbatim size request without nonempty explicit `sizes` tokens must not\n   produce a filtering claim when `sizeResolution` is absent.\n5. If a search has no results, identify the affected requirement. Suggest one\n   possible refinement, but do not relax the requirement without user approval.\n6. Present the returned products as candidate sets grouped by item type. Do not\n   select a winner at this discovery stage. Ask the user which candidates they\n   want to compare, or which search they want to refine.\n\n## Complete the plan after selection\n\nAfter the user selects candidates or asks for a comparison:\n\n1. Call `getProduct` for each selected product id. Keep the market from its search.\n2. Use only returned facts. Use each returned `url` exactly as supplied.\n3. Follow the MCP comparison contract. Name a preferred match only when the facts\n   support it. Otherwise, explain when each option fits without forcing a winner.\n4. Add current prices only when all selected products use the same currency. Make\n   clear that prices and availability can change.\n\nWrite the completed plan in this order:\n\n1. **Shopping brief** — the confirmed goal, market, budget, sizes, and hard\n   requirements.\n2. **Selected plan** — one row per item with its name and exact link, current\n   price, condition, listed size, and other returned facts that matter. Preserve\n   the requested quantity of each item type.\n3. **Budget status** — the current total in one currency and the remaining amount,\n   or a clear reason that no total is available.\n4. **Trade-offs and unknowns** — facts that affect the choice and missing details\n   the user should verify.\n5. **Styling notes** — optional opinion, clearly separate from catalog facts.\n\n## Boundaries\n\n- Do not buy an item, complete checkout, track an order, or contact a seller.\n- Do not claim that an item is authentic from a fulfilment route or marketplace\n  policy. Do not invent a certificate or item-level authentication evidence.\n- Do not describe an item as discounted unless its returned original price is\n  greater than its current price.\n- Do not claim social popularity, trend ranking, quality, value, rarity, fit, or\n  seller reliability without returned evidence.\n- Do not treat missing data as a negative fact. Label it as unknown.\n- Keep catalog facts separate from styling judgment.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}