La plupart des exercices ICP dérivent vers une soupe d’adjectifs — « SaaS mid-market en fintech, growth mindset, conscient de la sécurité ». Les listes construites à partir de ce type de brief sont soit trop restrictives (filtres trop serrés, vous obtenez 30 comptes évidents que tout le monde a déjà) soit trop larges (filtres trop lâches, vous obtenez 4 000 logos que les AE ignorent). Le bundle livré sur cette page fait l’inverse : au lieu de décrire l’ICP, vous pointez vers dix à vingt comptes gagnés en closed-won et laissez Claude faire l’ingénierie inverse de ce qu’ils ont en commun, puis vous laissez Clay traduire cette signature en filtres et en enrichissement.
L’artifact est un Claude Skill — icp-list-builder — qui exécute la boucle graine-vers-liste de bout en bout et écrit un draft classé dans une table Clay. Il est conçu pour donner à un réviseur un rapport Markdown et une table Clay côte à côte, pas pour pousser directement vers l’outbound.
Quand l’utiliser
Utilisez ce skill quand vous pouvez nommer 10-20 comptes closed-won qui partagent une forme reconnaissable, et que vous voulez que les 100-500 prochains candidats leur ressemblent. Les déclencheurs les plus courants en pratique :
Rafraîchissement trimestriel de territoire — les AE ont besoin d’un draft de liste par région, fraîchement scoré par rapport aux signaux publics actuels
Un nouveau produit de niche ou un nouveau niveau tarifaire se lance et la graine de « personnes qui ont dit oui » est petite mais réelle
Un programme outbound a travaillé l’ICP évident et l’équipe a besoin d’une deuxième vague informée par ce qui a closé, pas par ce que le fondateur imaginait initialement que l’ICP serait
Le skill suppose un compte Clay au plan Pro ou supérieur. En dessous du Pro, la surface d’enrichissement est trop étroite pour que la boucle lookalike soit utile, et vous vous retrouverez à payer pour un workflow qui fait à peu près ce que ferait une feuille de calcul plus une recherche LinkedIn.
Quand NE PAS l’utiliser
ABM Tier-1 comptes nommés. Les listes construites manuellement pour 25-50 comptes stratégiques impliquent des inputs de customer success et de direction que le skill ne peut pas modéliser. Utilisez-le pour l’outbound tier-2 et tier-3 ; la variance sur la boucle lookalike est trop élevée pour la sélection tier-1.
Chargement automatique dans des séquences outbound. L’output est un draft classé. Le skill écrit dans une table Clay et produit un rapport Markdown délibérément pour qu’un AE ou SDR doive l’examiner avant tout envoi. Si vous câblez l’output dans un déclencheur de séquence, vous utilisez ceci à mauvais escient.
Re-scoring de comptes déjà dans votre CRM. Utilisez un outil d’intention natif CRM pour ça. Ce skill écrit des candidats net-new ; il ne reclasse pas les connus.
Scoring sur des proxies de catégories protégées. Genre du fondateur, ethnicité du fondateur, alma mater, origine du nom — rien de tout ça n’appartient au rubric. Le fichier de rubric de référence énumère les dimensions autorisées ; n’en ajoutez pas d’autres.
Listes de graines de moins de huit comptes. Le skill refuse de procéder en dessous de huit graines valides car l’extraction de signature n’est pas fiable sur une base plus petite. Si vous n’avez que cinq victoires, construisez la liste manuellement et revenez quand vous en avez plus.
Configuration
Le bundle se trouve dans apps/web/public/artifacts/icp-account-list-builder-clay/ et contient :
SKILL.md — la définition du Claude Skill qui orchestre la boucle
references/1-icp-rubric-template.md — les portes firmographiques et les pondérations de signaux que vous remplissez pour votre équipe
references/2-signal-source-matrix.md — quelles sources publiques comptent comme primaires vs corroborant, et lesquelles sont explicitement interdites
references/3-exclusion-criteria.md — domaines bannis, sociétés mères et patterns firmographiques qui ne doivent jamais apparaître dans l’output
La configuration prend environ 45 minutes la première fois et 5 minutes à chaque rafraîchissement.
Installez le Skill. Déposez SKILL.md dans votre répertoire Claude Skills (ou chargez-le via Claude Code avec /skill load). Remplissez references/1-icp-rubric-template.md avec vos vraies portes firmographiques, signaux technographiques et pondérations. Remplissez references/3-exclusion-criteria.md depuis un export CRM frais de clients, opportunités actives et comptes closed-lost des 180 derniers jours.
Préparez la liste de graines. Un CSV avec company_name, domain et why_we_won (deux phrases). Extrayez les graines de plusieurs AE, segments et mois de clôture — le skill avertit si plus de 60 % des graines partagent un seul AE, secteur ou mois de clôture, car ça produit une liste qui ressemble au territoire d’un seul commercial.
Connectez Clay. Le skill lit votre espace de travail Clay via API. Définissez l’ID d’espace de travail et la clé API dans la configuration locale du Skill (ne les committez jamais dans le bundle).
Première exécution. Invoquez le skill avec votre CSV de graines et un target_list_size de 100. La première exécution est plus lente car l’univers firmographique n’est pas filtré ; les exécutions suivantes sur une vue Clay sauvegardée sont plus rapides.
Revoyez le rapport Markdown et la table Clay ensemble. Le rapport explique la signature de graine, la répartition par type de signal et les décomptes de signalements d’exclusion. La table Clay est la surface de travail pour l’AE.
Ce que le skill fait réellement
Six étapes, dans l’ordre. L’ordre est important — exécuter le scoring LLM avant le filtre firmographique gaspille des crédits et inclut des inadéquations évidentes.
Chargement et validation des inputs. Supprime les graines sans why_we_won et refuse d’exécuter sous huit graines valides.
Extraction de la signature de graine. Envoie les graines et le rubric ICP à Claude, qui retourne une signature structurée : codes sectoriels, fourchette d’effectifs, fourchette de revenus, géographie, stade de financement, marqueurs technographiques et marqueurs d’intention. Les notes why_we_won encodent des signaux qui ne sont pas des colonnes Clay (« ils avaient une page sécurité et conformité ») ; c’est pourquoi un pass LLM est nécessaire avant le filtre déterministe.
Application du filtre firmographique déterministe dans Clay. Traduit les portes strictes de la signature en filtres Clay et les exécute d’abord pour réduire l’univers à environ 500-3 000 candidats. Supprime tout ce qui est dans la liste d’exclusion à cette étape. Faire ça avant le scoring réduit le coût LLM d’environ 30-100x car la plupart des rejets sont des inadéquations firmographiques évidentes qui ne nécessitent aucun raisonnement.
Enrichissement et corroboration des signaux d’intention. Pour chaque candidat restant, demande à Clay d’enrichir la stack technologique, les variations de recrutement et les annonces des 90 derniers jours, puis demande à Claude des scores de correspondance par signal avec citations. Tout signal d’intention unique nécessite un signal corroborant primaire — un changement d’emploi LinkedIn plus un communiqué de presse, par exemple. Les affirmations d’intention de source unique sont scorées à 0 avec la raison « uncorroborated » plutôt que devinées.
Classement, dédoublonnage et écriture par lot dans Clay. Trie par score total, dédoublonne sur la colonne société mère, et écrit les target_list_size premières lignes dans une nouvelle table Clay en un seul batch. Les écritures par ligne brûlent des crédits et laissent un état incohérent en cas d’interruption ; les écritures par batch non.
Production du rapport de sortie. Un document Markdown avec la signature de graine en tête, le tableau de candidats classé, une répartition par type de signal, les décomptes de signalements d’exclusion et les métadonnées d’exécution. Le réviseur lit ceci avant de travailler dans la table Clay.
Réalité des coûts
Les grands leviers de coût sont les crédits d’enrichissement Clay et les tokens Claude. Budgets approximatifs par exécution, ancrés sur un target_list_size de 100 contre un univers filtré firmographiquement de 1 800-2 200 candidats :
Tokens Claude (extraction de signature + scoring par candidat). Environ 500k-700k tokens d’entrée et 80k-120k tokens de sortie sur Claude Opus par exécution. Au tarif affiché d’Opus 4.7, ça atterrit autour de 9-14 $ par exécution. Sur Claude Sonnet, la même boucle est autour de 1,50-2,50 $ par exécution avec une perte de qualité mesurable sur l’étape d’extraction de signature (le raisonnement de pattern de graine bénéficie du modèle plus grand). Recommandation : Opus pour l’étape de signature, Sonnet pour l’étape de scoring par candidat.
Crédits Clay. Environ 800-1 000 crédits d’enrichissement par exécution pour un output de 100 lignes, supposant 2 000 candidats entrant dans l’étape d’enrichissement. Au tarif Clay Pro, c’est environ 24-30 $ de coût en crédits par exécution ; sur le niveau Explorer les crédits sont plus serrés et vous devriez baisser le target_list_size à 50 ou pré-filtrer plus fort.
À l’échelle. Une équipe exécutant ceci hebdomadairement par région (par exemple, quatre pods AE) arrive à environ 1 300-2 000 $ par mois combinés (150-200 $ de Claude, le reste en crédits Clay). C’est bien en dessous du coût d’un seul siège ZoomInfo SalesOS et produit une liste plus fraîche, mais ça requiert que le rubric et le fichier d’exclusion soient maintenus à jour — les inputs obsolètes sont là où le coût dérape (vous payez des crédits pour enrichir des comptes qui n’auraient jamais dû passer l’Étape 1).
Le pattern de dérapage de coût dominant est d’appeler le skill de manière répétée avec une porte firmographique lâche et regarder l’univers de candidats exploser. La garde est à l’Étape 3 : si Clay retourne plus de 5 000 candidats, le skill resserre une fourchette et ré-exécute plutôt qu’enrichir l’ensemble.
Métriques de succès
La métrique à observer est le taux auquel les AE acceptent le draft de liste dans leur set de travail sans retouche manuelle. Cible : 70 %+ accepté (c’est-à-dire que sur 100 candidats classés, au moins 70 atterrissent dans la file outbound de quelqu’un sans être supprimés ou réétiquetés). En dessous de 50 % d’acceptation, le rubric est faux, la liste de graines est biaisée, ou le fichier d’exclusion est obsolète — diagnostiquez dans cet ordre.
Secondaire : taux de réservation de réunion sur les comptes acceptés par rapport au taux de base outbound de l’équipe. Le skill amortit son coût en crédits quand ce taux est au moins égal au taux de base ; la valeur ajoutée est la réduction du temps de construction de liste, pas nécessairement une augmentation immédiate du taux de conversion.
Alternatives
vs LinkedIn Sales Navigator + filtrage manuel. Sales Nav est le bon outil pour les listes tier-1 construites manuellement et pour la prospection individuelle sur un candidat. C’est le mauvais outil pour produire 100 lookalikes classés chaque semaine — les filtres de recherche sauvegardée ne capturent pas les signaux d’intention, et le temps de filtrage manuel par liste est d’environ 3-5 heures d’une semaine SDR. Ce skill remplace ces 3-5 heures par 5 minutes de revue d’un draft classé.
vs ZoomInfo SalesOS Intent. SalesOS est mature, a de bonnes données d’intention sur les comptes entreprise, et est la bonne réponse si vous avez un mouvement entreprise et le budget pour 35k-80k $/an de sièges. Pour un mouvement mid-market dans une équipe plus petite, ce skill plus Clay Pro représente environ 80 % du signal à 5-10 % du coût, avec comme compromis que vous possédez le rubric et la liste d’exclusion plutôt que de vous fier au scoring du vendeur.
vs Apollo Living Data. La fonctionnalité lookalike d’Apollo est la plus proche en forme de ce skill et ne nécessite qu’un clic plutôt qu’une configuration de 45 minutes. Le scoring lookalike d’Apollo est opaque (vous ne pouvez pas voir les pondérations de signal ni les remplacer) et les outputs ont tendance à sur-indexer sur la similarité firmographique. Ce skill rend le rubric et les pondérations inspectables et impose la corroboration par signal ; le coût est le temps de configuration et l’obligation de maintenir les fichiers de référence à jour.
vs rien (statu quo, l’AE construit la liste). Les listes construites par les AE sont exhaustives sur les comptes connus de l’AE et faibles sur les lookalikes que l’AE n’a pas entendus parler. Ce skill est l’inverse — il est mauvais sur les comptes stratégiques nommés et bon pour faire remonter les 100 prochains lookalikes. Le pattern honnête est d’exécuter les deux en parallèle : l’AE possède la liste nommée, le skill produit le draft lookalike.
Points de vigilance
Données firmographiques de mauvaise qualité depuis des sources publiques. Les chiffres d’effectifs et de revenus des agrégateurs accusent un retard de 6-18 mois sur la réalité et sont erronés de 30-50 % sur les entreprises en phase de croissance. Protection : le skill traite toute source firmographique unique comme directionnelle et exige un accord entre deux sources indépendantes avant d’appliquer une porte stricte. Les conflits remontent dans le rapport de sortie (« LinkedIn dit 120, BuiltWith dit 380 — signalé pour revue manuelle ») plutôt que d’être résolus silencieusement.
Bruit des signaux d’intention. Un signal « a recruté un VP des Ventes » extrait de LinkedIn seul classe mal les promotions, rôles de conseil et inflation de titre comme nouvelles embauches nettes. Protection : l’Étape 4 exige un signal corroborant primaire (communiqué de presse, preuve LinkedIn sous un angle différent) avant qu’un signal d’intention score au-dessus de 0 ; les affirmations non corroborées sont scorées à 0 avec la raison enregistrée pour l’audit.
Empoisonnement de liste depuis des bases de données obsolètes. Certaines sources d’enrichissement Clay contiennent des entreprises zombies — acquises, fusionnées ou défuntes — qui passent les filtres mais ne peuvent pas acheter. Protection : supprimez tout candidat dont le site web retourne un 4xx/5xx sur la vérification de la page d’accueil, n’a aucune activité LinkedIn dans les 90 derniers jours, ou dont le champ société mère se résout en un acquéreur connu dans le fichier d’exclusion. Le décompte des suppressions apparaît dans les métadonnées d’exécution pour que l’opérateur puisse repérer un pic (signe de dégradation du fichier d’exclusion ou de la source d’agrégateur).
Biais de graine. Une liste de graines de 10 victoires d’un seul AE dans un seul secteur produit une liste qui ressemble au territoire de cet AE. Protection : le skill avertit si plus de 60 % des graines partagent le même AE, secteur ou mois de clôture, et demande à l’opérateur d’élargir la graine avant de continuer.
Sur-ajustement du filtre. Une signature si serrée qu’elle ne correspond qu’aux 14 graines produit 0-30 candidats et paraît précise mais est inutile. Protection : si l’Étape 3 retourne moins de 200 candidats, le skill élargit les fourchettes d’effectifs et de revenus d’un cran et ré-exécute plutôt que de procéder avec un univers affamé.
Fichier d’exclusion obsolète. Si l’export de la liste clients a deux mois, un client peut passer à travers et se retrouver en outbound. Protection : le skill avertit dans le rapport de sortie quand last_refreshed dans le fichier d’exclusion est plus vieux de 14 jours.
Stack
Clay (Pro ou supérieur) — substrat d’enrichissement, filtre firmographique et table de destination. Le Pro est le plancher pratique pour la boucle lookalike.
Claude (Opus 4.7 pour l’extraction de signature, Sonnet pour le scoring par candidat) — raisonnement de signature sur les notes why_we_won des graines et scoring de corroboration par signal avec citations. Diviser la sélection de modèle entre les deux étapes est là où le compromis coût-qualité atterrit le mieux.
CRM (n’importe lequel) — source de la liste de graines, liste clients, liste d’opportunités et liste closed-lost qui alimente le fichier d’exclusion. Le skill ne lit pas directement le CRM ; l’opérateur exporte des CSVs.
Destination outbound (Outreach, Salesloft, Apollo, personnalisée) — où va la liste revue après acceptation par l’AE. Le skill s’arrête à la table Clay par conception.
---
name: icp-list-builder
description: Build a ranked target-account list from public signals using a closed-won seed pattern. Input is a seed of 10-20 closed-won accounts plus an ICP rubric; output is a ranked list of 100-500 lookalike candidates with per-account evidence, ready to write to a Clay table for outbound or AE territory routing.
---
# ICP list builder (Clay + Claude)
## When to invoke
Invoke this skill when a RevOps or SDR leader needs a fresh target-account list grounded in what already worked — not in a generic "mid-market SaaS in fintech" description. The skill takes closed-won accounts as the ground truth, extracts the firmographic + technographic + intent signature shared across them, then proposes Clay filters that produce lookalikes plus a ranked candidate list with evidence.
Typical triggers:
- Quarterly territory refresh — AEs need a new draft list per region
- New product or new wedge launch — the seed list is small (10-20 wins) and you want the next 100 to look like them
- Outbound program needs more accounts after the obvious ICP has been worked
Do NOT invoke this skill for:
- Auto-loading the output into outbound sequences without rep review. The output is a ranked draft, not a send list. AE or SDR review is mandatory.
- Scoring on protected-class proxies (founder gender, ethnicity, school). Rubric weighting must be on firmographic and intent signals only.
- Account lists for ABM tier-1 named accounts — that work is hand-built and this skill's lookalike loop has too much variance for tier-1 selection.
- Buying-signal scoring inside an existing CRM record (use a CRM-native intent tool — this skill writes new candidates, it does not re-score known ones).
## Inputs
Required:
- `seed_accounts` — CSV with columns `company_name`, `domain`, `why_we_won` (two sentences). 10-20 rows. Rows with missing `why_we_won` are dropped with a warning rather than silently skipped.
- `icp_rubric` — path to `references/1-icp-rubric-template.md` filled in for your team. Defines hard firmographic gates and signal-weight ordering.
- `target_list_size` — integer, the number of ranked candidates to return. Default 100. Hard cap 500 (above that, Clay credits and signal noise both blow up).
Optional:
- `signal_sources` — path to `references/2-signal-source-matrix.md` to override which public sources Clay/Claude should query and which it should ignore. Defaults: company website, LinkedIn company page, BuiltWith, public hiring pages, last-90-day press/funding announcements.
- `exclusion_list` — path to `references/3-exclusion-criteria.md`. Domains, parent companies, or firmographic patterns that must never appear in the output (existing customers, active opportunities, do-not-contact, known losses inside last 6 months).
- `territory_filter` — geography or vertical filter applied after scoring, for splitting the output by AE territory.
## Reference files
Always read the following from `references/` before generating the list. They contain the team's actual ICP definition, source preferences, and exclusions. Without them, the list is generic and may write banned domains.
- `references/1-icp-rubric-template.md` — hard firmographic gates plus the signal-weight order used for scoring. Replace template contents with your real rubric before first run.
- `references/2-signal-source-matrix.md` — which public sources count as primary vs corroborating, and which are explicitly disallowed (low-quality scraped databases, stale aggregators). Replace with the team's source policy.
- `references/3-exclusion-criteria.md` — banned domains, parent companies, firmographic patterns to drop. Replace with the team's actual exclusion list before first run.
## Method
Run these six steps in order. The deterministic firmographic filter MUST run before any LLM scoring — running scoring across the full Clay universe wastes credits and pulls in obvious misfits.
### 1. Load and validate inputs
Read `seed_accounts`, `icp_rubric`, and `exclusion_list`. Drop seed rows with missing `why_we_won` and warn. Refuse to proceed if fewer than 8 valid seed rows remain — the signature extraction is unreliable below that floor.
### 2. Extract the seed signature
Send the validated seeds to Claude with the ICP rubric as context. Ask for a structured signature: industry codes, headcount band, revenue band (if known), geography, funding stage, technographic markers (specific tools), intent markers (hiring patterns, page additions, public announcements), and disqualifiers observed.
Why Claude here, not a SQL query: the `why_we_won` notes encode tacit signals ("they had a security and compliance page" — not a Clay column) that firmographic queries miss.
### 3. Apply deterministic firmographic filter in Clay
Translate the signature's industry, headcount, revenue, geography, and funding gates into Clay filters. Run them first to narrow the universe to ~500-3000 candidates before any LLM cost is spent. Drop anything in `exclusion_list` at this stage.
Why deterministic first, LLM second: a single LLM scoring pass at full Clay universe scale costs roughly 30-100x more than a filter pass, and 80-90% of the rejections are obvious firmographic misfits that need no reasoning.
### 4. Enrich and corroborate intent signals
For each remaining candidate, ask Clay to enrich tech stack, hiring page deltas, and last-90-day announcements. Pass each candidate to Claude with the seed signature and ask for a per-signal match score (0-3) plus a corroborating citation URL.
Constraint: any single intent signal (e.g. "hired a VP of Revenue") requires a primary corroborating signal (LinkedIn job change visible from a second angle, or a press release citing the hire). Single-source intent claims are scored 0 with reason "uncorroborated" rather than guessed. This is the guard against intent-signal noise.
### 5. Rank, dedupe, and batch-write to Clay
Sort by total signal-match score, descending. Dedupe by domain (parent companies via Clay's parent-company column where present — same parent counts once). Write the top `target_list_size` rows to a new Clay table, one batch write at the end rather than per-row.
Why batch + dedupe before write: Clay enrichment is metered per row, and duplicate parent writes burn credits without adding accounts. A single batch write also keeps the table consistent if the run is interrupted.
### 6. Produce the output report
Generate the markdown output (format below). Include a top section that explains the seed signature so the AE/SDR reviewer can sanity-check the shape of the list before working it.
## Output format
Output is a single markdown document, written to disk and surfaced to the caller. Literal example shape:
```markdown
# ICP list — {date}
## Seed signature
- Industry: B2B SaaS — DevTools and Observability (NAICS 5415)
- Headcount: 80-350
- Revenue (where known): $10M-$60M ARR
- Geo: US + Canada, EMEA-EN
- Funding: Series B and C
- Technographic markers: Stripe, Datadog OR New Relic, Notion (corroborator)
- Intent markers: hired VP of Revenue or Head of Sales in last 9 months, or
shipped a new public security/compliance page in last 6 months
- Disqualifiers observed: government contractor, parent in F500
## Ranked candidates (top 100 of 217 scored)
| Rank | Company | Domain | Score | Top signal | Exclusions flagged |
|---|---|---|---|---|---|
| 1 | Acme Observability | acme.io | 14/15 | Hired VP Rev (LinkedIn + Sept 2026 press release) | none |
| 2 | Beacon Logs | beaconlogs.com | 13/15 | Stripe + Datadog + Series B Aug 2026 | none |
| 3 | Ledger Trace | ledgertrace.dev | 12/15 | New SOC 2 page Oct 2026 | EU-only — territory split required |
| ... | ... | ... | ... | ... | ... |
## Signal-type breakdown across the top 100
- Hiring-signal-driven: 38
- Technographic-driven: 29
- Funding/announcement-driven: 22
- Multi-signal (3+): 11
## Exclusion-flag explanations
- 14 candidates flagged "EU-only — territory split required": these passed
ICP but fall outside US/CA territories and should route to the EMEA pod.
- 3 candidates flagged "parent in F500": these were dropped from the ranked
list per `exclusion_list`. Listed for audit only.
- 9 candidates flagged "uncorroborated intent": dropped per Step 4 guard.
## Run metadata
- Seeds used: 14 (2 dropped for missing why_we_won)
- Clay universe after firmographic filter: 1,847
- Candidates scored by Claude: 217
- Final ranked list: 100
- Clay credits consumed: ~870 (enrichment) + 217 (scoring lookups)
```
## Watch-outs
- **Junk firmographic data from public sources.** Aggregator headcount and revenue numbers lag reality by 6-18 months and are wrong by 30-50% on growth-stage companies. Guard: treat any single firmographic source as directional, require headcount or revenue agreement across two independent sources before applying a hard gate, and surface conflicts in the output ("LinkedIn says 120, BuiltWith says 380 — flagged for manual review").
- **Intent-signal noise.** A "hired a VP of Sales" signal scraped from LinkedIn alone misclassifies promotions, contract roles, and job-title inflation as net-new hires. Guard: Step 4 requires a primary corroborating signal (press release, second-angle LinkedIn evidence) before any intent signal scores above 0.
- **List poisoning from outdated databases.** Some Clay enrichment sources carry zombie companies (acquired, merged, defunct) that pass filters but cannot buy. Guard: drop any candidate whose website returns a 4xx/5xx, has no LinkedIn activity in last 90 days, or whose parent-company field resolves to a known acquirer. These are reported in the run metadata, not silently dropped.
- **Seed bias.** A seed list of 10 wins from one AE in one vertical produces a list that looks like that AE's territory, not the company's ICP. Guard: the skill warns if more than 60% of seeds share the same primary AE, vertical, or close-month, and asks the operator to broaden the seed before proceeding.
- **Filter over-fit.** A signature so tight it matches only the 14 seeds produces 0-30 candidates and feels precise but is useless. Guard: if the Clay firmographic-filter step returns fewer than 200 candidates, the skill loosens the headcount and revenue bands by one notch and re-runs rather than proceeding.
- **AE review is non-optional.** Skill output is a ranked draft. The output format is markdown (not a Clay-to-sequence webhook) deliberately to force a human review step before any send.
# ICP rubric — TEMPLATE
> Replace this template's contents with your team's actual ICP rubric
> before the first run of `icp-list-builder`. The skill reads this file to
> set hard firmographic gates and signal-weight ordering. Without your
> real values, the candidate list will be generic.
## Hard firmographic gates
These are AND-gates — a candidate failing any single gate is dropped before any LLM scoring runs. Keep this list short (5-8 dimensions max). Long gate lists shrink the candidate universe below the 200-row floor and force the skill to loosen filters anyway.
| Dimension | In-ICP | Stretch (allowed but downweighted) | Out (dropped pre-scoring) |
|---|---|---|---|
| Industry (NAICS or custom tag) | {list} | {list} | {list} |
| Headcount | {range, e.g. 80-500} | {range, e.g. 50-79 or 501-800} | {below/above} |
| Revenue (where known) | {range} | {range} | {range} |
| Geography | {regions, e.g. US/CA, EMEA-EN} | {regions, e.g. APAC-EN} | {regions, e.g. China, sanctioned countries} |
| Funding stage | {stages, e.g. Series B-D} | {stages, e.g. Series A late or Series E} | {stages, e.g. pre-seed, IPO+} |
| Business model | {e.g. B2B SaaS subscription} | {e.g. usage-based} | {e.g. consulting, services} |
## Technographic signals
Tools that signal a fit (we win when these are present). Each entry should name a specific product, not a category.
- {Tool 1 — e.g. "Stripe (billing) — strong"}
- {Tool 2 — e.g. "Datadog or New Relic — strong"}
- {Tool 3 — e.g. "Notion (corroborator only, not a primary signal)"}
Tools that signal misfit. The skill downweights candidates with these.
- {Tool A — e.g. "Salesforce + manual CPQ — competing internal build"}
- {Tool B — e.g. "Legacy ERP with no API surface"}
## Intent signals
The signals the skill looks for in Step 4. Each must specify the primary source AND the required corroborating source. Single-source intent counts as zero per the skill's guard.
| Signal | Primary source | Required corroborator |
|---|---|---|
| Hired VP Rev / Head of Sales (last 9 months) | LinkedIn job change | Press release, company blog, or 2nd-angle LinkedIn evidence (e.g. announcement post) |
| New compliance page (SOC 2, ISO 27001, HIPAA) | Company website diff | Trust center URL or vendor listing |
| Funding round (Series A+) last 6 months | Crunchbase / company press | TechCrunch, PitchBook, or filed 8-K |
| Active hiring 5+ GTM roles | Public careers page | LinkedIn jobs cross-reference |
## Signal weights
The skill ranks candidates on a 0-15 scale across five signal categories. Set the per-category weights here. Total must equal 15.
- Industry + business-model match: weight {N, e.g. 4}
- Headcount + revenue match: weight {N, e.g. 3}
- Technographic match: weight {N, e.g. 3}
- Intent signal (corroborated): weight {N, e.g. 4}
- Geography + funding stage match: weight {N, e.g. 1}
## Disqualifiers (skill flags prominently if found)
Single signals that drop a candidate regardless of other fit. Keep narrow.
- {Disqualifier 1 — e.g. "Parent company in Fortune 500 (procurement model wrong for our motion)"}
- {Disqualifier 2 — e.g. "Government contractor (compliance posture we cannot meet)"}
- {Disqualifier 3 — e.g. "Active acquisition in last 90 days (buying frozen)"}
## Last edited
{YYYY-MM-DD} — update on every material change so the skill can warn when the rubric is stale (more than 6 months old triggers a stale-rubric notice in the output report).
# Signal source matrix — TEMPLATE
> Replace this template's contents with your team's actual source policy.
> The `icp-list-builder` skill reads this file to decide which public sources
> count as primary vs corroborating, and which to skip entirely.
## Why this file exists
The skill's intent-signal scoring (method Step 4) requires a primary source plus a corroborating source for any signal to count above 0. This matrix is where you encode which source plays which role for your team. Without it the skill defaults to a generic ordering that under-weights signals you trust and over-weights ones you've found unreliable.
## Source roles
For each public source the skill may query, assign one role:
- **primary** — a signal originating here can anchor a score (still needs one corroborator)
- **corroborator** — only counts as the second source confirming a primary signal; cannot anchor on its own
- **skip** — never query this source; results are too noisy or stale to trust
## Source × signal-type matrix
| Source | Firmographic | Technographic | Hiring | Funding | Compliance/security | Notes |
|---|---|---|---|---|---|---|
| Company website (homepage, About, careers, trust center) | corroborator | corroborator | primary | corroborator | primary | Source of truth for own claims; queried first |
| LinkedIn company page | primary | skip | primary | corroborator | skip | Strongest for headcount + role changes; rate-limited |
| LinkedIn jobs | skip | skip | corroborator | skip | skip | Volume signal only; titles are noisy |
| BuiltWith | skip | primary | skip | skip | corroborator | Strong for tech stack, weak for everything else |
| Crunchbase | corroborator | skip | skip | primary | skip | Funding date + amount only; org charts are stale |
| Public press releases (last 90 days) | skip | skip | corroborator | corroborator | corroborator | Date-stamped; cite URL + date |
| TechCrunch / industry press | skip | skip | corroborator | corroborator | skip | Use for funding corroboration |
| G2 / Capterra reviews | skip | corroborator | skip | skip | skip | Reviewer-self-reported; treat as weak signal only |
| Wayback Machine | corroborator | corroborator | corroborator | skip | corroborator | Use to date page additions (compliance pages, jobs page changes) |
| Generic data aggregators (ZoomInfo, Apollo passive scrape) | skip | skip | skip | skip | skip | High noise; use a paid product directly if needed, do not let the skill scrape |
## Sources explicitly disallowed
The skill must never query these. Add domains here as you discover sources that have produced bad data for your team.
- {Domain 1 — e.g. "scraped-data-aggregator-x.example"}
- {Domain 2}
## Refresh windows
How fresh a signal must be to count. Anything older than the window is dropped to corroborator-only or to 0.
| Signal type | Max age to count as primary | Max age to count as corroborator |
|---|---|---|
| Hiring announcement | 9 months | 18 months |
| Funding round | 6 months | 12 months |
| Compliance page addition | 6 months | 24 months |
| Tech-stack signal | 6 months (BuiltWith last-seen) | 12 months |
| Headcount snapshot | 90 days | 12 months |
## Last edited
{YYYY-MM-DD}
# Exclusion criteria — TEMPLATE
> Replace this template's contents with your team's actual exclusion list
> before the first run of `icp-list-builder`. The skill reads this file in
> method Step 1 and Step 3, and refuses to write any matched domain to the
> output Clay table.
## Why this file matters
A list builder that writes existing customers, active opportunities, or known-loss accounts back into outbound is worse than no list — it burns trust with AEs, with the prospect (who gets contacted as a stranger), and with CS (who finds out when the customer escalates). This file is the backstop. The skill treats it as a hard filter, not a downweighting signal.
## Banned domains
Exact-match domains that must never appear in the output. The skill matches on root domain and known parent-company domains.
```
# Existing customers
{customer1.com}
{customer2.com}
# Active opportunities (export from CRM monthly and paste here)
{opp1.com}
{opp2.com}
# Closed-lost in last 6 months (do not re-engage from outbound; route to AE for hand-touch)
{lost1.com}
{lost2.com}
# Do-not-contact requests honored
{dnc1.com}
{dnc2.com}
# Internal / partners / investors (never outbound)
{partner1.com}
{investor1.com}
```
## Banned parent companies
If the skill's enrichment step resolves a candidate to a parent in this list, the candidate is dropped regardless of root-domain match.
- {Parent 1 — e.g. "BigCo Inc — all subsidiaries flagged"}
- {Parent 2}
## Firmographic exclusion patterns
Patterns broader than a single domain. The skill applies these in Step 3 after firmographic enrichment.
- {Pattern 1 — e.g. "Any company tagged as government contractor by NAICS prefix 5417"}
- {Pattern 2 — e.g. "Any company headquartered in {sanctioned-country-list}"}
- {Pattern 3 — e.g. "Any company with active M&A announcement in last 90 days"}
## Audit posture
Excluded candidates are not silently dropped. The skill's run metadata section reports counts per exclusion category. This lets RevOps verify the exclusion file is current and catches the case where the customer list export was forgotten and a customer slipped through.
## Refresh cadence
This file is regenerated from CRM exports on a fixed cadence. Stale exclusion files are the most common source of bad list output.
- Customers: refresh weekly (every Monday)
- Active opportunities: refresh weekly (every Monday)
- Closed-lost: refresh monthly (first of month)
- DNC: refresh on every request received
- Partners / investors: refresh quarterly
## Last refreshed
{YYYY-MM-DD} — exports as of this date. The skill warns in its output report if this date is more than 14 days old.