research-components

name	research-components
description	Live web research for a project's components. Starting from a defined objective (integrations, radios, sensors) or an existing BOM, searches the web and the user's preferred marketplaces (AliExpress, Adafruit, Mouser, etc.) for real candidate parts with current listings, prices, and links. Writes a research dossier that feeds the spec, BOM, and sourcing plan.

Research Components

Ground the project in what is actually purchasable today, not model-knowledge price guesses.

Inputs

• User profile from $CLAUDE_USER_DATA/hardware-spec-assembly/config.json — location and preferred/avoided vendors decide which marketplaces to search first.
• Either:
  • Objective brief (pre-BOM): the user describes the project — purpose, integrations, radios (Wi-Fi / BLE / LoRa / Zigbee / Thread), sensors, actuators, power source. Capture this if not already in spec.md.
  • Existing project (post-spec): read <projects_dir>/<slug>/spec.md and bom.json and research each line.

Research pass

For each functional need (radio, sensor, actuator, power, display, MCU variant):

1. Web search for current module options — prefer breakout boards/modules over bare ICs for hobbyist builds. Search for reviews, known clone issues, and library/driver support (Arduino, ESP-IDF, ESPHome) since software support often decides between otherwise-equivalent parts.
2. Marketplace check on the user's preferred vendors — fetch actual listings where possible. Record for each candidate: vendor, listing title, price seen, shipping origin, and URL. AliExpress prices vary wildly between sellers; note a representative range, not one listing.
3. Shortlist 1–3 candidates per need, with a one-line recommendation tying the choice to the objective (e.g. "SX1262 breakout over RFM95: newer silicon, same price band on AliExpress, better ESP-IDF support").

Flag anywhere the web contradicts model knowledge (discontinued parts, superseded revisions, price shifts) — that is the point of this skill.

Output

Write <projects_dir>/<slug>/research.md:

• Objective restated (one paragraph).
• Per-need sections: shortlisted candidates with vendor, price seen, date checked, URL, and recommendation.
• A "discarded options" list with one-line reasons, so the reasoning survives.
• Open questions the research surfaced.

If bom.json exists, offer to update its items with the researched part names and add a price_seen field per line. Prices in research.md are dated snapshots — downstream skills (generate-budget-approximation, suggest-sourcing-options) should prefer them over model estimates when the file is recent.

After

• No spec yet → recommend create-hardware-spec, seeding it from research.md.
• Spec exists → recommend suggest-sourcing-options to turn findings into per-vendor carts.