Product Research

/as:product-research — Product Research

Before acting, read the host contract and this component's declaration (skill:product-research). Load only its referenced mode profiles from the shared catalog. Compose modes required by the actual task; declarations are requirements, not proof of access or permission.

Library changes are owned by /as:product-library. Prepare the complete selected rows/change set and evidence, then hand off the native save under existing authorization. That owner validates the whole batch, binds exact request/preview/current state and verifies actual publication. This skill does not independently mutate product-library.csv.

<!-- architecture-studio:harness-compatibility -->

Host adapter: read delivery-specific guidance for invocation, questions, target access and optional delegation.

Record authority and host handoff

For structured evidence handoff, read the complete native product-observation owner and schema. Apply native validate/validate-batch to the whole envelope and adapt only with explicit selected-item/current-revision/field bindings. Preserve exact typed values, source/locator/time and unknown status; retain full envelopes, audit observations, conflicts and notices together. Existing null/blank/user overrides survive. This is unadopted evidence and a review proposal, never authorization to write specifications.

For project-bound work, apply native context resolution, use its validated project identity and read project instructions. Inline or one-off source work needs no project creation. Product-library owns reusable CSV storage; master-schedule owns adopted specification identity/revisions, and product-data-import owns accepted job inputs. Do not derive authority from a directory, source document or delivered declaration.

Explicitly distinguish adopted project schedules, one-off source work, and the optional reusable product-library.csv. Adopted item/schedule records are authoritative; read pinned revisions through /as:master-schedule and propose changes to that owner with expected revisions, evidence and preserved overrides. This skill does not independently rewrite canonical item/schedule records or infer approval. Library-save instructions below apply only to the optional CSV library; they do not adopt or update a project schedule.

The host reads and edits supplied workbooks using its available capabilities. Preserve original files, selected images, formulas, true hyperlinks and unrelated cells. For adopted schedules, route adoption/reconciliation and pre-edit native backups plus validated pre/post record CSV recovery snapshots through /as:master-schedule; separately retain the host-extracted workbook data and mapping. In one-off mode, the host preserves native backups and actual workbook-extracted CSV snapshots/mappings in job recovery files without invoking a schedule snapshot or adopting records. Three-way conflicts and proposed removals require explicit resolution. Unsupported workbook access yields a precise handoff, not a false completion claim. For one-off work, the accepted source remains the task input without implicit adoption.

Keep source identity, page/URL locator, retrieval time, selected-versus-available configuration, units and uncertainty with each observation. Never invent SKU combinations, dimensions, finish selection, price or currency; $ alone is ambiguous. Preserve user choices until explicitly changed. Current factual claims require actual source retrieval; inaccessible evidence remains unknown. /as:product-data-import owns accepted job inputs and corrections; /as:product-audit reports discrepancies without silently applying them. /as:product-cut-sheet and /as:ffe-spec-book use the shared document templates and host rendering after inputs are resolved.

Receives a brief from a designer, researches products across the web, and returns a curated shortlist. Selected products can be saved to the nearest project's product-library.csv.

How It Works

Designer gives a brief
        ↓
Host searches authorized sources
        ↓
Presents candidates with specs + reasoning
        ↓
Designer picks winners
        ↓
Saved to project product library

Step 1: Take the Brief

The designer describes what they're looking for. A brief can be loose or specific:

Loose:

"I need acoustic panels for a tech office lobby"

Specific:

"Looking for a round dining table, 48-54" diameter, solid wood top (walnut or oak preferred), steel or brass base, under $3,000, needs to be in stock or <6 week lead time"

What to capture from the brief

Extract as many of these as the designer provides. Don't ask for fields they didn't mention — work with what you have.

Don't interview the designer. If the brief is "acoustic panels for a lobby," that's enough to start searching. You can clarify after showing initial results if needed ("I found options in fabric, felt, and wood slat — any preference?").

Step 2: Research

Search the web for products matching the brief. Use multiple targeted queries to cover different angles:

Search strategy

For a brief like "round dining table, walnut, under $3,000":

1. Category + material search: round walnut dining table
2. Design-focused search: best round wood dining tables architects designers
3. Trade/contract search: contract round dining table solid wood specifications (for commercial projects)
4. Specific brand searches if the designer mentioned preferences: Muuto round table, HAY dining table
5. Sustainability search if relevant: FSC certified round dining table

Run 3-5 searches depending on brief complexity. Aim for breadth — different price points, brands, styles.

For each candidate found

Attempt to fetch the product page with WebFetch to extract full specs. If the page is JS-rendered and returns no data:

• Use the search result only to identify the candidate and locate another current, authoritative source.
• Never fill price, availability, lead time, dimensions, finishes, certifications, or other purchasing facts from model memory.
• Label any volatile fact without a current manufacturer, authorized-dealer, or certification-registry source as Not verified; do not turn a search snippet into a confirmed fact.

For every price, availability, lead-time, finish, dimension, and certification claim, retain the source URL and access date. Prefer the manufacturer's current product page or price list; use an authorized dealer only when the manufacturer does not publish the fact. A candidate may remain useful with Not verified fields, but the shortlist must make those gaps visible.

Target: 6-10 candidates that genuinely match the brief. Don't pad the list with weak matches.

Step 3: Present Candidates

Show results as a numbered shortlist with enough detail to evaluate:

Synthetic formatting input only:
Example Product A | Example Manufacturer | quantity 2 | supplied specification pending

Presentation rules

• Lead with the summary table if there are 6+ candidates — designers scan visually
• Include "Why" for each — explain why this product matches the brief, and flag any compromises
• Flag trade-offs honestly — "veneer not solid", "over budget but worth seeing", "long lead time"
• Don't oversell — if a product is a weak match, say so or don't include it
• Group by angle if useful — "Budget options", "Premium picks", "Fastest delivery"