A maioria dos exercícios de ICP deriva em sopa de adjetivos — “SaaS mid-market em fintech, mentalidade de crescimento, security-aware.” Listas construídas a partir desse tipo de brief ficam aquém (filtros muito apertados, você consegue 30 contas óbvias que todo mundo já tem) ou passam da conta (filtros muito frouxos, você consegue 4.000 logos e os AEs ignoram o arquivo). O bundle que esta página disponibiliza faz a inversão: em vez de descrever o ICP, você aponta dez a vinte contas closed-won e deixa o Claude fazer engenharia reversa do que elas têm em comum, depois você deixa o Clay traduzir essa assinatura em filtros e enriquecimento.
O artefato é uma Claude Skill — icp-list-builder — que executa o loop semente-para-lista de ponta a ponta e grava um rascunho classificado em uma tabela Clay. Ela é projetada para entregar a um revisor um relatório markdown e uma tabela Clay lado a lado, não para empurrar direto para outbound.
Quando usar
Use esta skill quando conseguir nomear 10-20 contas closed-won que compartilham um formato reconhecível, e você quer que os próximos 100-500 candidatos se pareçam com elas. Os triggers mais comuns na prática:
Refresh trimestral de território — AEs precisam de uma lista rascunho por região, recentemente pontuada contra sinais públicos atuais
Um novo produto de wedge ou novo tier de preços é lançado e a semente de “pessoas que disseram sim” é pequena mas real
Um programa outbound trabalhou o ICP óbvio e a equipe precisa de uma segunda onda informada pelo que fechou, não pelo que o fundador originalmente imaginou que o ICP seria
A skill assume uma conta Clay no plano Pro ou superior. Abaixo do Pro, a superfície de enriquecimento é muito estreita para o loop de lookalike ser útil, e você acabará pagando por um workflow que faz aproximadamente o que uma planilha mais pesquisa no LinkedIn faria.
Quando NÃO usar
ABM de contas nomeadas Tier-1. Listas construídas à mão para 25-50 contas estratégicas envolvem input de customer-success e executivos que a skill não consegue modelar. Use isso para outbound Tier-2 e Tier-3; a variância no loop de lookalike é alta demais para seleção Tier-1.
Auto-carregamento em sequências outbound. O output é um rascunho classificado. A skill grava em uma tabela Clay e produz um relatório markdown deliberadamente para que um AE ou SDR tenha que olhar antes de qualquer envio. Se você conectar o output a um trigger de sequência, está usando isso errado.
Re-pontuação de contas já no seu CRM. Use uma ferramenta de intenção nativa do CRM para isso. Esta skill escreve candidatos net-new; ela não re-classifica os conhecidos.
Pontuação em proxies de classe protegida. Gênero do fundador, etnia do fundador, alma mater, origem do nome — nenhum desses pertence ao rubric. O arquivo de rubric de referência enumera quais dimensões são permitidas; não adicione outras.
Listas semente com menos de oito contas. A skill recusa continuar abaixo de oito sementes válidas porque a extração de assinatura é não confiável em uma base menor. Se você só tem cinco vitórias, construa a lista manualmente e volte quando tiver mais.
Configuração
O bundle está em apps/web/public/artifacts/icp-account-list-builder-clay/ e contém:
SKILL.md — a definição da Claude Skill que orquestra o loop
references/1-icp-rubric-template.md — os gates firmográficos e pesos de sinal que você preenche para a sua equipe
references/2-signal-source-matrix.md — quais fontes públicas contam como primárias vs corroborativas, e quais são explicitamente proibidas
references/3-exclusion-criteria.md — domínios banidos, empresas-mãe e padrões firmográficos que nunca devem aparecer no output
A configuração leva aproximadamente 45 minutos na primeira vez e 5 minutos em cada refresh.
Instale a Skill. Coloque SKILL.md no seu diretório de Skills do Claude (ou carregue via Claude Code com /skill load). Preencha references/1-icp-rubric-template.md com seus gates firmográficos reais, sinais tecnográficos e pesos de sinal. Preencha references/3-exclusion-criteria.md a partir de um export fresco do CRM de clientes, oportunidades ativas e contas closed-lost dos últimos 180 dias.
Prepare a lista semente. Um CSV com company_name, domain e why_we_won (duas frases). Extraia sementes de vários AEs, segmentos e meses de fechamento — a skill avisa se mais de 60% das sementes compartilham um único AE, vertical ou mês de fechamento, porque isso produz uma lista que parece com o território de um rep.
Conecte o Clay. A skill lê seu workspace Clay via API. Defina o ID do workspace e a chave API na configuração local da Skill (nunca faça commit desses no bundle).
Primeira execução. Invoque a skill com seu CSV semente e um target_list_size de 100. A primeira execução é mais lenta porque o universo firmográfico não está filtrado; execuções subsequentes contra uma view Clay salva são mais rápidas.
Revise o relatório markdown e a tabela Clay juntos. O relatório explica a assinatura semente, o breakdown por tipo de sinal e as contagens de flags de exclusão. A tabela Clay é a superfície de trabalho para o AE.
O que a skill realmente faz
Seis passos, em ordem. A ordem importa — executar pontuação LLM antes do filtro firmográfico desperdiça créditos e traz misfits óbvios.
Carrega e valida os inputs. Descarta sementes com why_we_won faltando e recusa executar abaixo de oito sementes válidas.
Extrai a assinatura semente. Envia as sementes e o rubric de ICP ao Claude, que retorna uma assinatura estruturada: códigos de setor, faixa de headcount, faixa de receita, geografia, estágio de financiamento, marcadores tecnográficos e marcadores de intenção. As notas why_we_won codificam sinais que não são colunas do Clay (“eles tinham uma página de segurança e conformidade”); por isso um passo com LLM é necessário antes do filtro determinístico.
Aplica filtro firmográfico determinístico no Clay. Traduz os gates rígidos da assinatura em filtros Clay e os executa primeiro para estreitar o universo para aproximadamente 500-3.000 candidatos. Descarta qualquer coisa na lista de exclusão neste estágio. Fazer isso antes da pontuação corta o custo LLM em aproximadamente 30-100x porque a maioria das rejeições são misfits firmográficos óbvios que não precisam de raciocínio.
Enriquece e corrobora sinais de intenção. Para cada candidato restante, pede ao Clay para enriquecer tech stack, deltas de contratação e anúncios dos últimos 90 dias, depois pede ao Claude pontuações de match por sinal com citações. Qualquer sinal de intenção único requer um sinal primário corroborativo — uma mudança de emprego no LinkedIn mais um press release, por exemplo. Afirmações de intenção de fonte única recebem pontuação 0 com razão “não corroborado” em vez de serem adivinhadas.
Classifica, deduplica e grava em lote no Clay. Ordena por pontuação total, deduplica na coluna de empresa-mãe e grava as target_list_size primeiras linhas em uma nova tabela Clay em um único lote. Gravações por linha queimam créditos e deixam estado inconsistente em caso de interrupção; gravações em lote não.
Produz o relatório de output. Um documento markdown com a assinatura semente no topo, a tabela de candidatos classificados, um breakdown por tipo de sinal, contagens de flags de exclusão e metadados da execução. O revisor lê isso antes de trabalhar a tabela Clay.
Realidade de custos
As grandes alavancas de custo são créditos de enriquecimento do Clay e tokens do Claude. Orçamentos aproximados por execução, ancorados em um target_list_size de 100 contra um universo firmograficamente filtrado de 1.800-2.200 candidatos:
Tokens Claude (extração de assinatura + pontuação por candidato). Aproximadamente 500K-700K tokens de input e 80K-120K tokens de output por execução no Claude Opus. Pelo preço de lista do Opus 4.7 isso fica em torno de US$9-14 por execução. No Claude Sonnet, o mesmo loop fica em torno de US$1,50-2,50 por execução com perda de qualidade mensurável no passo de extração de assinatura (o raciocínio de padrão de semente se beneficia do modelo maior). Recomendação: Opus no passo de assinatura, Sonnet no passo de pontuação por candidato.
Créditos Clay. Aproximadamente 800-1.000 créditos de enriquecimento por execução para um output de 100 linhas, assumindo 2.000 candidatos entrando no passo de enriquecimento. Pelo preço Pro do Clay isso é cerca de US$24-30 em custo de crédito por execução; no tier Explorer os créditos são mais apertados e você deve reduzir o target_list_size para 50 ou pré-filtrar mais.
Em escala. Uma equipe executando isso semanalmente por região (digamos, quatro pods de AE) fica em aproximadamente US$1.300-2.000 por mês combinados (US$150-200 de Claude, o restante de créditos Clay). Isso está bem abaixo do custo de um único assento do ZoomInfo SalesOS e produz uma lista mais atualizada, mas requer que o rubric e o arquivo de exclusão sejam mantidos atualizados — inputs desatualizados são onde o custo vai errado (você paga por créditos para enriquecer contas que nunca deveriam ter passado pelo Passo 1).
O padrão dominante de explosão de custo é chamar a skill repetidamente com um gate firmográfico frouxo e ver o universo de candidatos expandir. A proteção está no Passo 3: se o Clay retornar mais de 5.000 candidatos, a skill aperta uma faixa e re-executa em vez de enriquecer todo o conjunto.
Métrica de sucesso
A métrica a observar é a taxa com que os AEs aceitam a lista rascunho no seu conjunto de trabalho sem retrabalho manual. Meta: 70%+ aceitas (ou seja, de 100 candidatos classificados, pelo menos 70 entram na fila outbound de alguém sem serem deletados ou relabeled). Abaixo de 50% de aceitação, o rubric está errado, a lista semente está enviesada ou o arquivo de exclusão está desatualizado — diagnostique nessa ordem.
Secundário: taxa de reunião agendada nas contas aceitas comparada com a linha de base de lista outbound da equipe. A skill está ganhando o seu custo de crédito quando essa taxa é pelo menos igual à linha de base; o valor agregado é a redução no tempo de construção de lista, não necessariamente um lift imediato de conversão.
vs alternativas
vs LinkedIn Sales Navigator + filtragem manual. Sales Nav é a ferramenta certa para listas Tier-1 construídas à mão e para prospecção individual em um candidato. É a ferramenta errada para produzir 100 lookalikes classificados semanalmente — os filtros de busca salva não capturam sinais de intenção, e o tempo de filtragem manual por lista é aproximadamente 3-5 horas por semana de um SDR. Esta skill substitui essas 3-5 horas por uma revisão de 5 minutos de um rascunho classificado.
vs ZoomInfo SalesOS Intent. SalesOS é maduro, tem bons dados de intenção em contas enterprise e é a resposta certa se você tem um motion enterprise e orçamento para US$35K-80K por ano de assentos. Para um motion mid-market em uma equipe menor, esta skill mais Clay Pro é aproximadamente 80% do sinal a 5-10% do custo, com o trade-off de que você é dono do rubric e da lista de exclusão em vez de depender da pontuação de um fornecedor.
vs Apollo Living Data. O feature de lookalike do Apollo é o mais próximo em forma desta skill e é um clique em vez de uma configuração de 45 minutos. A pontuação de lookalike do Apollo é opaca (você não consegue ver os pesos de sinal nem sobrescrevê-los) e os outputs tendem a ponderar demais a similaridade firmográfica. Esta skill torna o rubric e os pesos inspecionáveis e força corroboração por sinal; o custo é o tempo de configuração e o requisito de manter os arquivos de referência atualizados.
vs nada (status quo, AE constrói a lista). Listas construídas por AE são abrangentes nas contas conhecidas do AE e fracas nos lookalikes que o AE não ouviu falar. Esta skill é o oposto — é ruim em contas estratégicas nomeadas e boa em surfacear os próximos 100 lookalikes. O padrão honesto é executar ambos em paralelo: AE é dono da lista nomeada, a skill produz o rascunho de lookalike.
Pontos de atenção
Dados firmográficos ruins de fontes públicas. Os números de headcount e receita dos agregadores atrasam a realidade em 6-18 meses e estão errados em 30-50% para empresas em estágio de crescimento. Proteção: a skill trata qualquer fonte firmográfica única como direcional e requer concordância entre duas fontes independentes antes de aplicar um gate rígido. Conflitos aparecem no relatório de output (“LinkedIn diz 120, BuiltWith diz 380 — sinalizado para revisão manual”) em vez de serem resolvidos silenciosamente.
Ruído de sinal de intenção. Um sinal de “contratou um VP de Vendas” extraído apenas do LinkedIn classifica erroneamente promoções, funções contratuais e inflação de título como novas contratações líquidas. Proteção: o Passo 4 requer um sinal primário corroborativo (press release, evidência do LinkedIn de segundo ângulo) antes que qualquer sinal de intenção pontue acima de 0; afirmações não corroboradas recebem pontuação 0 com a razão registrada para auditoria.
Envenenamento de lista por bancos de dados desatualizados. Algumas fontes de enriquecimento do Clay carregam empresas zumbis — adquiridas, fundidas ou extintas — que passam nos filtros mas não conseguem comprar. Proteção: descarte qualquer candidato cujo site retorna 4xx/5xx na verificação da página inicial, não tem atividade no LinkedIn nos últimos 90 dias ou cujo campo de empresa-mãe resolve para um adquirente conhecido no arquivo de exclusão. A contagem de descartes aparece nos metadados da execução para que o operador possa detectar um pico (sinal de que o arquivo de exclusão ou a fonte do agregador está degradando).
Viés de semente. Uma lista semente de 10 vitórias de um único AE em um único vertical produz uma lista que parece com o território desse AE. Proteção: a skill avisa se mais de 60% das sementes compartilham o mesmo AE, vertical ou mês de fechamento, e pede ao operador para ampliar a semente antes de continuar.
Overfit de filtro. Uma assinatura tão apertada que só corresponde às 14 sementes produz 0-30 candidatos e parece precisa mas é inútil. Proteção: se o Passo 3 retornar menos de 200 candidatos, a skill afrouxa as faixas de headcount e receita em uma nota e re-executa em vez de prosseguir com um universo faminto.
Arquivo de exclusão desatualizado. Se o export da lista de clientes tem dois meses, um cliente pode passar e acabar em outbound. Proteção: a skill avisa no relatório de output quando last_refreshed no arquivo de exclusão tem mais de 14 dias.
Stack
Clay (Pro ou superior) — substrato de enriquecimento, filtro firmográfico e tabela de destino. Pro é o piso prático para o loop de lookalike.
Claude (Opus 4.7 para extração de assinatura, Sonnet para pontuação por candidato) — raciocínio de assinatura sobre as notas why_we_won das sementes e pontuação de corroboração por sinal com citações. Dividir a seleção de modelo entre os dois passos é onde o trade de custo-qualidade fica melhor.
CRM (qualquer um) — fonte da lista semente, lista de clientes, lista de oportunidades e lista de closed-lost que alimenta o arquivo de exclusão. A skill não lê o CRM diretamente; o operador exporta CSVs.
Destino outbound (Outreach, Salesloft, Apollo, personalizado) — para onde a lista revisada vai depois da aceitação do AE. A skill para na tabela Clay por design.
---
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.