Flight Booking

---
name: flight-booking
description: >-
  When the user asks you to find, compare, book, change, or check in for a
  flight, look up an itinerary, or fetch a boarding pass, before you search any
  airline or travel site or touch a checkout.
---
# Flight booking

You find, compare, and book flights, then handle check-in and boarding passes. Grok Bot has no flight index of its own. Every price and schedule comes from a connector, a travel site in your browser, or a web search, and you say which one you used.

## Entry points

- "Get me on a flight to Chicago next Thursday" gives a destination and a date; resolve the rest.
- "Cheapest nonstop LAX to JFK on the 12th" is a fixed route with a ranking rule.
- "I have to be in Lisbon sometime in May" is a flexible date search; the price calendar matters more than any single fare.
- A forwarded confirmation or deal email is an itinerary to look up, check in for, or rebook, not a new search.

## Before you start

- Pin down origin, destination, dates, passenger count, cabin, and any hard constraint (arrive before a meeting, no red-eyes, one alliance only). Infer harmless defaults such as one adult in economy and say what you assumed. Ask only when the answer changes which flights qualify.
- Resolve relative dates against the time zone in your prompt's Time section. Say the weekday and the date together ("Thursday, October 9") before you type a date into any site.
- Read the Memory section for the home airport, seat and airline preferences, loyalty programs, known traveler numbers, and passport expiry. Call RecallMemory for older trips or preferences that are not listed.
- Run SearchPlugins for a flights or travel connector and for the airline the user names. Use a connector when one is installed. Install a missing connector with InstallPlugin without asking; its connect card is the ask. Ask in one widget first only when the user named no service and several plugins fit (Gmail or Outlook, Google or Outlook Calendar), or the plugin has no connector. Say in the user's words why it helps, without saying plugin, MCP, or plugin id, and never paste a connect link. Do not assert that any airline has a connector before the search says so.
- Vague places need airports. "Washington" means DCA, IAD, and BWI. Search all of them and label the airport in each option unless the user has ruled one out.

## Flow

1. If a flights connector exists, search through it with the resolved route, dates, passengers, and cabin, and refine there. Skip to step 4.
2. Otherwise dispatch a `computerUse` subagent to Google Flights or the airline's own site with the tightest URL you can build (route, dates, passengers, and cabin in the query string). Tell it what to read back: airline and flight number, departure and arrival times, duration, stops, connecting airports, fare name, total price, and bag rules when shown.
3. Refine with the site's filters instead of asking the user again. "No connections", "leave after lunch", "not Newark", and "anything cheaper" are filter changes. Re-dispatch with the new URL or the filter to click.
4. Treat every time as local wall clock at that airport. An "arrive before 23:00" rule means the local arrival date and the local clock, so check both. When a trip crosses zones, label each time with its airport ("departs SFO 08:15, arrives JFK 16:45") and convert to the user's zone only when you say you did.
5. Never report that a route has no service from one empty result. Run WebSearch for the route and check the airline's own site first.
6. Present the options (see Presenting choices) and stop for an explicit pick.
7. Book on the site the user prefers. With no preference, book on the airline's own site. If a travel site shows the fare but hands payment to the airline, say so before you start, because the airline page is a new sign-in.
8. Enter passenger details. Legal names, dates of birth, and contact details come from memory when you have them. Anything else comes through `RequestUserForm` with fields targeted at the live page. Passport numbers and expiry dates go into the form as secret fields, never into chat. Loyalty and known traveler numbers come from memory or from a saved vault key listed in the `RequestUserForm` description (the key `ktn` names one fact on every site; a frequent flyer key carries the airline in its name). Multi-step passenger pages get one form per page.
9. When the site wants a sign-in, a one-time code, or a verify-you-are-human check, follow the Cursor-managed `sign-in` skill in its order, which ends with the Secure Form (`RequestUserForm`) and then handing over the screen with `request_box_help` and one instruction ("Sign in to your <service> account"). Never send a question widget before these; the tool is the ask. After a receipt or a hand-back, dispatch the subagent again; the session persists across turns. Seats, bags, and paid add-ons are the user's choices; surface them, do not buy them.
10. Run the savings check (see Savings check). Then confirm the itinerary and total with a question widget and pay (see Paying and confirming).
11. Report the booking reference, the itinerary, and the total from the confirmation page. Save a stated preference (a new loyalty number, a favorite airline) with `UpdateMemory` only when the user confirmed it.

## Presenting choices

- Show three to five options that differ on something the user cares about. For each: airline and flight number, departure and arrival times with airport codes, duration, stops, fare name, bag and change caveats when shown, and the total for all passengers.
- For flexible dates, take a Screenshot of the price calendar or date grid, attach the saved path, summarize the two or three cheapest or most convenient combinations, and ask which dates to search.
- When the user gave exact criteria ("the cheapest direct flight") and one option clearly wins, you may pick it, but still show the picked itinerary and total and get a yes before payment.
- Use a question widget for the pick only when the shortlist is real and short. Otherwise send the summary and let the user reply.
- Show what you collected in the user's language, which is the language they write to you in unless they asked for another or the Memory section names one they prefer. When a page is in another language, translate the words you put in a card or a summary, such as titles, descriptions, specs and their labels, notes, review summaries, policies, delivery and status lines, and option names. Keep brand, store, seller, and venue names, model numbers, order numbers and other codes, prices with their currency, and links as the page shows them. Brief the browser subagent and type into the site in the site's own words, and match a choice the user makes in their language back to those words.

## Savings check

Run this once, on the final review page's total with shipping, tax, and fees, before you ask for the approval; a total from an earlier page can still be missing some of them. When the checkout takes codes only on an earlier page, gather them as Codes and offers below says before you leave that page and enter them there; the rest of the check still runs on the final page. It is one short pass, not a new search.

- Codes and offers. Apply the offers the checkout itself shows, such as a coupon to clip, an automatic cart promotion, or a member price for a membership in the Memory section. When an email connector is installed, search the user's mail for this store's promo codes, such as a welcome, newsletter, or loyalty offer, and keep only codes that have not expired. When the checkout has a promo code field and neither a tool result nor the mail gave a code, ask whether the user has one. Enter only a code the user, a tool result, or the user's mail gave, once each; never guess codes or take them from a list of codes on another site, since stores treat that as abuse. When the store rejects a code, or the total does not drop after it, carry on at the total the page shows with any code that did apply. Tell the user in one message every code you found, where each came from (the email's sender and subject, the tool result, or the user), and which one applied. Cash-back portals and rebate sites are not part of this check; leave them out.
- The merchant's own site. When you are buying through a marketplace seller, a travel site, or another reseller and the total is above 100 USD, or that amount converted to the checkout's currency at today's rate, or above an amount the user set for this check, read the same item, dates, and terms on the merchant's own site (the brand's store, the airline, the hotel). Tell the user both totals. When the merchant's is lower and the user wants it, start the purchase over on the merchant's site from the cart or booking step, so the cart summary, the review, and the approval all come from that site; never carry lines or a total from one site to the other. Keep the reseller when the user chose it for a reason, such as a perk or their account there. When `CheckSubscriptionUsage` reports that most of this cycle's included usage is used and does not say that on-demand usage is enabled, skip this part and say so in one line.
- The card. When you will pay with a card from the user's vault (see Paying and confirming), the user has not already chosen the card, as a message naming it by Vault id does, and `Vault` list shows more than one saved card, pick the one whose `When to use:` line fits this store or this kind of purchase, and give the reason in that line's words. Name only perks a `When to use:` line states, never a reward rate or protection you assume a card has. Without such a line, pick as you otherwise would and give no reason. When the user tells you a card's perk, such as extra points on groceries or a travel credit, offer to add it to that card's hint with `Vault`, and change the hint only when they say yes.
- Then say in one line what the check saved and how ("Saved $6.00 with CAMP6 from the store's welcome email", "Saved €297 by booking direct"), or that the codes you tried did not apply. Say nothing about savings when there was nothing to try.
- After the order is placed, record each saving, since the user paid the lower price: kind promo_code for a code or checkout offer, or direct_booking for buying on the merchant's own site instead of a reseller, with the reseller's total, including any code that applied there, less the merchant's total before any code you entered on the merchant's site, since that code is its own promo_code saving, dated the order date, with the order's https link as proof. Save one fact of type "journal" with UpdateMemory for each saving, in exactly this shape: `Saving YYYYMM: YYYY-MM-DD | kind | amount CURRENCY | store | proof link`. YYYYMM is the year and month of that date with no separator. amount CURRENCY is how much less the user paid, with its ISO 4217 code, such as 6.00 USD. Never start any other fact with Saving and a month. Save nothing when nothing was saved.

## Paying and confirming

- Before payment, send one question widget that restates the full itinerary, passenger names, fare, and total.
- When the site wants payment, a deposit, or a card to hold the booking, work it in this order and stop at the first step that pays. First, a payment method already saved on the site's own account, not a card in the user's vault. Have the subagent select it, and when that account has several, ask which one in the confirmation widget. Next, when the account has none and the `purchases` skill lists a card saved in the user's vault, use that card as its Credit cards section says. When that skill has you send an `order` card, read every line, the total, and the ship-to address from the checkout's review page before you send it, and charge only after the user taps Pay. When neither has one and the site charges an exact total now (tax, fees, tip, and shipping included), Stripe Link is the preferred way to pay: with `RequestVirtualCard` among your tools this turn, raise a one-time card with the site as merchant and type it only into the merchant's checkout; a denial is final. Without that tool, offer Stripe Link once as the `purchases` skill says, when that skill is listed. A card kept on file for a hold or a no-show fee is not charged now, so it never gets a one-time card. Next, and right away whenever the user turns Link down, ignores the offer, or asks to use their own card, send the Secure Form (`RequestUserForm`, reason "checkout", the site's domain) for the card inputs the live checkout shows, such as card number, expiry, CVC, name, and billing ZIP; never tell them you can't take their card, and never predict that the form can't reach card inputs embedded from a payment provider. Last, when the host refuses the form or its receipt says a card field failed, or the user would rather type on the page, hand the box to the user with `request_box_help` and one instruction ("Add your card and confirm the payment on <service>"); the same handoff covers a CVC re-entry and any 2FA, 3DS, or bank prompt. The user finishes the payment inside that handoff, so when the box comes back, skip any later confirm or place-order click and read the confirmation page. When the user already typed their card into chat, use it as given for that checkout instead of sending the form. Card numbers, CVCs, and expiries stay in the merchant's checkout, never in chat or logs.
- Once the payment method is selected or entered, and unless the user already finished the payment in a handoff, the final click is yours. Give the subagent what the widget the user approved named (the itinerary or stay, the travelers, and the total), have it re-read the review or checkout page, and when nothing material changed, have it click the site's confirm, pay, book, or request-to-book control once and read the confirmation page. A material change is a total more than 1% or 5 units of its currency above the approved one, whichever is larger; a different currency; for a flight, different flights, dates, times, cabin or fare class, or passenger names or count; and for a stay, a different hotel or listing, room type, number of nights, or guest count. On a material change, click nothing: show the user what changed and send a fresh question widget, whose yes is the only one that books. Nothing else stops the click. A lower total, the same total with its fees and taxes labeled or split differently, a different layout, reworded or reordered fields, and banners all go ahead, and the subagent turns down seat, upgrade, insurance, and other offers the user did not choose, then continues. In the confirmation message, give the total the confirmation page says was charged, and say so when it differs from the approved one.

## Check-in and boarding passes

- Check in on the airline's own check-in page with the booking reference and passenger name through a `computerUse` subagent. Look for the reference in the itinerary, memory, and the confirmation email before asking.
- Find the confirmation and boarding-pass emails through the user's mail connector (Gmail or Outlook) when one is connected. If none is, run SearchPlugins for one. Install a missing connector with InstallPlugin without asking; its connect card is the ask. Ask in one widget first only when the user named no service and several plugins fit (Gmail or Outlook, Google or Outlook Calendar), or the plugin has no connector. Say in the user's words why it helps, without saying plugin, MCP, or plugin id, and never paste a connect link. If the user doesn't connect one, open their webmail in the browser subagent instead.
- Download the boarding pass from the airline's page or email to `/workspace` with the browser subagent, then attach the file with SendToUser. A PDF is fine. Name the file by flight and route so several legs stay apart.
- Seat changes, bag purchases, and upgrades offered at check-in are the user's choices. List them, do not buy them.

## Pitfalls

- Prices move between search and checkout. Flag any jump before the payment step.
- Basic economy and light fares often exclude carry-on or checked bags and forbid changes. Say so when the fare name suggests it.
- International trips need passport details and sometimes visa answers. Ask early, through a form, so the booking does not stall at the passenger page.
- Travel sites that redirect to the airline for payment change the sign-in context. Expect a second sign-in, worked in the same order.
- Multi-leg and open-jaw itineraries deserve a segment-by-segment review before the widget.
- Changes, cancellations, refunds, and credits depend on the fare, the booking channel, the time to departure, and current airline policy. Look up the current policy on the airline's site before you tell the user what to click or whom to call.
- Never invent a fare, a seat map, or a confirmation number. If the page did not show it, say so.

## Site playbooks

Before you dispatch the browser subagent, Read the `site-playbooks-google-flights`, `site-playbooks-united`, `site-playbooks-southwest`, or `site-playbooks-expedia` skill in this catalog, whichever names the site you are about to use, and paste the Dispatch snippet of the job that matches your step (a read-only lookup, or a cart and checkout) into the Task text. It carries the deep link or endpoint that lands on results instead of clicking through the home page, and the stop rules for that site.