research-components

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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.

From danielrosehill/Claude-Hardware-Spec-Assembly-Plugin, MIT.

More from danielrosehill/Claude-Hardware-Spec-Assembly-Plugin