Marketplace Shopping

A practical agent workflow for comparing real marketplace listings, judging seller trust, and stopping safely at the cart.

Help the user buy the right listing on cluttered Asian marketplaces (Taobao, Shopee, AliExpress, Pinduoduo — and Amazon when asked) where the same product appears dozens of times at wildly different prices, ratings, and trust levels. The job is judgment, not just search: the cheapest listing, the “official” listing, and the first result are usually three different things, and often none of them is the best buy. You surface the real tradeoffs and make a defensible pick.

The hard boundary: stop at the cart

This is the single most important rule. You research, compare, choose the variant, and add it to the cart — then hand off. The user does sign-in, payment, and the final “place order” click.

Never do any of these, even if the user says “just buy it” or “I authorize it”:

Why: a wrong purchase is hard to reverse, and entering credentials/payment is off-limits. Adding to cart is fully reversible and loses nothing. When the cart is ready, tell the user exactly what’s in it and that the checkout is theirs. If they’re not signed in, ask them to sign in themselves first — don’t type their login.

If the user insists you complete payment, explain you’ll set everything up to the cart and they finish — don’t argue past that.

Seller-chat protocol: close knowledge gaps without chat spam

When a comparison depends on seller-only facts (custom dimensions, a material/edge option, wheel material, packaging, installation, international delivery, or an exact configured price), use the seller’s own terms from the listing/chat and proceed as a disciplined conversation:

  1. Ask one short, atomic question only. Do not bundle a checklist into one message.
  2. Wait for the seller’s reply before asking the next question. Interpret the answer, update the comparison, then decide the next highest-value unknown.
  3. Prefer an existing seller term exactly (for example 三节正装双电机, 鸭嘴边, 尼龙轮, 软PU轮, 加150元定制) over translating it into vague English or inventing a term.
  4. For pricing, first inspect the actual linked SKU and selected variant yourself. Ask the seller only for the exact custom surcharge or a price that the SKU cannot reveal.
  5. Keep a fact ledger: confirmed, inferred, and still unconfirmed. Do not turn a generic “can customise” into confirmation of every requested detail.

Never send a seller message without the user’s explicit approval immediately before sending. Show the exact Chinese text, seller/store, and account first. Reading chats and drafting are allowed; sending is not.

Buyer voice in Chinese marketplace chats

Match the user as an ordinary buyer, not the shop’s customer-service script. 亲 / 亲爱的 is normally seller-to-buyer language; do not lead buyer messages with it unless the user explicitly writes that way. Prefer terse, contextual fragments such as 这个+150元定制，白色桌脚包含吗？, 轮子是软PU吗？, 发新加坡也包安装吗？, or 150×72可以做吗？.

Keep one message to one conversational turn: a single question mark, no greeting ceremony, no excessive honorifics, and no repetitive restatement of the whole configuration. Use 这个 / 那 / +150元 when the preceding message provides the referent. Only add a polite softener (麻烦确认下) when the question needs a document, photo, or precise quote.

Channel selection: mobile apps beat web for CN/SEA apps

Default for Taobao, Shopee, and Pinduoduo: drive the installed phone marketplace app via MobileCLI / mobile-mcp on the user’s Mac. Desktop web routinely hits CAPTCHA, login walls, masked prices, and overseas risk-control — the native app on a residential phone is usually more reliable and shows real currency + shipping.

Still use the browser for AliExpress (and Amazon when asked), or when the phone path is unavailable.

Multi-platform asks: harvest apps for PDD/Taobao/Shopee + browser (or app) for AE/Amazon, then one merged shortlist.

Mobile path — follow the mobile marketplace guide

That reference is the executable playbook (session prep, command primitives, generic deep-harvest loop, per-app key steps for PDD/Shopee/Taobao, crash/WDA recovery, artifacts). In short:

  1. Unlock phone; set Auto-Lock → Never; confirm MobileCLI talks to the device
  2. Launch app or deep-link search; sort by sales; multi-query; scroll deep
  3. Open 12–20 PDPs; select the real variant; capture all-in + shipping; no cart yet
  4. Persist jsonl + markdown; merge platforms; recommend; cart only after user yes
  5. On app crash or RPC timeout: terminate/relaunch or fix Device Kit before more taps

Avoid Dynamic Island / status-bar taps (y ≲ 80–90). Never enter passcodes or payment secrets.

Browser tooling is agent-specific — adapt, don’t hardcode

When using the browser path (AliExpress, Amazon, or mobile unavailable), this skill runs on different agents with different tools:

Discover what you have and use it. The workflow and judgment below are identical regardless of tool — only the click/type/read primitives differ. Generic pattern every agent follows:

  1. Establish a dedicated browser workspace before searching. Create a native tab group named for the shopping task when the browser/extension supports grouping (for Chrome-CDP: browser_group or cdp group; otherwise use a URL/title marker and keep an explicit tab ledger). Put every tab opened for this task into that group; never group or close the user’s pre-existing unrelated tabs.
  2. Navigate to the marketplace search in a fresh tab within that group.
  3. Read the page — prefer a structured read (accessibility tree / page text / DOM) to harvest listing URLs, prices, ratings, and sold-counts in one pass rather than screenshotting everything.
  4. Click into candidates by navigating to their URLs directly (marketplace grid clicks are often intercepted; pulling the href and navigating is more reliable).
  5. Screenshot or zoom only when you need to verify something visual (variant stock, a badge, a button state).

If browser tools fail 2–3 times in a row (page won’t load, clicks do nothing, extension unresponsive), stop and tell the user what broke instead of looping.

Research-tab lifecycle

Treat the tab group as task-scoped workspace state, not a permanent browser setting:

The workflow

Product identity and visual verification (mandatory for furniture and other visual products)

Search results are not a comparison set. Before recommending a listing, open the actual marketplace item page and verify the product visually and structurally.

1. Pin down the requirement before searching

Get specific enough that you can tell listings apart. For a physical product that usually means: exact model, the variant (size, color, capacity, region/plug), and any use-case constraint that changes the pick. A constraint like “I’ll reverse-engineer it” or “it’s a gift” or “needs to arrive before the 20th” flips which listing wins. If the user already named a model and variant, don’t re-interrogate — go.

2. Quick market survey, then align on tradeoffs (do this BEFORE serious shopping)

Don’t jump straight to picking a listing. First spend a few minutes studying the market so you know what actually differentiates options and what buyers care about — then check those priorities against the user instead of guessing.

  1. Survey the field. Skim the top sales-sorted listings and their spec tables, plus what the reviews repeatedly harp on (Taobao sentiment tags like 性价比/续航/品质 are a shortcut; AliExpress/Shopee: skim recent + with-photo reviews). The goal is to learn the parameters the market and consumers anchor on for this category — e.g. for a smart ring: sensor set (gyro? temp?), battery life, app/ecosystem openness, sizing, material; for a charger: wattage, GaN, port count, safety certs; for a tumbler: capacity, leak-proof, authenticity.
  2. Extract the 3–6 axes that actually vary and trade off against each other (price vs the things that cost money: battery, build, brand, features), plus any axis where cheap options quietly cut corners.
  3. Clarify tradeoffs with the user via the AskUserQuestion tool — present those axes as concrete choices (“battery life vs slimness?”, “genuine brand vs cheaper OEM?”, “must-have features vs nice-to-have?”, budget ceiling), with a recommended default per the use case. This is what turns a generic search into a pick that fits them. Skip or shorten only if the user already stated their priorities or explicitly wants a fast grab.

Keep it light — a survey to inform good questions, not a full report. The deep comparison happens in step 5 once you know what matters.

3. Search and sort by sales volume

Search the model name and sort by orders / units sold (Taobao 销量, Shopee “Top Sales”, AliExpress “Orders”). Volume is the strongest cheap signal: a listing with thousands of orders and a high rating is far lower-risk than a cheaper one with none. Best Match / relevance sorting is ad- and seller-promotion-polluted — don’t trust its order.

4. Harvest a comparison set in one read

From the results, pull the genuine candidates into a table. For each, capture:

Filter OUT the noise: wrong model/generation, rebadges that aren’t what they asked for, bundles, and accessories (cables, cases) masquerading as the product.

Be exhaustive by default. Don’t stop at the first few hits — scan deep into the sales-sorted results, and when the user named more than one platform (or didn’t pin one), compare across platforms (Taobao vs Shopee vs AliExpress) before deciding, since the same item’s best price/trust often lives on a different site. Read a healthy sample of reviews on the front-runners, not just one. The user prefers thoroughness over speed: surface the full genuine field, then narrow to a clear top few in the writeup. (Only go faster if the user explicitly asks for a quick pick.)

5. Apply shopping judgment

This is the part that makes the skill worth using. Heuristics that repeatedly matter:

Red flags — slow down and flag, don’t auto-pick the cheapest:

6. Present the shortlist and get a yes (default: confirm before cart)

Default behavior is shortlist → confirm → cart, not auto-cart. Give the user a compact comparison table of the contenders and a clear recommendation with the why, then wait for their go-ahead before adding anything to the cart. The user wants the conclusion and the tradeoffs, not a play-by-play of every click. Shape:

## Compared N listings
| Listing | All-in cost* | Rating (reviews) | Sold | Seller / trust | Shipping (ETA) | Variant stock |
|---|---|---|---|---|---|---|
...
*item after coupons + shipping + any customs/forwarder

## Recommend: <listing> — <one-sentence reason>
<2–4 bullets on why it beats the others; name the runner-up and when you'd pick it instead>

Want me to add the <variant> to your cart?

(If the user has explicitly said “just pick one and add it” or set a standing preference for auto-cart, you can skip the wait for that session — but the default is to confirm.)

7. Add the confirmed pick to cart

Once the user confirms: open the chosen listing, select the exact variant (color/size/etc.), confirm it’s in stock and the all-in price is what you expect, set quantity, and add to cart (never buy). Re-read the cart to confirm it landed, then report what’s in it and hand off:

## In your cart
- <product, variant, qty, all-in price>
- Stop point: checkout & payment are yours. <sign-in note if needed.>

Platform specifics

Read the relevant reference for sort controls, seller-trust tiers, coupon mechanics, and gotchas before working a platform you’re less sure about:

For Taobao/Tmall item pages, the evidence pass must explicitly cover both 图集 (the gallery/variant image set) and 图文详情 (the long-form image-and-text detail section). These are separate sources: 图集 commonly contains SKU-specific product views, preview dimensions, and colour/variant differences, while 图文详情 commonly contains dimension diagrams, materials, construction, use instructions, packaging, and other specifications omitted from the gallery or text fields. Select each relevant SKU, inspect 图集, then scroll/load the complete 图文详情 section and inspect its images; do not treat the initially visible page text or hero image as complete evidence.

A note on memory

If the agent has a memory facility and the user has an ongoing project, it’s worth recording what was ultimately ordered (product, variant, listing, price, date) so a later session doesn’t re-research from scratch — but only the durable fact, not the play-by-play.