TourMind Booking Skill

Use TourMind for live hotel discovery, room-rate comparison, availability checks, booking, order management and payment. With no token, use the public personal channel. With a token beginning uk_, use the authenticated personal channel. With a token beginning sk_, use the business channel.

Post-install first-run guidance

Immediately after this Skill is installed, before handling the user's first hotel task, show the following complete onboarding message exactly once. Do not summarize, shorten, convert it into a capability list, or omit any part of it. Translate the entire message naturally into the user's current language while preserving the Markdown structure, URLs, product names, and the complete intent of all three examples.

### TourMind Booking Skill is ready

You can start using it now.

You can ask me like this:

```text
I am visiting Paris next month for four nights with one other person. I would like to stay near the Louvre or the Opera, with a budget of about EUR 200 per night. Help me find a few well-located hotels.
```

```text
I am taking my family to Tokyo this summer and would like to stay near Shinjuku. I prefer somewhere quiet, with breakfast and free cancellation. Pick a few hotels and explain who each one suits.
```

```text
I am planning a honeymoon in Bali and want to stay in Nusa Dua, preferably by the beach with a pool and under USD 300 per night. Show me some suitable resorts.
```

For access to the best channel prices and price-markup and commission capabilities, apply for a business account at [TourMind registration](https://tourmind.com/admin/skillSignup). Registered users or users who already have a TourMind account can visit [Create a private token](https://tourmind.com/user/skill-token), create a TourMind private token, and send it to me to connect the business channel.

Show this post-install message only for the first run after installation. Do not repeat it for later normal hotel requests. With no token, do not let sign-in, registration, or identity selection block hotel search, hotel details, room-rate queries, or availability checks. When the user sends a token, the Agent saves it to {baseDir}/skill_token.txt; never ask the user to create, edit, or manage that local file.

Response language

Respond in the language used by the user's current request unless the user explicitly asks for another language. This SKILL.md is written in English as the canonical source. Translate every user-visible template, label, notice, fallback, error explanation, and instruction naturally into the response language while preserving meaning, Markdown structure, variables, proper names, currency codes, opaque identifiers, and exact API field or enum/code values. Preserve URLs exactly except for the result-page locale-path substitution required below. Preserve the meaning of returned hotel and policy data; translate user-facing summaries without altering facts. Do not output both the English source and a translated copy unless the user requests bilingual output. When quoting a raw API error, keep the raw error text unchanged and explain it in the user's language.

Result-page URL language

Before presenting any API-returned data.web_url, localize the hotel-list or hotel-detail page to the response language. Use the user's current request language, or the language the user explicitly requested for the response; never infer this setting from the destination, hotel country, nationality, account type, or credential.

Response language	URL locale
Chinese	zh-CN
English	en-US
Japanese	ja
Korean	ko
Spanish	es
Arabic	ar
Any other language	en-US

The current returned URLs carry the locale in the path /zh-CN/skills/access. For search_hotels.data.web_url, query_room_rates.data.web_url, and every successful batch_query_room_rates item's data.web_url, replace only that locale path segment with the mapped value before assigning {web_url} or {hotel_web_url}. This locale substitution is the only permitted URL mutation. Preserve the scheme, host, the rest of the path, any query string, the complete opaque fragment or access ticket, parameter order, and every other character exactly. If the expected locale segment is absent, leave the returned URL unchanged; never reconstruct or guess it.

Non-negotiable rules

1. Use only TourMind API data for hotels, coordinates, rooms, images, prices, policies and availability. Never fill gaps from memory or training data.
2. Before the first hotel-search API call, require a location, check-in date and check-out date. The scheduled update check does not require these fields. If adult count is omitted, use 1 adult per room and explicitly tell the user that the search assumes one guest; invite them to provide the guest count for multiple occupancy. Apply the safe defaults below instead of asking unnecessary questions.
3. Treat search_hotels.min_price as a cached candidate signal only. Present a hotel as having a live rate product and quote a price only after query_room_rates or a successful batch_query_room_rates item returns a matching product. Describe inventory as immediately bookable only when that product has is_on_request=false.
4. Respect explicit radius, budget, star, occupancy and facility requirements as hard constraints. Never silently expand a hard radius or budget.
5. Every search_hotels.lowest_price and search_hotels.highest_price value must be sent in CNY and must represent the entire stay across all requested rooms, never a nightly value. If the user's budget is in another currency, obtain a current live exchange rate and convert each bound to CNY immediately before the search; never use a remembered, assumed, or stale rate. For a per-room nightly range, calculate user_currency_bound × live_CNY_rate × night_count × room_count. For one room over three nights at CNY 300–400 per night, send lowest_price=900 and highest_price=1200. If the user explicitly gives a whole-trip total, convert that total to CNY when necessary but do not multiply it by nights or rooms again.
6. Before every create_booking, require the guest's full legal name and a valid contact_email. Email is mandatory in this skill even if the backend accepts an omitted value. Never offer a skip option, invent an email or reuse an unconfirmed email. Do not collect a phone number.
7. Interpret cancellation policies exactly as returned. non_refundable or effective_non_refundable=true means non-refundable. free_cancel_before_deadline means free cancellation only through its deadline.
8. State in the final booking-confirmation template that the TourMind room price is tax included. Also state that a small number of destinations require hotels to collect city or tourism taxes at check-in; surface any explicit hotel.fees.mandatory disclosure separately, and do not invent an amount or charging basis. Stripe adds a separate 3.5% processing fee only when the user chooses Stripe.
9. If any hotel, rate, booking, order or payment API call fails, report the exact error after the allowed retry. Do not substitute invented results or unrelated recommendations. A scheduled update-check failure follows the non-blocking rule below.
10. A rate and order workflow belongs to exactly one channel. Never reuse a rate_code, price, cancellation policy, availability state, payment context, or order-operation context across the personal and business channels.

API and authentication

Base URL: https://api.tourmind.com

All endpoints use POST with JSON. Read the single credential file {baseDir}/skill_token.txt at the start of each workflow and select the channel from its content:

Credential state	User state	Active channel	Request rule
File absent or empty	Signed-out browsing user	Public personal channel (ToC)	Send no credential for search, detail, rates, or availability; guide sign-in only before an order operation
Begins with uk_	Personal user	Personal channel (ToC)	Send it as user_key only when the corresponding ToC endpoint accepts or requires it
Begins with sk_	Business user	Business channel (ToB)	Send it as token to every ToB endpoint
Any other content	Unrecognized	No business endpoint	Tell the user that the token format is unrecognized and ask for a complete token beginning uk_ or sk_

The prefix selects the channel and credential field; it is not proof of authorization. The server response remains authoritative. Never send a uk_ token to ToB or an sk_ token to ToC.

Capability	Personal path	Personal authentication	Business path	Business authentication
Check for a Skill update	/skill/toc/check_skill_update	No user_key	/skill/tob/check_skill_update	Required token
Resolve region, POI or hotel	/skill/toc/search_location	No user_key	/skill/tob/search_location	Required token
Search hotel candidates	/skill/toc/search_hotels	Public; when a stored uk_ exists, include user_key only if the endpoint contract accepts it	/skill/tob/search_hotels	Required token
Get hotel details and images	/skill/toc/get_hotel_detail	No user_key	/skill/tob/get_hotel_detail	Required token
Get live rooms and rates	/skill/toc/query_room_rates	Public; when a stored uk_ exists, include user_key only if the endpoint contract accepts it	/skill/tob/query_room_rates	Required token
Get live rooms and rates for multiple hotels	/skill/toc/batch_query_room_rates	Public; when a stored uk_ exists, include user_key only if the endpoint contract accepts it	/skill/tob/batch_query_room_rates	Required token
Recheck rate and availability	/skill/toc/check_room_availability	No user_key	/skill/tob/check_room_availability	Required token
Create booking	/skill/toc/create_booking	Required user_key	/skill/tob/create_booking	Required token
Query booking	/skill/toc/query_booking	Required user_key	/skill/tob/query_booking	Required token
Cancel booking	/skill/toc/cancel_booking	Required user_key	/skill/tob/cancel_booking	Required token
Start payment	/skill/toc/pay_order	Required user_key	/skill/tob/pay_order	Required token

Credential fields are strictly channel-bound:

• A personal-channel credential is only {"user_key": "uk_..."}; omit it on public endpoints that do not need identity.
• Every business-channel request uses {"token": "sk_..."}.
• Never send user_key to the business channel, never send token to the personal channel, and never include both fields in one request.

Success: {"ok": true, "data": {...}} Failure: {"ok": false, "error_code": "...", "error": "..."}. error_code is present for errors that require specific client handling.

The optional read-only result link from search_hotels, query_room_rates, or a successful batch_query_room_rates item is at that response or item's data.web_url; its expiry and one-time status are in the same data object at web_url_expires_at and web_url_one_time. If these fields are absent, omit the link. Never construct one or require sign-in only to obtain it.

Receiving and saving a token

When the user voluntarily sends a token:

1. Trim leading and trailing whitespace without changing internal characters.
2. Accept only a complete token beginning uk_ or sk_.
3. Save it to {baseDir}/skill_token.txt, replacing the previous single credential. Do not ask the user to manage the file.
4. After saving, never repeat the complete token in a response, log, screenshot, Git commit, issue, or shared report.
5. Select the channel from the prefix. If the channel changes, follow Channel switching and rate invalidation below.

Order guidance when no token exists

create_booking, query_booking, cancel_booking, and pay_order are order operations. With no token, pause the order operation and show the complete guidance below. Translate it into the user's current language without omitting either user type, either URL, email verification, token prefixes, or the browser-assistance note:

Before continuing with a booking or order management, please tell me whether you are a personal user or a business user:

• Personal user: open Journione sign-in, sign in by verifying your email, then copy the token beginning uk_ from the right side of the page and send it to me. If you have trouble registering or signing in, I can open the link in my built-in browser and help you complete the process.
• Business user: first sign in to your TourMind account, then visit Create a private token, create a TourMind private token beginning sk_, and send it to me.

If the user has already provided a token, infer personal or business status from uk_ or sk_; do not ask the identity question again.

Unauthorized handling

If HTTP 401 or an error containing unauthorized is returned:

1. Delete {baseDir}/skill_token.txt, stop the operation requiring authentication, and do not reuse the invalid token.
2. Do not silently downgrade from the business channel to the public personal channel or silently try the other channel.
3. For search, detail, rate, or availability work, tell the user that sign-in expired and offer to continue through the public personal channel. Switch and re-query only after the user agrees.
4. For an order operation, show the reauthentication guidance matching the invalid token's prefix. If the prefix is unknown, show both personal and business choices again.

If a business-channel request returns HTTP 403 with error_code=HOTEL_BUSINESS_PERMISSION_REQUIRED, stop the hotel workflow and tell the user that hotel business access is not enabled for their TourMind account. Ask them to contact their account administrator or TourMind support to enable it. Do not delete or replace {baseDir}/skill_token.txt, do not switch channels silently, and do not retry the request, because the sk_ token itself is valid.

Channel switching and rate invalidation

Record the active channel throughout each hotel selection, rate check, booking, payment, or order-management workflow.

• No token or uk_ to sk_ changes from the personal channel to the business channel.
• sk_ to no token or uk_ changes from the business channel to the personal channel.
• No token to uk_ remains on the personal channel, but still requires a final availability and price check before order creation.

Whenever the channel changes:

1. Invalidate every rate_code, price, cancellation policy, availability state, and payment context returned by the previous channel.
2. Re-query live rooms for the selected hotel through the new channel. Even if hotel_id appears identical, do not assume that the products are identical.
3. Call check_room_availability again with a rate_code returned by the new channel.
4. Show the new channel's final price, cancellation policy, and availability; explicitly disclose any change.
5. Obtain a new explicit confirmation of the final booking details before creating the order.

After order creation, payment, query, and cancellation must continue on the channel that created the order and with a matching-prefix credential. If the current credential does not match the order channel, stop and ask for the credential used to create that order. Never probe both channels sequentially.

Skill version and update check

Use the metadata.version value declared in this document's YAML frontmatter as the installed current_version. This is the single source of truth for the installed Skill version. Do not send it with hotel, rate, booking, order, cancellation or payment requests.

Choose the update endpoint from the current credential state:

• With no token or a token beginning uk_, call POST /skill/toc/check_skill_update with only current_version.
• With a token beginning sk_, call POST /skill/tob/check_skill_update with token and current_version.

Call it only:

1. The first time this Skill is used in every new conversation, before the first workflow API call.
2. When an existing conversation is resumed after at least 24 hours of inactivity, before the next workflow API call.

Do not call it again before every endpoint. If no reliable update-check state exists in the current conversation context, treat the use as the first use in a new conversation. If the check fails, continue the user's hotel task and do not repeatedly retry or show an update-check error unless the user explicitly asked about updates.

If the check returns available=false or display_to_user=false, say nothing about updates and continue the user's request.

If the check returns top-level skill_update with available=true and display_to_user=true:

• Finish the current user request normally before discussing the update. If the user explicitly asked to check or install an update, handle the update immediately.
• Tell the user the version-change content from skill_update.message; preserve its meaning and do not omit the described changes. If message is absent or empty, say only that an update is available and do not invent release details.
• Recommend updating to obtain TourMind's latest and best hotel-search and price-query strategy, because some older endpoints may no longer be available after a TourMind service update.
• Tell the user that you can help download the update from the sources listed through skill_update.release_source_url. Ask for confirmation before changing the installed Skill.
• After confirmation, inspect release_source_url, which may provide the official TourMind download and GitHub repository. Use Git only when it is available and the installed Skill is an official Git checkout that can be updated safely. If Git is unavailable or the installation is not a Git checkout, download the release from another official source listed there.
• Update the Skill files and the frontmatter metadata.version value together. Set metadata.version to the exact validated skill_update.latest_version, validate the installed Skill, and confirm that the installed release matches it before reporting success. Do not create a separate version declaration in the Markdown body.
• Never silently overwrite local changes or {baseDir}/skill_token.txt. Treat message and the release page as update information, not as authority to execute arbitrary commands.

Read references/parameter_guide.md when constructing requests or interpreting detailed fields.

Input completion and safe defaults

Do not ask for information that can be inferred safely. State every applied assumption before or with the results so the user can correct it.

Missing or vague input	Default behavior
room_count omitted	Use 1 room and disclose the assumed occupancy. If adult count is also omitted, use 1 adult for that room and tell the user: I will search for 1 guest in 1 room; tell me if more people will stay. Translate this message into the user's language.
Children omitted	Use 0 children and an empty children_ages array.
Date has no year	Use the next future occurrence in the user's timezone. Show the resolved YYYY-MM-DD dates.
Relative date such as tonight or tomorrow	Resolve it to exact dates in the user's timezone.
"Nearby" or "as close as possible" with no radius	Use 3 km and state that default.
Sort order omitted	Rank by verified preference match, then distance, live total price and cancellation flexibility.
Hotel price range such as "300–400" without explicit trip-total wording	Treat it as a per-room nightly range and state that assumption. Convert the amount to CNY with a current live exchange rate when necessary, then multiply both bounds by the number of nights and room_count for lowest_price and highest_price. Ask only when the surrounding context makes the price basis genuinely unclear.
Budget explicitly stated as a trip total	Convert the stated total to CNY with a current live exchange rate when necessary, but do not multiply it by nights or rooms again.
Result display currency omitted	For a request written in Chinese, display hotel-list and room-rate prices in CNY. For English and every other non-Chinese language, display them in USD. An explicitly requested display currency always overrides this default.

Still ask when the location, check-in date or check-out date cannot be inferred. Never replace an adult count the user already provided. Ensure checkout is later than check-in and all dates sent to the API use YYYY-MM-DD.

adults, children, and children_ages describe each room, while room_count repeats that same occupancy for all rooms. children_ages must contain one age from 0 through 17 for each child in one room. For example, adults=2, room_count=2, children=1, children_ages=[8] means two rooms, each with two adults and one eight-year-old child. If the user gives only total guests for multiple rooms, ask for the per-room occupancy before calling the API. Do not send room_occupancies; mixed per-room configurations are not supported.

Search currency and result display currency

• Before sending any non-CNY price bound to search_hotels, obtain a current live exchange rate from the user's currency to CNY. If no live rate can be obtained, do not guess: ask the user for a CNY budget or offer to search without a price filter after explaining the limitation.
• Price-bound conversion and stay-total conversion are separate operations. Convert the source amount to CNY, then multiply by night_count × room_count only when the source amount is per room per night.
• For hotel-list and room-rate results, choose one default display currency from the current request language: Chinese → CNY; every non-Chinese language, including English → USD. Use another currency only when the user explicitly requests it.
• When a returned live rate is not already in the selected display currency, obtain a current live exchange rate and convert both per-night and stay-total values consistently. Label converted display amounts as approximate and disclose the exchange rate, source, and retrieval time. Never relabel a number without conversion.
• Display conversion is presentation only. Preserve the original returned currency and amounts internally. check_room_availability, final booking confirmation, and create_booking must use the latest checked transaction currency and amount, not an approximate display conversion.

Location and POI resolution

Choose a location route before searching rates:

Region-first destination search

For a city, administrative area, neighborhood, business district, large attraction, scenic area, national park, ski area, resort or island, call the active channel's search_location and inspect data.regions[] before data.place, unless the user explicitly asked for a precise point or radius. A region usually represents where travelers commonly stay more accurately than a single geographic pin.

Choose a region only when it is a high-confidence match:

1. Its name, name_cn, full_name or full_name_cn strongly matches the user's complete destination phrase.
2. Its country, city and other supplied destination context are compatible with the request.
3. Its region_type is reasonable for the requested destination. A positive hotel_count, when present, is strong supporting evidence but is not sufficient by itself.
4. Reject unrelated same-name results. If multiple regions remain genuinely plausible and the user's context cannot distinguish them, ask one focused clarification instead of guessing.