SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsatlas-flight-booking

atlas-flight-booking

General & other

View repository

Updated 10-15 19:50

About this skill

Atlas Flight Booking

Operate through the Atlas Flight Booking CLI only. Preserve every opaque ID exactly. Branch on response code, never message, and present only normalized CLI fields.

Capability questions

When the user only asks what this Skill can do or how to use it, answer directly in the user's language. Do not check or install the CLI, check authorization, or call any service. Keep the answer concise and use the following structure or its natural equivalent:

"Atlas Flight Booking supports querying and booking flights using natural language. You can provide exact dates, or describe date ranges, time preferences, or price requirements; I will search for and compare flights that meet the criteria."

For example:

  • 'Search for flights from Shanghai to Tokyo on September 4.'
  • 'Compare the lowest prices for Shanghai to Tokyo from September 1 to 7.'
  • 'Find the cheapest morning direct flights from Tokyo to Osaka in the next two weeks.'

After selecting a flight, you can also continue with price verification, choose baggage and seats, create an order, pay with balance, and check the ticketing status. When price increases, seat substitutions, or payment are involved, your confirmation will be obtained first."

Do not enumerate implementation details or unsupported after-sales operations unless the user asks for more detail.

Start

Treat 0.3.12 as the minimum supported CLI version. Run atlas-flight --version and parse the stable atlas-flight X.Y.Z output. If the command is unavailable, its version output is invalid, or its version is older than 0.3.12, bootstrap or upgrade the required tooling immediately and continue the interrupted flight task. Do not reinstall when the installed version is 0.3.12 or newer, and never downgrade a newer CLI. Do not ask conversational permission to install or upgrade it: the user's request to use this Skill authorizes installation of its required CLI. Allow any native execution-approval prompt from the host to appear, but do not add a separate permission question.

If uv is unavailable, detect the operating system and run the applicable official standalone installer:

  • macOS or Linux: curl -LsSf https://astral.sh/uv/install.sh | sh; use wget -qO- https://astral.sh/uv/install.sh | sh only when curl is unavailable.
  • Windows: powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex".

Use the newly installed executable in the current session, including $HOME/.local/bin/uv on macOS/Linux or $HOME\.local\bin\uv.exe on Windows when uv is not yet on PATH. Run exactly uv tool install --force --python 3.12 atlas-flight-booking==0.3.12, using that resolved executable path when the CLI is missing, invalid, or older than the minimum supported version. If atlas-flight is not yet on PATH, resolve the tool binary directory with uv tool dir --bin and invoke atlas-flight from there; do not ask the user to restart the terminal. Verify that atlas-flight --version now reports 0.3.12 or newer and continue. Only stop when the automatic installation or upgrade actually fails; then give one concise failure explanation and the official https://docs.astral.sh/uv/getting-started/installation/ link. Do not fall back to another Python environment or package manager.

Then run atlas-flight auth status --json. Retain data.ticketing_activation_url and data.ticketing_blocker only when returned; never invent or derive either field. If authorization is required, follow references/cli-contract.md. Explain that Atlas authorization is required before the interrupted task can continue and present the returned URL as a descriptive clickable link. Briefly explain what the user will do on the page: sign in and authorize with an existing ATRIP account, or choose Create one, finish registration, then sign in and authorize. Ask the user to return to the conversation and reply after authorization is complete. Stop the current turn without polling. After the user confirms completion, poll once for at most 120 seconds and resume the interrupted task only after AUTHORIZED.

Search and booking

Collect missing search inputs, search, and list offers. When the retained data.ticketing_blocker is TOP_UP_REQUIRED, explain in friendly language that the account can continue searching flights and prices, but its balance top-up is not yet complete, so price verification, order creation, and ticketing are not yet available. Do not describe this availability as “real-time.” When data.ticketing_activation_url is returned, use this Chinese wording: "The current account can continue to query flights and prices, but the top-up status has not yet taken effect, so price verification, order creation, or ticketing cannot continue for now. You can go to ATRIP workbenchto check the top-up status; after the status is updated, I will check again; if you have already selected an offer, I will first verify the price to confirm the latest price." Use the returned URL for {ticketing_activation_url}. Retain a selected offer whose price_status=current. After the user says the top-up is effective, check authorization status. If data.ticketing_available=true, verify that selected offer_id even when its earlier search result had bookable=false; that flag described availability at search time and does not itself require a new search. Treat the earlier amount only as the previous price. Search again only when no current-price offer was selected or verification returns OFFER_EXPIRED or FLIGHT_UNAVAILABLE. Never reuse an offer whose price_status=reference. Do not describe these results as the separate price-comparison service or include its documentation link.

Flexible search

Resolve relative or fuzzy dates against the current date and the user's timezone. Present the interpreted absolute dates with the results. For one exact departure date, run one new search. For a bounded list or date range, run one complete new search per calendar date, retain each date's search_id and offer IDs separately, and merge the normalized results only after every requested date has been attempted. Never invent a range argument, replay one date as another date, silently sample dates, or claim a definitive cheapest result when part of the comparison failed.

Compare total_price for the complete passenger request, not a per-person amount. Compare prices directly only within the same currency; group or clearly separate other currencies. Apply requested departure-time, direct-flight, airport, or airline preferences to the normalized offers, and state the dates represented in the final shortlist. Origin and destination remain required; do not turn a missing destination into an open-ended “anywhere” search. Preserve the selected offer's original date and opaque IDs before continuing to verification or booking.

Otherwise, when an offer has price_status=reference, describe the results to the user as real-time flight price search and comparison only. State that they do not support continued price verification or ticketing, and include a descriptive link to https://resources.atriptech.com/api-wen-dang/api-reference/booking-apis/price-compare-search#price-compare-search labeled "Price Query and Comparison Instructions" in Chinese or its natural equivalent in the user's language. When authorization returned ticketing_available=false, data.ticketing_blocker=TICKETING_ACTIVATION_REQUIRED, and data.ticketing_activation_url, also explain that the user can open the returned URL through a descriptive "ATRIP workbench" link, complete the unfinished activation steps shown there, then return so the Agent can check status and run a new search. Do not guess whether the unfinished step is email verification, subscription, or access approval. Do not imply that a comparison-only offer can later be purchased or reuse its ID after activation. Do not expose internal product labels. Otherwise, verify only an offer_id returned by the CLI. Tell the user when the verified price decreases. Obtain new explicit confirmation when the verified price increases.

Follow references/booking-workflow.md for optional services, order creation, payment, and ticketing. Read references/passenger-input.md before collecting passenger details. Optional-service unavailability never blocks verification, order creation, payment, or ticketing.

Before payment, present the CLI's current payment summary and show data.order_url only when it is present, then wait for the user's explicit approval of that summary. Use the returned payment confirmation ID exactly once. If payment or order creation is uncertain, query status when an order number is available and never repeat a side-effecting command.

On PAYMENT_BALANCE_CHECK_REQUIRED, explain that payment could not be confirmed and that the ATRIP account balance may be insufficient. Ask the user to check the balance, show data.order_url only when returned, and never submit payment again. Use only order status for any later status check.

Mandatory checkpoints

  • 🛑 AUTHORIZATION: After presenting the authorization link and the existing-account/new-account instructions, stop the turn. Poll only after the user replies that authorization is complete.
  • 🛑 PRICE INCREASE: After presenting the old and new totals, stop. Confirm the increased price only after the user explicitly accepts it.
  • 🛑 SEAT FALLBACK: Before selecting a seat, stop until the user chooses what to do if that seat becomes unavailable during order creation.
  • 🛑 PAYMENT: After presenting the current masked payment summary and any returned order link, stop. Pay only after the user explicitly approves that exact summary.

Safety

Do not inspect configuration, credentials, or internal routing. Do not call services directly. Do not expose passenger input or copy it into chat, logs, command arguments, or saved Skill files. A retryable read-only failure permits at most one identical retry; never retry order creation or payment.

References

Read references/cli-contract.md before constructing commands. Read references/booking-workflow.md for the end-to-end flow, references/passenger-input.md for one-time passenger input, and references/error-handling.md for every non-success code.