karthikselvarjn/lead-signal-scout

Lead Signal Scout

Convierte la URL de un producto en una lista corta donde cada entrada está en una página que el agente abrió, leyó y fechó, y pertenece a alguien que realmente podría comprar. Los prospectos no verificados, desactualizados y no cualificados nunca llegan a la lista corta.

Seis puertas son obligatorias. Omitir una invalida la ejecución; dilo en lugar de enviar la salida.

1. Ingesta (paso 1): no investigues hasta que el resumen pueda rechazar una coincidencia débil.
2. Verificación (paso 4): no redactes un prospecto cuya página no se haya obtenido.
3. Cribado (paso 4): no abandones una consulta que arrojó resultados sin abrir uno de ellos y anotar por qué.
4. Actualidad (paso 5): no incluyas en la lista corta una señal sin fecha o que supere el límite.
5. Cualificación (paso 6): no incluyas en la lista corta un prospecto sin un problema propio probado, sin capacidad de compra, sin una ruta de contacto utilizable o sin una empresa identificada en un modo orientado a empresas.
6. Auditoría (paso 8): no presentes resultados hasta que validate_run.py devuelva PASS.

Redacta cada campo de prosa siguiendo references/writing-rules.md. Un informe que parezca generado será ignorado, sea cual sea la investigación detrás.

Flujo de trabajo

1. Ingesta

Lee references/intake.md. Construye el resumen del producto y luego pregunta una vez, en un único mensaje agrupado, las cuatro cosas que una página de aterrizaje no puede decirte: geografía, banda de precio y dinámica de compra, exclusiones y cualquier dato de clientes existentes o ventas pasadas. Procede con suposiciones etiquetadas si el usuario no responde.

Registra icp.price_band_source como user o assumed. Esto importa: una banda que inventaste no puede eliminar a nadie. Con assumed, no puntúes commercial_fit por debajo de 3 por razones de precio. Un número que nadie confirmó no tiene derecho a decidir qué empresas reales se descartan.

Establece max_age_days aquí. El valor predeterminado es 120. Usa 60 cuando las señales sean publicaciones de contratación o búsquedas de proveedores, donde una solicitud de hace cuatro meses casi siempre está cubierta.

2. Establecer modo y profundidad

El modo decide qué se optimiza. La profundidad decide cuántos. Son independientes.

Modo	Optimiza para	Pesos (dolor / ajuste / comercial / oportunidad / alcance / evidencia)
discovery (predeterminado)	Dolor no cubierto, pre-producto-mercado	28 / 22 / 10 / 14 / 13 / 13
pipeline	Flujo de leads repetible para un negocio en venta	22 / 20 / 20 / 14 / 12 / 12
design-partners	Personas que probablemente probarán y darán retroalimentación	24 / 18 / 6 / 10 / 24 / 18
b2b	Empresas con un desencadenante comercial actual	14 / 20 / 26 / 18 / 11 / 11
community	Solicitudes y discusiones públicas explícitas	28 / 18 / 8 / 14 / 22 / 10

b2b y pipeline también se niegan a incluir en la lista corta un prospecto cuya empresa no esté identificada.

Profundidad	Límite de lista corta	Consultas mínimas	Páginas abiertas mínimas	Cobertura mínima por cubo x familia
quick	5	10	12	4 cubos x 3 familias
standard (predeterminado)	10	18	20	5 cubos x 4 familias
deep	20	35	35	7 cubos x 6 familias

Las consultas miden la escritura, las páginas miden la lectura, y solo una de ellas encuentra clientes. Registra el recuento en coverage.pages_opened, incluyendo las páginas que nunca se convirtieron en candidatos.

Copia el perfil del modo elegido en el JSON de ejecución textualmente. El auditor recalcula cada puntuación contra él y falla si los pesos declarados se desvían del perfil del modo.

3. Planificar y ejecutar la búsqueda

Lee references/search-playbook.md. Escribe el plan de consultas antes de buscar: qué cubos, qué familias de fuentes, qué redacciones en las propias palabras de la audiencia. Registra cada consulta y su recuento de resultados, incluyendo las de cero resultados. Recopila URL candidatas; no escribas registros de prospectos todavía.

4. Verificar antes de escribir

Lee references/verification.md. Obtén cada URL candidata y luego decide:

• signal_confirmed: página obtenida, señal presente en ella, atribuible al prospecto nombrado. Solo esto puede incluirse en la lista corta.
• url_ok: obtenida, pero la señal está condicionada, la atribución es inferida o falta la fecha. Nivel de revisión.
• unverified: no obtenida, muerta o con muro de pago. Añadir a dropped con el motivo y detenerse. No lo redactes.

Escribir un registro completo de prospecto y luego descartarlo porque la página da 404 desperdicia la mayor parte de una ejecución. Obtén primero, escribe después.

Abre lo que estás a punto de abandonar. Cualquier consulta que haya devuelto tres o más resultados y no haya conservado ninguno necesita una note en su entrada de cobertura, escrita después de abrir uno de esos resultados. El auditor falla una ejecución donde la mayoría de las consultas abandonadas no llevan nota.

Este es el paso que decide quién está en la lista corta, y es invisible a menos que lo escribas. Una ejecución que registra 16 consultas y supera todos los mínimos de cobertura puede, sin embargo, haber devuelto 75 resultados, abierto 10 y tomado toda su lista corta de tres consultas con forma de anuncio, mientras que una página de reseñas de competidores y tres RFP publicados quedaron sin leer. La línea de auditoría llamará a eso cobertura completa. Verifica también la ruta de contacto, no solo la fuente; verification.md cubre qué registrar.

Límites de investigación: solo información profesional y empresarial pública; no está permitido eludir inicios de sesión, muros de pago, controles de acceso, límites de velocidad o restricciones de robots; no usar corredores de datos, conjuntos de datos filtrados, grupos privados, descubrimiento de correos electrónicos personales o enriquecimiento de teléfonos; nunca inferir ni apuntar a características protegidas, salud, dificultades financieras, política, religión o sexualidad.

5. Fechar cada señal

La oportunidad se puntúa a partir de la antigüedad, por lo que una señal sin fecha no puede incluirse en la lista corta. Recorre esta lista y detente en la primera que dé una respuesta: una fecha de publicación visible, una marca de tiempo relativa en la página convertida a signal_age_days, o una marca de tiempo codificada en la URL. Registra cuál usaste en date_basis. verification.md proporciona el método para cada una.

Nunca estimes una antigüedad. Las fechas parciales como 2026-08 se rechazan, y también las fechas futuras. Una entrada de lista corta que se basa en una fecha adivinada es el fallo exacto que esta habilidad existe para prevenir.

Registra fetched_at y final_url para cada prospecto confirmado. El auditor no puede verte obtener una página; esto hace que una afirmación sin respaldo requiera más trabajo que hacerlo correctamente.

6. Puntuar, filtrar y deduplicar

Lee references/scoring.md. Puntúa seis dimensiones del 0 al 5 contra los anclajes escritos. La oportunidad proviene de la antigüedad, limitada por banda; un desencadenante actual nombrado aumenta el límite en uno.

pain_strength puntúa el problema propio del prospecto, en el trabajo que hace el producto, en sus propias palabras. Un problema que tienen sus clientes, un problema para el que venden la solución, o una tendencia del mercado que comentaron, todo puntúa 0. Toda marca de consumo lanza campañas; eso no es una señal.

commercial_fit pregunta si este vendedor puede cerrar a este comprador a través de la dinámica que tiene este vendedor. No si la empresa es grande. Ingresos en miles de millones, cien países y un portal de proveedores publicado son evidencia de una cola de adquisiciones, y para un vendedor de autoservicio o fundador eso puntúa 2, no 4.

Descarta todo lo que esté por debajo de 50. Envía al nivel de revisión cualquier cosa sin fecha, más antigua que max_age_days sin los tres campos still_open, que puntúe 0 o 1 en pain_strength sin un trigger nombrado, que puntúe 0 o 1 en commercial_fit contra una banda proporcionada por el usuario, cuya única ruta de contacto sea inappropriate o cuya empresa no esté identificada en modo b2b o pipeline. Nada se elimina; el nivel de revisión muestra cada uno con su motivo.

Registra signal_type y purchase_readiness en lugar de una única etiqueta de intención. Alguien que contrata a un diseñador tiene intención real y ninguna intención de comprar software. Las dos etiquetas tienen límites vinculados a las dimensiones subyacentes: hiring no puede exceder adjacent, una señal basada en dolor necesita pain_strength de 3 para strong, strong necesita commercial_fit de 3, y direct necesita 4. El auditor las aplica todas, porque los campos de texto libre que se desplazan hacia arriba juntos es cómo un anuncio de lanzamiento se convirtió en un comprador de alta intención.

Una página que anuncia un freelancer, contratista o empleado es hiring, por muy exactamente que el trabajo coincida con el producto. Están seleccionando a una persona, no un servicio, y hiring limita la preparación a adjacent. Archivar un anuncio de trabajo como direct_request pasa por alto ese límite, que es cómo un encargo freelance de quince dólares la hora llegó una vez a la cima de una lista corta. La pista está en lo que pide la ruta: un portafolio, CV, currículum o tarifario significa contratación; alcance, precio, plazo o una prueba significa compra.

Deduplica en dedupe_key. Carga ledger.json de ejecuciones anteriores en el mismo directorio de salida y excluye lo que ya haya aparecido, además de todo lo que esté en la lista de exclusión del usuario.

Mantén la lista corta distribuida entre fuentes: no más de la mitad de una familia de fuentes o un dominio. El sitio que se obtiene de forma más fiable terminará dominando la ejecución, y una lista corta de una sola fuente hereda el sesgo de ese sitio.

Si más del 60 por ciento de la lista corta puntúa 80+, los anclajes se aplicaron de forma laxa. Vuelve a puntuar.

7. Registrar quién, dónde y cómo contactarlos

Separa company, person y handle. La empresa es quien compraría; la persona es quien publicó; el handle es su nombre de usuario en la plataforma. Cuando no se vea ninguna empresa, establece company a not identified y pon el handle en handle, escrito como lo escribe la plataforma (u/nombre). Las salidas comienzan con el handle en ese caso. Busca la empresa primero: los carteles a menudo la nombran en el hilo, su perfil o un enlace.

Proporciona a cada prospecto un channel_url: la página que el usuario realmente abre para contactar. A menudo el hilo fuente, a veces un formulario de contacto o perfil. Ábrelo y registra channel_evidence: una cita corta o el encabezado de la página que muestre para quién es la ruta. Un prospecto de la lista corta que afirma channel_fit: valid sin esto falla la auditoría.

Los portales de registro de proveedores y vendedores son questionable en el mejor de los casos, una cola más que una conversación. Las rutas de solicitante, prensa y atención al cliente son inappropriate. Cuando la primera ruta que encuentres tenga la forma incorrecta, dedica una obtención más a buscar la correcta antes de descartar al prospecto; los sitios grandes entierran la página de consulta empresarial y clasifican la página de carreras.

El auditor lee channel_evidence, no solo la URL. Un anuncio de trabajo en Reddit o LinkedIn tiene una URL perfectamente limpia y se delata solo en las palabras: "comparte tu portafolio y currículum actualizado" es una ruta de solicitud esté donde esté.

Deja additional_source_urls vacío a menos que otra página muestre la misma señal. Se renderiza como "También visto en", por lo que poner la página de contacto allí afirma una corroboración que no existe.

Redacta un mensaje de apertura por prospecto de la lista corta, de menos de 90 palabras, basado únicamente en la página obtenida. No envíes, envíes, conectes, sigas, comentes ni escribas a un CRM a menos que el usuario lo autorice por separado en un turno posterior.

8. Construir salidas y auditar

Lee references/output-schema.md, escribe run.json, luego:

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

<dir-habilidad> es el propio directorio de esta habilidad, del que se cargó este SKILL.md. Construye una ruta absoluta a partir de él. No uses una ruta relativa al directorio de trabajo: el directorio de trabajo es el proyecto del usuario, no la habilidad. Cuando el anfitrión sustituya ${CLAUDE_SKILL_DIR}, esa variable es exactamente este directorio.

Corrige cada ERROR y vuelve a ejecutar hasta que imprima PASS. Informa la línea de auditoría textualmente en la respuesta final. build_outputs.py escribe leads.csv (la lista operativa), leads-full.csv (todos los campos), report.html, brief.md y un ledger.json actualizado. Mantén run.json junto a ellos como la fuente de verdad.

Sin Python: escribe brief.md y leads.csv manualmente a partir del esquema y realiza las comprobaciones del auditor manualmente.

9. Informar

Devuelve la línea de auditoría textualmente en tu respuesta y en brief.md. No aparece en report.html en una ejecución exitosa, porque un banner verde que dice "bien" no es lo que alguien abre un informe de prospectos para leer.

Luego el veredicto, el prospecto principal y las rutas absolutas a los artefactos. Lidera con lo que está verificado y fechado. Haz visibles las brechas.

Nivel de calidad

• Un prospecto sin fuente obtenida no es un prospecto. Uno sin fecha no es un lead. Uno que no puede comprar es una entrevista de investigación. Uno que no ha manifestado ningún problema propio es un segmento de mercado.
• Los resultados obtenidos y nunca abiertos son la salida real de la ejecución. Cuéntalos y abre los que estabas a punto de saltarte.
• Una ejecución que examinó treinta candidatos y no incluyó ninguno en la lista corta es un resultado válido. Infórmalo claramente en lugar de rellenar.
• Diez coincidencias verificadas y actuales superan a cincuenta genéricas.
• Informa lo que se buscó y no se encontró, no solo lo que se encontró.
• Personaliza desde la fuente, nunca desde la invención.
• Etiqueta todo como una hipótesis. Una señal pública no es consentimiento, interés ni intención de compra.