name: jdbuyskill description: Use when a user asks Codex to run a JD.com product monitoring, availability check, cart, or checkout task in a visible browser with a product URL, quantity, purchase strategy, local CDP browser, or aligned polling interval. Do not use for CAPTCHA solving, risk-control bypass, bot evasion, stealth automation, internal API automation, or payment verification.

JD Buy Harness Runbook

Operate JD.com purchase tasks as a visible-browser harness. Codex performs each check and browser action itself under the protocol; do not generate a long-running automation program, cron job, daemon, or request-level bot.

Required References

Read these before acting:

1. references/task-schema.md for task parsing and validation.
2. references/harness-protocol.md for allowed states, transitions, page signals, and evidence rules.
3. references/examples.md when the user request is ambiguous or you need parsing examples.

Operating Rules

• Keep exactly one current protocol state from references/harness-protocol.md.
• Report every state transition with the format in Status Format.
• Run the first stock check immediately; only repeat checks at aligned wall-clock boundaries.
• Default to dry_run unless the user explicitly requests submit_order.
• Pause for manual login, CAPTCHA, SMS, risk-control, address blockers, and payment prompts.
• Stop before payment. For submit_order, click final submit at most once, then stop.
• Do not continue from an unexpected page by guessing. Capture evidence and ask the user.

Refuse Or Narrow

Refuse only the unsafe part when possible. Offer a compliant alternative such as notify_only, dry_run, screenshots, HTML snapshots, slower aligned checks, or pausing for manual intervention.

Reject requests to:

• bypass CAPTCHA, login, SMS, risk control, bot detection, or payment confirmation
• spoof headers, patch browser stealth signals, or use internal JD APIs
• run unattended background purchasing or automatic payment
• disable manual intervention for protected steps

Task Setup

Build an in-memory task object before opening the browser:

• product_url: JD product detail URL.
• quantity: purchase quantity, default 1.
• purchase_strategy: notify_only, dry_run, or submit_order; default dry_run.
• poll_aligned_minutes: default 5.
• max_attempts: default 0, meaning no fixed cap while the session remains active.
• browser.mode: cdp or visible; prefer cdp only when a local endpoint is available.

If any required or safety-relevant field is ambiguous, show the interpreted task object and ask for confirmation before continuing.

For CDP mode, ask the user to start Chrome when no endpoint is available:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/jdbuy-chrome-profile

Connect to http://127.0.0.1:9222 with the available browser-control tool. If connection fails, stop and ask the user to restart Chrome with the command above.

Execution Loop

Run exactly this high-level loop:

1. Open the product URL.
2. Run one immediate stock check.··
3. If unavailable, wait until the next aligned wall-clock boundary.
4. Repeat checks only on aligned boundaries.
5. If available, apply purchase_strategy.
6. If manual login, CAPTCHA, SMS, or risk prompt appears, pause and ask the user to handle it.
7. If dry_run, stop before final order submission.
8. If submit_order, click submit order once, then stop for manual payment.

Status Format

At every state transition, report one short block:

state: <STATE>
page: <current URL or page label>
signal: <visible button/text/challenge/checkout marker>
next: <next action or next scheduled check time>

Stop Conditions

Stop immediately when:

• the protocol reaches STOPPED
• the page requires phone-only purchase
• browser control or CDP connection is unavailable
• the user must handle login, CAPTCHA, SMS, risk control, address selection, or payment
• the task violates the safety boundary
• evidence is insufficient to classify the page state

When stopped, summarize the last state, last observed signal, and what user action is needed next.