{"id":65303,"plugin_id":"plugin_asdk_app_69c4d4163c8c819183a9bdcf6d2ac262","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-27T06:06:48.625Z","digest":"71fe5fb9150684f9c14db9fec9c4986e3df62de12c12e344bb2d6be91b0ac5d4","against":null,"payload":{"description":"Find and compare Trip.com low-price flight options across flexible, approximate, or range-based dates for 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":"flexible-flight-search","skill_md_contents":"---\nname: flexible-flight-search\ndescription: Find and compare Trip.com low-price flight options across flexible, approximate, or range-based dates for one-way or round-trip travel. Present results using the associated Trip.com widget.\n---\n\n# Flexible-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_low_price_flights_v2` whenever travel dates are flexible, approximate, or a range, even without the word \"cheap\". For a specific departure day, including \"cheapest on that day\", use `search_flights` according to its schema. For mixed exact and flexible alternatives, ask whether to run exact search, flexible search, or both separately.\n\n## Request construction\n\n- Obtain departure and arrival locations and a concrete departure date window before calling. Obtain the return departure window for round trips. Resolve relative dates using the current date and user timezone. Clarify the year, market, or dates of ambiguous named holidays.\n- Call `search_low_price_flights_v2` for actual fare options. Pass only `tripType`, unchanged `rawQuery`, `locale`, and `segments`. Use en-US and USD as defaults where applicable; do not add a currency parameter that the schema does not accept.\n- Each segment has exactly one `origin.name`, one `destination.name`, and `departureTimeRange` with `startTime` and `endTime` in `YYYY-MM-DD`. Preserve the user's country/region, city, or airport granularity; do not substitute inferred cities or flight codes.\n- One-way uses one segment; round-trip uses two reciprocal segments. Date ranges describe departure dates, including for the return leg.\n- Keep one-way windows within one month. For round trips, keep the span from the earliest outbound departure to the latest return departure within one month. For broader requests, ask to narrow the window or agree on bounded separate searches; do not silently switch to an exact-date search.\n- Cabin, airline, nonstop, baggage, student fares, passenger counts, and connection-city filters are not accepted by this tool. Omit unsupported fields, explain which user constraints cannot be enforced, and do not claim the returned options satisfy them.\n- Multiple location alternatives require separate supported requests; do not pass arrays into single-location fields. Clarify the desired alternatives when necessary. Offer separate one-way searches for multi-city requests without claiming a combined ticket.\n- Prefer v2. Call deprecated `search_low_price_flights` only if v2 is unavailable and the legacy schema is available; build that request from its schema, not the v2 schema. Call `flight_tools_intro` only when tool usage remains unclear.\n\n## Result interpretation\n\nThese are low-price fare options, not a reservation or guarantee of current booking availability. Compare only returned data, preserving currency, price, date, itinerary grouping, and links. Do not invent missing rules or fares. Once the user chooses dates, use `search_flights` if an exact-date follow-up is requested or needed. Do not automatically re-search merely to explain existing results.\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_low_price_flights_v2`, legacy `search_low_price_flights`, and `search_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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}