OpenTable

For a user-facing restaurant search or booking, first read
/opt/hatch/skills/booking/SKILL.md,
/opt/hatch/skills/booking/references/restaurants.md, and /opt/hatch/skills/booking/references/presentation.md. Those files define the end-to-end booking, fallback, and presentation rules. Use this file for the OpenTable CLI contract. Keep reservation choices in plain Markdown. Do not call create_options or a comparison/list widget during a restaurant booking.

Connecting

OpenTable needs a one-time in-chat consent before any command returns data. Run opentable status. For a direct reservation request, if it is not_connected, recommend connecting OpenTable as the preferred low-friction path and post the exact returned connect_url. Do not invent one. Explain briefly that this enables live availability, saved-profile use, and smoother booking. Do not wait idle for the connection or make it a prerequisite: continue the same request through the venue's official reservation link, another reputable platform, and phone.place_call when available. If the user connects after a fallback path started, follow the duplicate-protection rule in /opt/hatch/skills/booking/references/restaurants.md before resuming the OpenTable request. If status is unavailable, skip the connection offer and use those fallback paths immediately. If the request is specifically to connect OpenTable rather than reserve a table, post the link immediately and wait for the user to connect. Disconnect with opentable disconnect. Do not send the user to Settings.

Common flows

Find a table

Use lookup-rid to resolve a named restaurant or discover restaurants by city, cuisine, and price. When the city is known, include --city. If there is no clear match, vary the restaurant name or adjust the filters. For example, try common spacing or punctuation variants, pass only the city name to --city, or drop --country-code. Keep the requested location fixed.

Then use search-availability to check open tables for the requested time and party size.

Book

After search-availability, resolve the exact slot from the user's request. Use authorized stored contact details when available; ask only for the name, email, or phone fields still required at checkout. Then book with book-reservation (it locks the slot and books in one step). After book-reservation returns a confirmation, offer to remind the user 30 minutes before the reservation. If they accept or choose another lead time, use cron.add to create a run-once reminder for their chosen time, resolved from the confirmed reservation time.

Modify

Find the new time with search-availability, resolve the exact requested slot, then update with modify-reservation-with-lock. Needs the reservation's confirmation id.

Cancel or look up a reservation

Use cancel-reservation or get-reservation, both by the reservation's confirmation id.

Book an experience

Find it with list-experiences, check times with search-availability --include-experiences true, resolve the exact requested experience and slot, then book with book-reservation --experience-json (include the experience id and version).

Other commands

The flows above cover the common cases. For anything else (a restaurant's policies, seating and dining-area options, releasing a stuck slot lock), run opentable --help for the full command list and opentable <command> --help for its flags.

Rules

• Before book-reservation or modify-reservation-with-lock, resolve the exact restaurant, date, time, and party size. Before cancel-reservation, resolve which reservation the user means. For a booking, take the user's name, email, and phone from an authorized profile or the user. Invoke the resolved command directly so connector policy can present any required approval. Do not add a duplicate chat confirmation. A clear, unambiguous cancellation may proceed without an additional confirmation. Do not guess missing details.
• Read results add UTC and user-local semantic fields when OpenTable supplies an offset-bearing reservation or hold timestamp, plus runtime-generated retrieved_at. A date/time without an offset is restaurant-local civil time; do not guess a timezone or convert it.
• book-reservation verifies the booking with OpenTable before reporting success. Only report the booking as confirmed when the result explicitly says it is confirmed; a confirmation number alone is not proof. When it is confirmed, say so without hedging, mentioning provider lifecycle states, or predicting a later status transition. If OpenTable requires another action, explain what is needed instead of retrying. If the booking is unconfirmed or cannot be verified, say that plainly, keep the confirmation reference, and never retry automatically. Offer only the OpenTable continuation or recovery link returned by the command; the link itself never proves confirmation, and you must never invent one.
• For reservation lookups, summarize the returned status in a natural sentence (for example, "Your reservation is confirmed"). Never quote result field names or provider-internal status fields. Describe cancelled, completed, no-show, or unknown results in the same plain language.
• When OpenTable returns a reservation-management link, include it exactly once as the only web link in the final reply, on its own last line. Do not also link the restaurant profile; multiple links prevent Hatch from rendering the management card.
• Only tell the user a booking, change, or cancellation went through when the command returns a confirmation. If it fails or comes back empty, say so plainly instead of inventing a confirmation or a workaround.
• A result carrying resource_authorization with persisted: false means the OpenTable operation succeeded but the main agent could not confirm that its authorization was stored. Do not automatically repeat a mutation. Give the user the confirmation number and explain that the main agent may not be able to manage it later. Reads are safe to retry except after a rate-limit response.
• Make only one OpenTable connector call at a time. Do not batch calls, run them in parallel or in the background, or put them in shell/Python loops or retry wrappers.
• If an OpenTable command returns HTTP 429 or says it was rate limited, stop making OpenTable calls for this task and report the partial result. Never repeat book-reservation, modify-reservation-with-lock, or cancel-reservation after a rate limit because the mutation may already have applied. If the result includes a confirmation reference, a later task may retry only get-reservation after the returned retry_after, or after 60 seconds if the response has no value.
• A reservation the main agent did not book may not be reachable by get-reservation, modify-reservation-with-lock, or cancel-reservation. If one of those commands is refused, say so and point the user to opentable.com or the restaurant. Do not retry with a different rid or confirmation id.
• Attribute each reservation task to OpenTable. Mention OpenTable when presenting availability. Mention it once more in the final result only when that clarifies who owns the reservation. Do not repeat it in intermediate updates or use promotional language.
• Only add special requests the user gave you (dietary needs, allergies, seating). Do not put unrelated personal data in the booking.
• If lookup-rid finds no match after the applicable retries, stop the OpenTable attempt without checking availability or inventing a rid. If the user asked only whether the venue appears on OpenTable, report that result. If the user intends to reserve, continue with the Search and route section in /opt/hatch/skills/booking/references/restaurants.md.
• If search-availability returns no_availability_reasons, tell the user why in plain language rather than showing the raw code.
• Present restaurant results through
  /opt/hatch/skills/booking/references/presentation.md.
• Keep messages focused on the outcome. Do not quote the command you ran or plan to run, rids, tokens, slot-lock state, or raw result codes like not_connected or NoTimesExist. Tell the user the outcome in normal words. The OpenTable attribution described above is user-facing. It is not an internal implementation detail.

Limits

• The connector cannot book a slot that needs a card, deposit, or prepayment. These show up as a cancellation_policy on the slot in search-availability, or an experience marked prePaymentRequired. When these requirements are present, or a booking is rejected for needing a card, continue the same reservation with browser.spawn_task following /opt/hatch/skills/booking/references/browser-booking.md. Use the returned booking_url with ref=19075 added if missing, or the restaurant's profile_url if no booking URL is returned.
• Bookings are for 1 to 20 diners. For a larger party, tell the user to arrange it with the restaurant directly. Do not book a smaller table or split the group to fit.