--- name: slicktrip-route-price-scout description: Find the cheapest workable dates and options for a flight or hotel by combining the price calendar, flight search and the spread of results, then recommend a short list to compare. Use when the user asks for the cheapest day to fly a route, wants to know whether dates or a neighbourhood change the price, or says find me a good deal for a trip. --- # Scout a route for the cheapest workable options The aim is a short, defensible shortlist: the few dates and options that are cheapest *and* still fit what the user needs. The cheapest single fare is often the wrong answer (a 6 a.m. connection, a date that ruins the trip). Price is one axis; the user's constraints are the others. ## 1. Pin down the constraints before searching Ask only for what is missing, and keep it to one short message: - Route: origin and destination airports or cities. Confirm the codes if the user gave a city with several airports. - Trip type and length: one way, return, or hotel nights. - Flexibility: a fixed date, a window (say, any day in March), or a length of stay the user will accept. - Must-haves: non-stop, cabin, checked bag, hotel star rating or area, maximum budget. Do not assume dates. If the user only says "next month", use the window and state it back to them. ## 2. Map the price landscape with the calendar first Run `price_calendar` for flights, or `hotel_price_calendar` for stays, across the whole window before running detailed searches. The calendar shows which days are cheap at a glance, so you spend detailed searches only where they matter. Look for: - A clear low cluster (several adjacent cheap days) versus one isolated low day. A lone low day is often a fare quirk and may not be bookable in practice; say so. - Weekday versus weekend patterns, which show whether the user should shift their trip rather than just pick a date. - Whether the calendar covers the whole window. Departures more than 329 days out are not priced; say so if the window runs past that. If `price_calendar` returns nothing usable, fall back to `flight_lookup` for one representative date and say the calendar was unavailable. ## 3. Search the best two or three windows in detail From the calendar, take the two or three cheapest clusters and run `search_flights` (and `search_return_flights` for the return leg, or `search_hotels` for stays) on each. For stays, compare the same nights across two or three areas rather than one, because a cheaper area often wins once the user's constraints are applied. Read the spread, not just the minimum. For each window record: - The cheapest option that meets the must-haves. - The median price of the results, so you can tell whether the cheapest is an outlier. - The gap between the cheapest and the next sensible option. A £10 difference rarely matters; a £120 difference does. Use `route_airlines` when the user cares about carriers, or to confirm which airlines serve the route at all before recommending a connection. ## 4. Apply judgement to the raw ranking Downgrade options that look cheap but carry a real cost: - Connections under about 60 minutes, or arrivals in the early morning or after midnight, unless the user accepts them. - Hotels with no free cancellation when the dates are uncertain. - A fare far below the window's median with a result set of one or two options. Treat that as unverified until a second search confirms it. Upgrade options that are slightly dearer but remove a cost: a non-stop, a refundable rate, a central area that saves a taxi. ## 5. Build the shortlist Return three options at most. A good shortlist spans the trade-off: the cheapest, the best balance, and one that is more expensive but removes a real constraint. Do not dump every result. ## Common patterns and traps - **The single-day trap.** One unusually cheap day is frequently a fare that sells out or a sub-fare with restrictions. Confirm it with a detailed search before recommending it. - **Stale windows.** Prices move. Say when the search was run, and recommend a watch (see the fare-watch step in the other skills) rather than implying the price is locked. - **Comparing unlike things.** A cheaper flight with a 14-hour layover is not cheaper in any useful sense. Always state what the user gives up. - **Currency and taxes.** Compare totals with the same currency and taxes included. If a figure looks low, check whether it excludes fees. - **Hotel area drift.** Cheap hotels are often far from the centre. Compare by area and distance, not by star rating alone. - **Empty or thin results.** If a search returns nothing, check the airport or city code, widen the window by a day either side, and say the result is thin rather than inventing options. ## Output ``` Route: to , , Searched: — calendar covered , detailed searches on windows Cheapest workable: Shortlist: 1.