TIMEPIECES//
ON BENCH
// SKILL

Sourcing skill.

Sourcing

This skill exists because past sessions failed at sourcing two different ways:

  1. Quoting prices from memory, trusting URLs without fetching them, mixing supplier tiers as if they were interchangeable.
  2. Surveying a narrow set of boutique suppliers, finding nothing, and bailing out into "let's email them" or "let's commission a custom" — when the part existed on a marketplace listing the survey never looked at.

The methodology below addresses both. The hard rule: search wide, verify hard, email only when justified.

Rule zero: trust nothing you didn't verify in the current session. Prior verification by past Claude is hearsay. Re-verify URLs, prices, stock, and spec match every session before any order recommendation.

Rule one: email is a last resort. If a spec field is missing from a listing, look at another listing, another seller, another search angle, public Q&A, or forum measurements before drafting an email. Email is only acceptable when (a) the information is private to one party (a case maker's exact crystal seat ID where no public mirror or measurement exists), and (b) steps 1–4 below have been exhausted and produced no listing that publishes the missing value. When email is the output, the skill must state why none of the public alternatives worked.

Procedure — apply to every part, every time

1. Build the search-key set

Read builds/watch_NNN/spec.md first. Extract the spec values that constrain the search:

Generate 4–6 query variants. Mix English with maker terminology (e.g., "Dauphine hands NH35 C1 lume", "explorer 39 case 28.5 dial seat", "domed sapphire double dome AR coated"). For Taobao or Chinese-marketplace queries, include transliterations when useful.

2. Search-first across the full viable supplier set

Suppliers in scope (no categorical exclusions):

Tool selection:

Cast wide before narrowing. Pull at least 5–8 candidates into a working list before scoring, more if the field is broad. A four-shop survey is not a market signal.

3. Verify each candidate

For each candidate that survives a first-glance match:

URL verification. Fetched live, not from memory. 404 / wrong variant / wrong product → reject the URL but keep the candidate alive if the supplier homepage carries an equivalent.

Price verification. Extract from the live page. Currency must be explicit ($44 USD, £89 GBP, ¥150 CNY, never bare $). For cross-border purchases, output list price AND an estimated landed cost (list + shipping + ~3% US import duty for AliExpress / Cousins UK / Taobao). Label landed as "estimated". Account-gated pricing → state "account-gated, requires Rob to log in and report price"; do not estimate.

Spec match. Confirm each compatibility-chain item is on the product page. Mark each ✓ confirmed / ✗ not stated / ⚠ partial. Critical fields cannot be ✗ — see "Critical fields" below.

Variant specificity. Confirm the exact variant being verified. The variant name and any visible SKU goes in the output.

4. Trust check (tier-appropriate, listing-level)

Tier is a property of a listing, not a gate. The deeper the trust gap, the deeper the check.

Critical fields — non-negotiable

A listing missing any of these for its part type is rejected, full stop. Do not draft an email asking the seller; move to the next listing.

5. Email only as a justified last resort

Email is acceptable when both are true:

Anti-pattern: emailing before searching marketplace mirrors. Anti-pattern: concluding "no C1 Dauphine exists" from a four-shop survey. Anti-pattern: emailing the original supplier for a stock or color question when the same product is in stock elsewhere.

When email is justified, draft it under builds/watch_NNN/emails/<topic>.md and reference the draft in parts.md.

Output — fixed format, one block per candidate

### <Part type> — Candidate <N> of <total>

- **Product:** <exact name as on the page>
- **Variant/SKU:** <specific variant; SKU if visible>
- **Supplier:** <name> (tier: authorized | maker | modder | marketplace-seller)
- **URL:** <verified live URL>
- **URL verified:** YYYY-MM-DD (this session)
- **Price (list):** <amount + currency> (verified YYYY-MM-DD) | `account-gated — pending Rob login` | `verification failed — see notes`
- **Price (estimated landed):** <amount + USD>   (omit for same-country)
- **Stock:** in stock | out of stock | unknown | account-gated
- **Spec match (vs `builds/watch_NNN/spec.md`):**
  - <item 1>: ✓ | ✗ | ⚠ — <brief detail>
  - <item 2>: ✓ | ✗ | ⚠ — <brief detail>
- **Trust check (marketplace listings only):**
  - Store reputation: <reviews / age / feedback rate>
  - Image authenticity: <clean | appears stolen from X | unverified>
  - Price anomaly: <none | suspect — reason>
- **Verdict:** ✅ recommend order | ⚠ verify with supplier first | ❌ do not order | ⛔ blocked on <dependency>
- **Reasoning:** <one or two sentences>
- **Risks accepted (if any):** <e.g., "no QC guarantee; lume color stated but no batch reference; 21-day shipping">

After producing candidate blocks, finish with a Recommendation section: one or two sentences naming the top candidate and the trade-off, or naming the genuine two-way decision if there is one. Never present a menu and walk away.

Failure modes

Override mechanism

If Rob explicitly asks for an unverified estimate ("just give me your best guess on the strap price") OR a verification shortcut ("skip re-verifying the dial, trust the prior session"), comply — but label the output [UNVERIFIED — guess only] or [UNVERIFIED — shortcut at Rob's request] and state which verification step was skipped. The label must be visible. Default behavior remains full verification; override only on explicit Rob request.

Anti-patterns

After every sourcing pass