Update to Trip.com

{
  "description": "Search and compare Trip.com flights for a fixed departure date, including the cheapest flight on a specific day and one-way or round-trip travel. Present results using the associated Trip.com widget.",
  "included_files": [
    {
      "relative_path": "references/input-collection.md",
      "size_in_bytes": 2610
    }
  ],
  "name": "flight-search",
  "skill_md_contents": "---\nname: flight-search\ndescription: Search and compare Trip.com flights for a fixed departure date, including the cheapest flight on a specific day and one-way or round-trip travel. Present results using the associated Trip.com widget.\n---\n\n# Fixed-date flight search\n\n## Input collection first\n\nFor flight-search requests, apply this workflow before asking for inputs or calling a search tool. Existing-result comparisons and general Trip help follow their respective sections below.\n\n1. Resolve the known route, travel dates and trip intent from the conversation, then apply only valid schema defaults. Identify all genuinely missing required inputs. Do not ask for known values or require optional preferences to fill a richer form. If nothing is missing, call the appropriate search tool directly without an input form.\n2. If even ONE required input is missing, check the native GPT Intelligent UI form capabilities actually exposed by the Host before writing a plain-text question. When a compatible form with a working submission path is available, you MUST use it first. A single missing travel-date input is enough: show the supported specific-date or date-window controls appropriate to the intent below, preserve the known route, and wait for the user's submission. Collect multiple missing inputs together using only supported controls; known values may be shown as context, not required again.\n3. Use a plain-text question only when no compatible native form capability is exposed, the available form cannot collect/submit the required input, or an actual rendering/submission failure occurs. Do not choose text because only one field is missing, because it is easier, or because the MCP tool declares only a results Widget and no input-form resource. If Host capability is unknown, inspect the available capabilities first; do not invent a tool/API or claim a form was attempted or failed without evidence. For a necessary fallback, ask for ALL currently missing required values in one concise question.\n4. Wait for valid submitted values before searching. Reuse previously known values, validate the submission and request only remaining corrections together. Call the appropriate Trip tool only after required inputs are complete, then display its associated results Widget. Input forms belong to the Host; `_meta.ui.resourceUri` identifies the results Widget and does not decide whether native input forms are available.\n\nBefore collecting date or trip-type inputs, changing the form mode, or validating dates before a search, you MUST read and follow [Input collection details](references/input-collection.md). It contains the existing date-form layouts, round-trip rules, validation limits and examples.\n\n## Tool routing\n\nUse `search_flights` for a specific departure date, even when the user asks for the cheapest fare. Resolve relative dates using the current date and user timezone. If the date is missing, collect a specific day or flexible date window through the input workflow above. For flexible dates, use `search_low_price_flights_v2` according to its schema instead. For mixed exact and flexible alternatives, ask whether to search one or both separately.\n\n## Request construction\n\n- Before searching, obtain the departure and arrival locations and departure date; obtain the return departure date for a round trip. Ask only for missing required information. Apply schema defaults where the user has not specified a preference; use en-US and USD as defaults where applicable.\n- Call `search_flights` to obtain actual flight results. Pass `rawQuery` unchanged and dates as `YYYYMMDD`. Do not substitute remembered or invented flights.\n- For one-way travel use one segment. For round trips use two reciprocal segments with the same location sets reversed. The server returns complete round-trip options in one call; do not invent a separate return-selection tool or combine unrelated one-way offers as a round-trip fare.\n- Keep explicitly requested location alternatives in `departLocations` and `arriveLocations` on the same leg. Preserve country/region, city, and airport granularity; never expand a country into guessed cities. Clarify whether the user wants to compare alternatives or select one when ambiguous.\n- A requested connection city belongs in `filters.transferCities`, not in extra segments. Use only supported cabin, passenger, airline, baggage, and student-fare fields from the tool schema. Do not invent a nonstop filter.\n- Multi-city travel is not supported as a single itinerary. Offer separate one-way searches without claiming a combined ticket or fare.\n- If the tool returns no flights, explain that outcome and ask before changing dates or switching to a flexible search. Use `flight_tools_intro` only if the available tool schemas and descriptions do not resolve a usage question.\n\n## Result interpretation\n\nCompare only the returned options and available fields. Preserve prices, currencies, itinerary groupings, and booking links. Do not infer baggage allowances, refund rules, availability guarantees, or a market-wide lowest price. A search does not reserve, purchase, or confirm a ticket. A request to explain existing results does not require another search unless updated or missing data is needed.\n\n## Trip help and missing information\n\nWhen the user chooses Trip for flight help, first determine whether the available Trip tools can answer the request. For supported searches, reuse information already provided in the conversation and valid schema defaults. Ask only for missing required slots; do not collect every optional preference or guess required facts.\n\nMissing slots, empty results, and tool errors are not reasons to automatically use Web Search. Explain the outcome and offer a relevant next step. For requests the available tools cannot answer, explain the capability limit and guide the user to the corresponding Trip fare details, signed-in order details, or official Trip support. Do not collect irrelevant flight-search slots, login credentials, or payment secrets, and do not pretend an order lookup, ticket change, reservation, or purchase was performed.\n\nIf supplemental public information is needed, search only relevant official Trip sources and verify that the actual page is official and applicable. Answer with the supporting source when it establishes the requested fact. General Trip help cannot establish a particular ticket's baggage, refund, change, or penalty rules. If the actual fare/order rules are missing or official information still cannot establish the specific answer, say what is unknown and guide the user to the exact fare/order details or Trip support. Public search cannot retrieve private order facts.\n\n## Mandatory tool and UI usage\n\nThese presentation rules apply to `search_flights`, `search_low_price_flights_v2`, and legacy `search_low_price_flights` whenever this skill is active.\n\n- For a new or updated flight search, you MUST call the appropriate Trip.com tool after obtaining its required inputs.\n- You MUST use the UI resource declared by the called tool's `_meta.ui.resourceUri` as the flight results interface. This requirement applies after every flight search tool response, including a new search made during a follow-up. The current resource is `ui://flight-low-price/search-results`; use the tool's actual declared URI if it changes.\n- The host loads and renders this resource. Use the associated Trip.com widget; do not invent a render tool, treat the URI as a browser URL, or claim that reading HTML alone displays the widget.\n- After each flight search tool response and its associated widget: Keep all accompanying assistant-authored summary text within 50 words total. State only the key outcome and necessary caveats; do not add headings, bullet lists, extra notes, the full flight list or a results table. This applies again after every new search. Widget content is excluded. Later follow-up comparisons using existing results follow the Markdown-table rule below.\n- GPT Intelligent UI forms are required when available for collecting missing inputs before search. They do not replace the tool-associated results widget. Do NOT create replacement or duplicate flight-results cards, charts, dashboards, HTML, tables or custom interfaces. Input-collection forms and focused follow-up Markdown comparison tables are allowed only for their stated purposes below; do not recreate the full results interface or duplicate the widget.\n- For follow-up comparisons of existing flights, you MUST use a standard, non-interactive Markdown table as the ONLY comparison presentation. Do NOT invoke Intelligent UI or other generative UI tools for the comparison. Do NOT generate additional cards, itinerary diagrams, charts, buttons, HTML, dashboards or custom interfaces, even alongside the table.\n- Compare only the options and fields relevant to the follow-up; do NOT repeat the complete flight list or create another results summary table after a search. Identify options by airline and flight number, preserve returned prices/currencies, dates and itinerary groups, and mark missing facts as unknown. If ordinal references are ambiguous, clarify which flight numbers the user means rather than inventing a new ordering.\n- Use the existing returned data without another tool call solely for comparison or formatting. A Markdown comparison table supplements the existing widget; it MUST NOT replace the associated HTML widget after any new flight search. Brief plain-text identification or caveats may accompany the table, but do not expand them into another results interface.\n- If the host reports that the associated resource is unavailable or cannot render it, report that the required results interface is unavailable. Do not generate a replacement interface. Do not claim the widget was displayed without evidence; do not infer a rendering failure solely because no rendering acknowledgment is exposed.\n- Do not invent instruction-priority overrides: follow explicit user instructions and higher-priority host instructions, and explain any resulting presentation limitation.\n"
}