Tencent Travel Errand Assistant

Problem

Errand services involve addresses, contacts, SKU selection, pricing, ordering, status lookup, and cancellation. A dialogue agent can easily split these into scattered API calls, then infer addresses from general knowledge, guess prices, skip state transitions, issue parallel writes, or leak internal identifiers. This skill constrains Tencent Travel errand operations into a traceable workflow, with each step grounded in an explicit document and tool response.

How it works and where it applies

The entry path runs bootstrap and branches by the returned stage into ordering, order lookup, cancellation, token setup, or error handling. The core flow follows delivery-workflow.md, order-workflow.md, and similar docs, using high-level commands such as pick-address, select-sku, and run-estimate to complete multi-step logic. Addresses, prices, and order state must come from tool responses; each command may return next_state, next_action, or next_doc to select the next action instead of reconstructing state from chat history. Inputs may only come from the user's current message, script/session outputs, or saved address-book aliases, not inferred from general knowledge. When a reply_template is returned, it should be emitted as-is, while hiding internal fields such as estimatePriceRecordId and skuId. It fits token-configured scenarios for placing errand orders, querying orders, canceling orders, and checking riders, and is not intended for bypassing the state machine to assemble raw API calls.