Update to Omneky

{
  "description": "Import a product page URL into the Omneky brand catalogue or update a SKU after scrape confirmation. Keywords: import product, product URL, scrape product, catalogue, SKU, identify product, finalize scraped product, PDP.",
  "included_files": [],
  "name": "omneky-product-import",
  "skill_md_contents": "---\nname: omneky-product-import\ndescription: >-\n  Import a product page URL into the Omneky brand catalogue or update a SKU\n  after scrape confirmation. Keywords: import product, product URL, scrape\n  product, catalogue, SKU, identify product, finalize scraped product, PDP.\n---\n\n# Product import\n\n## Activation analytics\n\nIf the host exposes a skill-activation / analytics hook, call it once per new user request with this skill name; otherwise skip silently. Never invent a tracking tool. Omneky MCP does **not** expose `track_skill_activation`.\n\n## Purpose\n\nURL → catalogue draft → user confirm → finalize. Specialized path of\n`omneky-catalogue` for PDP imports.\n\n## When to use\n\n- User pastes a product URL to import\n- Re-scrape / refresh an existing PDP into a new draft then finalize\n\n## When not to use\n\n- Manual field entry without URL → `omneky-catalogue` (`create_product` /\n  `upsert_brand_product`)\n- Generating creatives from the product before finalize completes\n- Category / collection listing URLs (classify first; usually skip scrape)\n\n## OpenAI runtime contract\n\n- Use only tools from the current OpenAI host + Omneky MCP (`https://mcp.omneky.com/mcp`). Never invent tools.\n- Prefer native ChatGPT / host widgets and question UI for decisions. Use MCP `request_user_decision` for missing structured fields (not deprecated `ask_user`) when listed. Else follow `omneky-failure-modes` § Approval / plain-chat fallback.\n- When intake is incomplete, ask **one** concise chat question. Never invent a question tool.\n- Approval / Generate turns: end the turn after Approve / Deny (or Generate / Cancel) via host UI or plain chat; mutate only after affirmative Approve / Generate. Never invent a fake widget tool.\n- Never invent tokens; OAuth is host-managed.\n\n## Non-negotiable output / safety contract\n\n- Always `identify_product_from_url` before scrape.\n- Finalize with `finalize_scraped_product` — never treat scrape draft as\n  completed via `upsert_brand_product`.\n- Confirm selected images + fields before finalize (Approve widget preferred).\n- No public product-delete tool.\n- Pending scrapes: no tight-loop polling in one turn.\n\n## Staged workflow\n\n### Stage 1 — Brand\n\n1. Resolve `brand_id` (`list_brands` / picker). Prefer numeric id.\n\n### Stage 2 — Identify\n\n1. `identify_product_from_url`.\n2. If listing/category: tell the user; ask for a single product PDP. Stop.\n\n### Stage 3 — Scrape\n\n1. `scrape_product_from_url`.\n2. If `status=pending`: explain; retry later with the same `brand_id` + url.\n3. Do not start multiple parallel scrapes for the same URL in one turn.\n\n### Stage 4 — Confirm\n\n1. Present name, description, images, URL.\n2. Host Approve / Deny / Edit (or plain-chat fallback / `request_user_decision` when listed) — `omneky-failure-modes` § Approval / plain-chat fallback.\n3. End turn after the widget.\n\n### Stage 5 — Finalize\n\n1. On Approve: `finalize_scraped_product` with chosen fields / images.\n2. Optionally `update_product_url` if only the URL should change later.\n3. Hand off to creative or launch skills with the new `product_id`.\n\n### Stage 6 — Re-import\n\n1. Optional `update_product_url` first.\n2. Scrape again → confirm → finalize.\n\n## Failure boundaries\n\n| Failure | Required response |\n| --- | --- |\n| Listing URL | No scrape; request PDP. |\n| Pending | Later retry; no tight loop. |\n| User denies finalize | Leave draft; do not upsert as completed. |\n| Wrong brand | Re-resolve brand; do not finalize onto guessed id. |\n| Delete request | No public delete; explain. |\n"
}