win4r/museai-skills/booking

Booking

Use plain Markdown for booking responses except for flight comparisons. Use the native structured flight list for flight comparisons when the active client supports it. Do not emit HTML, call create_options, or duplicate booking inventory in another widget. The native flight widget owns flight selection and its action.

Turn a direct booking request into a verified reservation or purchase with as little work from the user as possible. Examples include “book dinner tomorrow for two,” “get me a flight from SFO to JFK next Tuesday,” “find me a hotel in SoHo for Friday,” and “get tickets to the Patriots’ next game.”

This skill covers four booking types:

• flights: read /opt/hatch/skills/booking/references/flights.md and

/opt/hatch/skills/booking/references/presentation.md before searching or booking; the required comparison fields affect which facts must be retained from search results

• hotels: read /opt/hatch/skills/booking/references/hotels.md before searching

or booking

• restaurants: read /opt/hatch/skills/booking/references/restaurants.md

before searching or booking

• sports, concert, theater, and other event tickets: read

/opt/hatch/skills/booking/references/tickets.md before searching or booking

Booking is the user-facing entry point. Provider-specific skills are secondary operating manuals: load this skill and its category reference first, then load the relevant provider skill before using that provider. Do not substitute a provider skill or generic browser search for this orchestration layer.

For a browser checkout, read /opt/hatch/skills/booking/references/browser-booking.md before starting it. For a non-flight booking, read /opt/hatch/skills/booking/references/presentation.md before presenting options, a final review, or a confirmation. Read only the references required for the current booking type.

Apply instructions that ask the user a question only in a live conversation. In a detached worker, use authorized context to make reversible assumptions. Put any unresolved blocker in the final message.

Non-negotiable behavior

• Load the category reference before searching or opening a provider, even when

a provider-specific skill appears to cover the request.

• When a relevant, low-friction booking connector is disconnected, recommend

connecting it and surface its supported connection action once when that would improve live availability, saved-profile use, or checkout. Do not make connection a prerequisite or wait idle for it: continue the same request through the official website, another reputable provider, and phone.place_call when that tool is available. A missing, gated, unavailable, or unsuccessful connector ends only that path.

• Keep provider plumbing private. Do not expose internal provider names,

commands, identifiers, offer ids, or tool choices.

• Present flight comparisons with the native structured flight list when it is

available. Present all other booking choices and decisions in plain Markdown. Do not use HTML, call create_options, or duplicate the same options in multiple formats. When Travel Planning owns a plan-first workflow, return the selected candidate to it for the separate book-now-or-later decision.

• For event tickets, do not search seat inventory until the exact occurrence

and ticket count are known, including after a partial reply; an option count is not a ticket count. Never infer a seat attribute from its section name; if a current source does not state shade or coverage, call it unverified.

• Do not ask the user to paste sensitive values into chat unless the active

provider skill explicitly permits the field for checkout. Payment-card data and account credentials never qualify. Do not repeat sensitive values.

Boundary

Direct use requires booking intent. A specific venue or itinerary is not required, but the desired outcome is a transaction rather than inspiration. The exception is a bounded live availability or price check delegated by Travel Planning, which retains trip-level ownership and receives the selected candidate back without checkout preparation.

Do not use this skill for:

• planning a trip, building a multi-part itinerary, or filling in adjacent

needs such as rides, childcare, activities, or meals the user did not ask to book; Travel Planning may still delegate one bounded live check

• “where should I go?” exploration with no intent to reserve
• factual questions such as opening hours, reviews, or flight status
• changing or cancelling an existing booking unless the request explicitly

asks for that and the relevant provider tool supports it

If a direct request contains several bookings, handle each requested item but do not expand it into a broader trip or occasion plan.

Operating principle: discover before asking

Do not begin with a questionnaire. Use available, authorized sources to fill in the request and personalize the search before asking the user for anything. Work from narrow, relevant queries; do not browse unrelated mail, accounts, or transactions.

Check, when available and relevant:

1. Persistent preferences or prior booking context.
2. Connected email for confirmations, receipts, credits, memberships, and the

channels previously used for comparable bookings.

1. Signed-in provider accounts and booking platforms for profile details,

loyalty status, credits, points, booking history, and saved preferences.

1. Connected calendar for conflicts with the requested date or time.
2. Connected wallet or card profile for saved payment methods and known

benefits. Plaid, when available, may identify linked card products and relevant transactions, but it is not a source of points balances, reward rules, or unused travel credits. Do not expose full account or card numbers.

1. Live inventory and the provider’s current terms.

Use what is already connected. For a relevant low-friction booking connector, briefly recommend connecting it early when doing so improves discovery or checkout, and provide only its supported connection action. Continue useful unauthenticated discovery without waiting for the connection. For other accounts or login walls, offer sign-in when authentication materially unlocks the best path or is required to complete checkout. Do not turn it into an up-front questionnaire.

What to remember

Build a small booking profile from explicit choices and reliable history. Keep three kinds of data separate:

• Reusable preferences: airports, airlines, seat location, cabin, hotel

style, neighborhood, restaurant tastes, price comfort, usual dining time, seating preferences, and preferred booking channels. Save these through an available persistent memory or profile capability.

• Account facts: loyalty program names, status tiers, point currencies,

card products, travel-credit programs, and which booking accounts exist. Keep these only in an approved account/profile store or the connector that owns them.

• Sensitive booking identity: legal name, date of birth, passport details,

Known Traveler Number or TSA PreCheck number, loyalty membership numbers, and payment credentials. A provider skill may permit checkout fields in chat; use them only for that checkout. Never copy them into ordinary memory, notes, artifacts, or workspace files, or claim they were remembered.

Apply these evidence rules:

• An explicit statement is a preference.
• A repeated pattern across comparable bookings is a tentative preference.
• One old booking is a search hint, not a permanent preference.
• Do not infer allergies, accessibility needs, identity fields, or willingness

to spend from history.

• Do not overwrite an explicit preference with an inferred one. When recent

evidence conflicts and changes the recommendation, surface the conflict at the decision point.

• After a completed booking, update reusable preferences when the user made

an explicit choice or the booking reinforces a repeated pattern. Store a concise fact, not the full itinerary or receipt.

If persistent memory is unavailable, keep the profile session-local and say nothing that implies it will survive this conversation.

Direct-booking flow

1. Normalize the request

Resolve relative dates into exact local dates. Identify the booking type and the minimum transaction fields for it. Carry reasonable assumptions into search when they are reversible. For example, use one traveler when the user says “me,” or search near the user's home when context makes that clear. Label those assumptions when presenting results.

Do not invent legal names, ages, identity numbers, accessibility needs, dietary restrictions, or payment details.

2. Gather context proactively

Inspect the relevant sources above, preferably in parallel. Extract only facts that can affect this booking. Record internally whether each fact was explicit, observed repeatedly, or inferred from one prior booking.

Do not ask for information already available from an authorized source. Delay sensitive identity and payment fields until a chosen option actually requires them.

3. Ask only for a true blocker

Start searching as soon as a useful search can run. Ask only when a missing fact would create materially different searches, risks booking the wrong thing, or is required to transact and cannot be obtained securely elsewhere.

Keep at most one unanswered question in flight. Prefer a short choice with a recommended default. Do not ask for optional preferences one by one; search with the best available profile and let the results make tradeoffs concrete.

4. Search through the best available path

Use the category reference’s routing. In general:

1. Use a connected native provider or authenticated first-party account when

it can complete the job and preserve relevant loyalty or credits.

1. Use connected booking platforms and compare across them when channel,

availability, or benefits differ.

1. Use the authenticated browser on the provider’s own site.
2. Use a reputable marketplace or aggregator.
3. Use phone.place_call when it is in the tool catalog and the business

accepts bookings by phone. Follow the phone tool’s confirmation rules.

1. Hand off only after the available paths are genuinely blocked. Give the

exact link or number, the filled-in choices, what remains, and why you could not finish.

Actually try an available path before declaring it unavailable. A help page, search snippet, or missing result on one marketplace is not proof that the booking cannot be made.

When one provider has no match, no inventory, or cannot complete the booking, continue immediately through the next suitable provider, the venue or carrier's official site, and then phone.place_call when that tool is available. Do not ask whether to try the next path. Ask only when every available path is blocked by a decision, identity field, authentication step, or commitment that requires the user.

Do not silently substitute a different date, airport, property, restaurant, event, seating class, fare class, or materially different price.

5. Rank a small set of real options

When a choice remains, show three to five bookable contenders, best first. Include only details that separate them and the full amount the user will pay, including taxes and mandatory fees. For comparisons without a flight widget, say why the first option wins for this user, using confirmed preferences and clearly labeled assumptions. For flight widgets, follow the acknowledgement guidance in /opt/hatch/skills/booking/references/flights.md.

Render the choices according to /opt/hatch/skills/booking/references/presentation.md. The native structured list is the primary flight-comparison surface when available; a compact Markdown table is the fallback for flights and the primary surface for other booking types. Do not repeat either as a wall of prose.