/market-sizing

name: market-sizing
description: "Market sizing skill for Claude Code and Codex: calculate TAM/SAM for any ICP against Explorium's 150M+ company dataset using real-time firmographic and technographic filters. Iteratively refines filters with the user until the account universe matches intent, then returns the count and filter set for downstream prospecting skills. Use for territory design, capacity planning, investor-ready market sizing, and ICP sharpening. Triggers on 'size the market', 'TAM for', 'how many companies match', 'is my ICP too broad', 'market sizing'. Works in Claude Code, Codex, and Hermes-Agent."

Market Sizing

Iteratively refine a company-level ICP filter set and return a count plus a structured filter artifact ready for downstream prospecting work.

Input

• ICP description (recommended): natural language, or "my ICP" / "our ICP" / nothing (ask).
• Use case (optional): territory design, investor sizing, ICP sharpening (default).
• SAM hypothesis inputs (optional): addressable fraction (0 to 1) and ARPA in USD.

Workflow

1. Parse the ICP into filter dimensions. Tag each user-specified or unspecified. Persona criteria ("CTOs", "VP Sales") are recorded but NOT applied to the company count.

2. Disambiguate ambiguous regions BEFORE counting. "EU" can mean European Union members or the broader European region: ask one clarifying question. Same for "Americas" vs "North America" vs "US and Canada".

3. Resolve every free-text field via autocomplete, then classify the result into ONE of three branches before sizing.

(a) **Clean canonical match.** An unambiguous value is returned for the user's phrasing (e.g. "Software Development" for SaaS; "Salesforce CRM" for a Salesforce filter). Commit and proceed.

(b) **Brittle or parent-only match.** The exact term does not exist in the taxonomy but a parent or sibling does (e.g. "fintech" maps only to a "Financial Services" parent; "Snowflake" only cleans up as "Snowflake Data Cloud" on a variant phrasing). STOP before sizing and surface the candidates to the user with a one-line disambiguation: "No exact match for `<term>`; nearest entries are `<list>`. Approximate with `<parent>`, seed a known company for a lookalike follow-up, or proceed with a tech-stack or intent proxy?" Do NOT silently substitute the parent.

(c) **No match after 2-3 variant phrasings** (bare term, full product name, vendor-plus-suffix like "Stripe Payments"). Surface "no matching value" and offer the same three options as (b).

For flagship vendors (Snowflake, Databricks, Stripe): try the suffix-qualified variant FIRST ("Snowflake Data Cloud", "Stripe Payments") because the bare token often returns a noise hit.

**Taxonomy mutex.** LinkedIn industry and NAICS are mutually exclusive on a single query. Query LinkedIn FIRST; commit on a clean (branch a) match; fall through to NAICS only on no-match. Dual-querying both taxonomies in the same pass is acceptable ONLY when LinkedIn lands in the brittle branch (b) AND the user has approved looking at both candidates.

4. Tech-stack taxonomy-gap framing. When step 3 lands in branch (c) for a flagship vendor, document this as a coverage gap, NOT a sparsity-narrow result. The skill cannot size around a tech filter with no taxonomy entry; the sparsity probe in step 6 measures something different and should not be conflated.

5. Size the audience. Get the total count for the resolved filter set. Country-scoped TAM caveat: the sizing endpoint does NOT strictly enforce country filters at the headline-count level. For any country-scoped TAM, sum the per-location breakdown across requested ISO-2 codes. Never use the global headline count when the user asked for a specific geography.

6. Data-sparsity probe (mandatory when tech-stack or intent filters are applied). Size twice: with the filter (count_filtered) and without it (count_unfiltered). If count_filtered / count_unfiltered is below 0.1, treat as coverage-sparse and use count_unfiltered as the operative TAM. Surface "Explorium coverage of [field] is sparse for this segment." Show both numbers.

7. Classify the sizing band against the operative TAM.

| Operative TAM | Band | Read | |---|---|---| | > 50,000 | Too broad | Probably not operational. | | 5,000 to 50,000 | Healthy enterprise/mid-market | Suggest tier segmentation. | | 1,000 to 5,000 | Sweet spot | Focused primary-tier list. | | 250 to 1,000 | Tight/niche | Flag capacity feasibility. | | < 250 | Too narrow | Coverage risk; suggest widening. |

8. Decide on sample accounts. **Default: skip.** Pull is paid; stats are free.

Pull a ~25-row sample ONLY when ONE of these triggers fires:

(a) **User asked** for account names, a quality sanity check, or a downstream list.

(b) **Sparsity probe needs noise validation.** Ratio in step 6 sits near the 0.10 threshold and you cannot tell from the counts alone whether the filter is sparse-but-real or sparse-and-noisy.

(c) **Brittle match accepted in step 3.** A parent-approximation or variant-qualified match was committed; entity-quality confirmation would tell you whether the substitution captured what the user meant.

If none of the triggers fire, return stats-only and note "stats-only" in the self-check. Skip the pull even when TAM <= 50,000. The 50,000 ceiling is a maximum, not a trigger.

When pulling: ~25 unsorted rows for ICP sanity (do top names look right, or include conglomerate / BPO / staffing noise?), directional geography and sub-industry shape, noise-rate estimation. The sample is unsorted: directional, not ranked. Do not compute employee or revenue percentages from it.

9. Noise-adjusted TAM (mandatory when sample noise is at least 20 percent). Compute `adjusted = round(operative_TAM x (1 - noise_rate), 2 sig figs)`. Re-classify the band against the adjusted number. Cite specific noisy rows. 20-60 percent noise signals revisiting the filter set, not shipping the count.

10. SAM hypothesis (only if both inputs s