1. Gather requirements — Ask a short, focused set of questions
2. Build a targeted query — Map their needs to proven search terms (spec-driven, not size-driven — see note below)
3. Fetch results from Newegg — Run the bundled script (it calls the API and parses specs)
4. Read the parsed specs — Field reference for what comes back
5. Locally filter/rank — Apply size/resolution/panel preferences the API itself won't filter on
6. Display results — Clean table with parsed specs and clickable purchase links

scripts/monitor_api.py

python scripts/monitor_api.py "144Hz gaming monitor"
python scripts/monitor_api.py "OLED gaming monitor" --max-price 900 --order 15
python scripts/monitor_api.py "curved ultrawide gaming monitor" --min-price 350 --max-price 800 --limit 30

• The query is one quoted positional argument; everything else is an option:

  --min-price

  ,

  --max-price

  ,

  --order

  ,

  --page

  ,

  --limit N

  (default 30),

  --raw

  ,

  --timeout N

  .

• scripts/

  is relative to this skill's own directory — run it from there, or pass the absolute path.
• Exit codes:

  0

  ok,

  1

  usage error,

  2

  transport/API error (message on stderr).
• Always use the slim output. A raw page is ~110 KB and will flood context; slimmed it is ~21 KB. Never dump a raw payload into context or into the reply.

references/http-api.md

• [Highest priority — check first] Category boundary check: Before asking any requirement questions or doing any lookup, determine whether the request is about gaming monitors / displays. If the core product the user is asking about is anything other than a monitor (e.g. GPU, CPU, RAM, motherboard, case, PSU, laptop, mouse/keyboard, speakers, webcam, etc.), stop immediately — do not run Step 1 through Step 6, do not search that category, do not return any product list or recommendation for it. Reply with the fixed script in the "Category Boundary" section below, in one or two sentences. This rule outranks every other rule in this skill, including "don't ask for clarification" and general proactive-helpfulness instincts.
• This check applies mid-conversation too: if the user pivots from monitors to a different category in a follow-up ("这个显示器配什么显卡好" / "what GPU pairs with this?"), the pivot itself is out of scope for this skill — decline the GPU part specifically rather than quietly answering it with fabricated or unverified specs. Answering the monitor part of a mixed question is fine; extending into the other category is not.
• Do not repeatedly ask the user for narrowing details before showing any results — run the default flow (Steps 1–6) once, show results, then ask if they want to narrow further.
• Fetch data silently: just run the script. Never ask the user to install or enable anything, and never mention the script, the API, or how the data was fetched.
• Search in English, answer in the user's language: the catalog is English-only. Translate a Chinese request into an English query before searching (see Step 2) — a non-English query would otherwise return an empty result set that looks like "no matches". The reply itself still follows the user's language.
• Keep payloads small: use the script's slim output. Never paste a raw API payload into context or into the reply.
• On failure or invalid data, report it directly — never pretend it succeeded, and never fabricate a product, price or spec.

• ❌ Calling the product search API for that non-monitor category
• ❌ Showing any product table, price, rating, or recommendation for that category — even "here are some options for reference while we're at it"
• ❌ Segueing into a product list with phrasing like "since you're building a PC, here are some GPUs too..."
• ❌ Explaining unrelated category background at length instead of declining

This feature currently only covers gaming monitors — it doesn't cover {category} right now. I can't look that up here; feel free to ask me separately, or use a general product search instead.

This feature's scope is limited to monitors. For {category}, please ask me in a new question — I can help through a different path.

• Size/format preference: standard 24–27" / large 27–32" / ultrawide curved / no preference
• Any brand preference? (ASUS, MSI, GIGABYTE, Acer, LG, Samsung, etc.)

• Size preference: if user asked for "24–27 inch", filter on

  SizeInches

  outside that range. If it leaves fewer than 5 results, widen by a few inches and note the substitution.
• Ultrawide/curved: filter for

  Aspect Ratio

  =

  21:9

  or

  IsCurved

  =

  true

  , if requested.
• Panel type: if user specified OLED/IPS, filter or prioritize accordingly.
• Otherwise rank primarily by relevance to the use case (refresh rate for competitive, resolution/panel for quality-focused) then by rating.

• Fewer than 8 results after local size/format filtering: widen the size range or drop the format filter, note the substitution to the user.
• Specs missing for some products: show

  —

  for those fields, don't drop the product from the list — price/rating/title are usually still there.
• The script can't run (no Python in the host): not an error — call the API directly per

  references/http-api.md

  , and say nothing about it to the user.
• The script exits

  2

  : retry once, then report the failure honestly — never fill in invented prices or specs.
• Console gaming request: always add the HDMI 2.1 reminder since that spec isn't reliably present in parsed fields.
• Results look off-topic (office monitors, no gaming specs at all): retry with the fallback query from the table in Step 2.
• User wants precise/verified specs on final 2–5 candidates: optionally reuse the

  newegg-compare

  skill's browser-based Productcompare page scrape for a second, authoritative pass before the user buys.