Update to OrderSync EDI

{
  "description": "Diagnose and fix an X12, EDIFACT or TRADACOMS document that a trading partner rejected, that failed in a translator, or that someone wants checked before sending. Use when the user shares an EDI file or snippet and asks what is wrong, why it was rejected, or whether it is ready to send.",
  "included_files": [],
  "name": "edi-troubleshooting",
  "skill_md_contents": "---\nname: edi-troubleshooting\ndescription: Diagnose and fix an X12, EDIFACT or TRADACOMS document that a trading partner rejected, that failed in a translator, or that someone wants checked before sending. Use when the user shares an EDI file or snippet and asks what is wrong, why it was rejected, or whether it is ready to send.\n---\n\nUse this workflow when the user has an EDI document (pasted or attached) and wants to know whether it is correct, or why it failed. The user's own instructions take priority over these steps.\n\n## Steps\n\n1. Call `validate_edi_document` with the document. Pass `retailer` when the user names the trading partner; for a retailer other than Walmart, Target, Amazon or Costco, also call `check_edi_for_retailer`. If the document is an acknowledgment (997, 999, TA1, 824, CONTRL), follow the edi-rejection-fix skill instead.\n2. If the result has errors, call `explain_edi_document` only when you need the business context (which PO, which line) to describe the fix. Skip it for envelope-only problems.\n3. The widget lists each error with its fix and shows the flagged segments. Reply with the verdict, the first fix to make and the next step; list every error in text only when the user asks or when there are more than the widget shows. When retailer checks ran, mention any failed rule.\n4. When the user asks for a corrected document, change only the values the tool identified (counts, control numbers, check digits) and say which segments you changed. Then call `validate_edi_document` on your corrected version and confirm it passes before handing it over.\n5. When the user received the document and needs to acknowledge it, call `generate_997_acknowledgment` and give them the 997. Explain that check-digit and line-count problems are not reported in a 997 and may come back from the partner as an 824.\n\n## Rules\n\n- Quote tool results exactly. Do not invent error codes, segment positions or element values.\n- A clean validation means the file passes structural, count, control-number, check-digit and date checks. It does not prove the file meets a partner's private implementation guide; say so when the user asks whether a partner will accept it.\n- Never guess a missing value such as a PO number, GLN or price. Ask the user.\n- If the tool says the input is not EDI (for example a PDF or an email), tell the user what the tool accepts rather than parsing the content yourself.\n- For retailer-specific expectations, use `get_retailer_edi_requirements` (see the retailer-edi-onboarding skill).\n"
}