Lead Signal Scout

O que Lead Signal Scout faz?

Transforme uma URL de produto em uma shortlist onde cada entrada está em uma página que o agente abriu, leu e datou, e pertence a alguém que realmente poderia comprar. Prospects não verificados, desatualizados e não qualificados nunca chegam à shortlist.

Seis barreiras são obrigatórias. Pular uma invalida a execução; diga isso em vez de entregar a saída.

1. Intake (etapa 1) - não pesquise até que o briefing possa rejeitar uma correspondência fraca.
2. Verificação (etapa 4) - não escreva um prospect cuja página não foi obtida.
3. Triagem (etapa 4) - não abandone uma consulta que retornou resultados sem abrir um deles e registrar o porquê.
4. Atualidade (etapa 5) - não coloque em shortlist um sinal sem data ou com data anterior ao corte.
5. Qualificação (etapa 6) - não coloque em shortlist um prospect sem problema próprio evidenciado, sem capacidade de compra, sem rota de contato utilizável, ou sem empresa identificada em modo orientado a empresa.
6. Auditoria (etapa 8) - não apresente resultados até que validate_run.py retorne PASS.

Escreva cada campo em prosa seguindo references/writing-rules.md. Um relatório que parece gerado é ignorado, qualquer que seja a pesquisa por trás dele.

Fluxo de trabalho

1. Intake

Leia references/intake.md. Crie o briefing do produto e pergunte uma vez, em uma única mensagem agrupada, as quatro coisas que uma página de destino não pode dizer: geografia, faixa de preço e movimento de compra, exclusões e quaisquer dados de clientes existentes ou vitórias passadas. Prossiga com suposições rotuladas se o usuário não responder.

Registre icp.price_band_source como user ou assumed. Isso importa: uma faixa que você inventou pode não remover ninguém. Com assumed, não pontue commercial_fit abaixo de 3 por motivo de preço. Um número que ninguém confirmou não tem autoridade para decidir quais empresas reais são descartadas.

Defina max_age_days aqui. O padrão é 120. Use 60 quando os sinais forem postagens de contratação ou buscas de fornecedores, onde um pedido de quatro meses atrás quase sempre está preenchido.

2. Definir modo e profundidade

O modo decide o que é otimizado. A profundidade decide quantos. Eles são independentes.

Modo	Otimiza para	Pesos (dor / adequação / comercial / timing / alcance / evidência)
discovery (padrão)	Dor não atendida, pré-product-market-fit	28 / 22 / 10 / 14 / 13 / 13
pipeline	Fluxo de leads repetível para um negócio em vendas	22 / 20 / 20 / 14 / 12 / 12
design-partners	Pessoas propensas a testar e dar feedback	24 / 18 / 6 / 10 / 24 / 18
b2b	Empresas com um gatilho de negócio atual	14 / 20 / 26 / 18 / 11 / 11
community	Solicitações e discussões públicas explícitas	28 / 18 / 8 / 14 / 22 / 10

Os modos b2b e pipeline também se recusam a colocar em shortlist um prospect cuja empresa não foi identificada.

Profundidade	Limite da shortlist	Consultas mínimas	Páginas abertas mínimas	Cobertura mínima de bucket x família
quick	5	10	12	4 buckets x 3 famílias
standard (padrão)	10	18	20	5 buckets x 4 famílias
deep	20	35	35	7 buckets x 6 famílias

Consultas medem digitação, páginas medem leitura, e apenas uma delas encontra clientes. Registre a contagem em coverage.pages_opened, incluindo páginas que nunca se tornaram candidatas.

Copie o perfil do modo escolhido para o JSON de execução literalmente. O auditor recalcula cada pontuação contra ele e falha se os pesos declarados divergirem do perfil do modo.

3. Planejar e executar a busca

Leia references/search-playbook.md. Escreva o plano de consultas antes de buscar: quais buckets, quais famílias de fontes, quais frases nas próprias palavras do público. Registre cada consulta e sua contagem de resultados, incluindo as de zero resultados. Colete URLs candidatas; não escreva registros de prospect ainda.

4. Verificar antes de escrever

Leia references/verification.md. Obtenha cada URL candidata e então decida:

• signal_confirmed - página obtida, sinal presente nela, atribuível ao prospect nomeado. Apenas este pode ser colocado em shortlist.
• url_ok - obtida, mas o sinal é impreciso, a atribuição é inferida ou a data está faltando. Nível de revisão.
• unverified - não obtida, morta ou com paywall. Adicione a dropped com o motivo e pare. Não escreva o registro.

Escrever um registro completo de prospect e depois descartá-lo porque a página retorna 404 desperdiça a maior parte de uma execução. Obtenha primeiro, escreva depois.

Abra o que você está prestes a abandonar. Qualquer consulta que retornou três ou mais resultados e não manteve nenhum precisa de uma note em sua entrada de cobertura, escrita após abrir um desses resultados. O auditor falha uma execução onde a maioria das consultas abandonadas não tem nota.

Esta é a etapa que decide quem está na shortlist, e é invisível a menos que você a registre. Uma execução que registra 16 consultas e atinge todos os pisos de cobertura ainda pode ter retornado 75 resultados, aberto 10, e obtido toda a sua shortlist de três consultas em formato de anúncio, enquanto uma página de avaliações de concorrentes e três RFPs publicadas ficaram sem leitura. A linha de auditoria chamará isso de cobertura completa. Verifique a rota de contato bem como a fonte; verification.md cobre o que registrar.

Limites de pesquisa: apenas informações profissionais e comerciais públicas; sem burlar logins, paywalls, controles de acesso, limites de taxa ou restrições de robots; sem corretores de dados, conjuntos de dados vazados, grupos privados, descoberta de e-mail pessoal ou enriquecimento de telefone; nunca inferir ou direcionar com base em características protegidas, saúde, dificuldades financeiras, política, religião ou sexualidade.

5. Datas cada sinal

O timing é pontuado a partir da idade, então um sinal sem data não pode ser colocado em shortlist. Percorra esta lista e pare na primeira que der uma resposta: uma data de publicação visível, um carimbo de tempo relativo na página convertido para signal_age_days, ou um carimbo de tempo codificado na URL. Registre qual você usou em date_basis. verification.md fornece o método para cada um.

Nunca estime uma idade. Datas parciais como 2026-08 são rejeitadas, e também datas futuras. Uma entrada de shortlist baseada em uma data adivinhada é exatamente a falha que esta skill existe para prevenir.

Registre fetched_at e final_url para cada prospect confirmado. O auditor não pode ver você obter uma página; estes tornam uma afirmação não suportada mais trabalhosa do que fazê-la corretamente.

6. Pontuar, barrar e desduplicar

Leia references/scoring.md. Pontue seis dimensões de 0 a 5 contra as âncoras escritas. O timing vem da idade, limitada pela faixa; um gatilho atual nomeado aumenta o limite em um.

pain_strength pontua o problema do próprio prospect, no trabalho que o produto faz, nas palavras deles. Um problema que os clientes deles têm, um problema para o qual eles vendem a solução, ou uma tendência de mercado sobre a qual comentaram pontuam todos 0. Toda marca de consumo lança campanhas; isso não é um sinal.

commercial_fit pergunta se este vendedor pode fechar este comprador através do movimento que este vendedor tem. Não se a empresa é grande. Receita na casa dos bilhões, cem países e um portal de fornecedores publicado são evidências de uma fila de compras, e para um vendedor self-service ou liderado pelo fundador isso pontua 2, não 4.

Descarte qualquer coisa abaixo de 50. Encaminhe para o nível de revisão qualquer coisa sem data, mais antiga que max_age_days sem os três campos still_open, pontuando 0 ou 1 em pain_strength sem trigger nomeado, pontuando 0 ou 1 em commercial_fit contra uma faixa fornecida pelo usuário, cuja única rota de contato é inappropriate, ou cuja empresa não foi identificada em modo b2b ou pipeline. Nada é deletado; o nível de revisão mostra cada um com seu motivo.

Registre signal_type e purchase_readiness em vez de um único rótulo de intenção. Alguém contratando um designer tem intenção real e nenhuma intenção de comprar software. Os dois rótulos têm limites vinculados às dimensões subjacentes: hiring não pode exceder adjacent, um sinal baseado em dor precisa de pain_strength de 3 para strong, strong precisa de commercial_fit de 3, e direct precisa de 4. O auditor aplica todos eles, porque campos de texto livre subindo juntos é como um anúncio de lançamento se tornou um comprador de alta intenção.

Uma página anunciando para um freelancer, contratado ou empregado é hiring, por mais exatamente que o trabalho corresponda ao produto. Eles estão selecionando uma pessoa, não um serviço, e hiring limita a prontidão a adjacent. Registrar um anúncio de emprego como direct_request ultrapassa esse limite, que é como um briefing freelancer de quinze dólares por hora já encabeçou uma shortlist. O sinal está no que a rota pede: um portfólio, currículo ou tabela de preços significa contratação; escopo, preço, prazo ou teste significa compra.

Desduplique em dedupe_key. Carregue ledger.json de execuções anteriores no mesmo diretório de saída e exclua o que ele já retornou, além de tudo na lista de exclusão do usuário.

Mantenha a shortlist distribuída entre fontes: não mais da metade de uma família de fontes ou um domínio. Qualquer site que busque mais confiavelmente dominará a execução, e uma shortlist de fonte única herda o viés desse site.

Se mais de 60 por cento da shortlist pontuar 80+, as âncoras foram aplicadas frouxamente. Re-pontue.

7. Registrar quem, onde e como alcançá-los

Separe company, person e handle. A empresa é quem compraria; a pessoa é quem postou; o handle é o nome de usuário da plataforma. Quando nenhuma empresa estiver visível, defina company como not identified e coloque o handle em handle, escrito como a plataforma o escreve (u/name). As saídas lideram com o handle nesse caso. Procure a empresa primeiro: os posters frequentemente a nomeiam no tópico, no perfil ou em um link.

Dê a cada prospect um channel_url: a página que o usuário realmente abre para fazer contato. Frequentemente o tópico fonte, às vezes um formulário de contato ou perfil. Abra-o e registre channel_evidence: uma breve citação ou o cabeçalho na página mostrando para quem a rota é. Um prospect em shortlist reivindicando channel_fit: valid sem isso falha na auditoria.

Portais de registro de fornecedores e vendedores são questionable na melhor das hipóteses, uma fila em vez de uma conversa. Rotas de candidato, imprensa e suporte ao cliente são inappropriate. Quando a primeira rota que você encontra tem a forma errada, gaste mais uma busca procurando a certa antes de descartar o prospect; sites grandes enterram a página de consulta de negócios e classificam a página de carreiras em primeiro lugar.

O auditor lê channel_evidence, não apenas a URL. Um anúncio de emprego no Reddit ou LinkedIn tem uma URL perfeitamente limpa e se revela apenas nas palavras: "compartilhe seu portfólio e currículo atualizado" é uma rota de candidatura onde quer que esteja hospedado.

Deixe additional_source_urls vazio a menos que outra página mostre o mesmo sinal. Ele renderiza como "Também visto em", então colocar a página de contato lá reivindica corroboração que não existe.

Esboce uma abertura por prospect em shortlist, com menos de 90 palavras, fundamentada apenas na página obtida. Não envie, submeta, conecte, siga, comente ou escreva em um CRM a menos que o usuário autorize separadamente em uma etapa posterior.

8. Construir saídas e auditar

Leia references/output-schema.md, escreva run.json, então:

python3 <skill-dir>/scripts/validate_run.py run.json
python3 <skill-dir>/scripts/build_outputs.py run.json outputs/

<skill-dir> é o diretório desta skill, aquele de onde este SKILL.md foi carregado. Construa um caminho absoluto a partir dele. Não use um caminho relativo ao diretório de trabalho: o diretório de trabalho é o projeto do usuário, não a skill. Onde o host substituir ${CLAUDE_SKILL_DIR}, essa variável é exatamente este diretório.

Corrija cada ERROR e re-execute até que imprima PASS. Relate a linha de auditoria literalmente na resposta final. build_outputs.py escreve leads.csv (a lista operacional), leads-full.csv (todos os campos), report.html, brief.md e um ledger.json atualizado. Mantenha run.json ao lado deles como a fonte da verdade.

Sem Python: escreva brief.md e leads.csv manualmente a partir do esquema e faça as verificações do auditor manualmente.

9. Relatar

Retorne a linha de auditoria literalmente em sua resposta e em brief.md. Ela não aparece em report.html em uma execução aprovada, porque uma faixa verde dizendo "ok" não é o que alguém abre um relatório de prospect para ler.

Depois, o veredito, o principal prospect e caminhos absolutos para os artefatos. Lidere com o que está verificado e datado. Torne as lacunas visíveis.

Barra de qualidade

• Um prospect sem fonte obtida não é um prospect. Um sem data não é um lead. Um que não pode comprar é uma entrevista de pesquisa. Um que não declarou problema próprio é um segmento de mercado.
• Resultados retornados e nunca abertos são a saída real da execução. Conte-os e abra aqueles que você estava prestes a pular.
• Uma execução que examinou trinta candidatos e não colocou nenhum em shortlist é um resultado válido. Relate-a claramente em vez de inflar.
• Dez correspondências verificadas e atuais superam cinquenta genéricas.
• Relate o que foi pesquisado e não encontrou nada, não apenas o que foi encontrado.
• Personalize a partir da fonte, nunca da invenção.
• Rotule tudo como uma hipótese. Um sinal público não é consentimento, interesse ou intenção de compra.