Publicación de Empleo de LinkedIn a Mapa de Dolor del Comprador
Toma publicaciones de empleo de LinkedIn. Decodifícalas en un mapa estructurado de dolor del comprador con puntuaciones, dolores y ángulos de alcance.
Regla crítica: Cada dolor inferido debe citar lenguaje específico de la descripción del trabajo que lo respalde. Nunca inventes dolores que no estén fundamentados en el texto. Si una publicación es demasiado genérica para inferir dolor, dila explícitamente y asigna una puntuación de intensidad de señal baja.
Regla ética: No infieras atributos personales o características protegidas sobre los candidatos. Enfócate estrictamente en el dolor operativo a nivel de empresa y las necesidades organizacionales.
Paso 1: Verificación de Configuración
Confirma que las variables de entorno requeridas existen:
echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"
Si GEMINI_API_KEY falta: Detente. Dile al usuario: "Se requiere GEMINI_API_KEY. Obténla en aistudio.google.com. Agrégala a tu archivo .env."
Paso 2: Recopilar Entradas
La habilidad necesita 3 entradas requeridas. Recógelas antes de continuar.
2a: Resumen del Producto
Pregunta: "Describe tu producto en 2-5 oraciones. ¿Qué haces, cuál es tu propuesta de valor principal y a quién te diriges?"
Si el usuario ya incluyó esto en su mensaje: Extráelo. Confirma: "Resumen del producto capturado: [resumen]."
2b: Descripción del ICP
Pregunta: "Describe tu perfil de cliente ideal en 2-6 viñetas: industrias, tamaños de empresa, roles a los que vendes, pistas sobre el stack tecnológico."
Si el usuario ya incluyó esto en su mensaje: Extráelo. Confirma: "ICP capturado: [resumen]."
2c: Publicaciones de Empleo
Pregunta: "Pega las descripciones de trabajo que deseas analizar. Para cada publicación, incluye el nombre de la empresa, el título del puesto y el texto completo de la descripción. Puedes pegar de 1 a 15 publicaciones."
Formatos aceptados:
- Texto pegado sin procesar con el nombre de la empresa y el título del trabajo claramente etiquetados
- Objetos JSON estructurados con campos:
company_name,job_title,location(opcional),seniority(opcional),team_or_function(opcional),job_description_text,job_url(opcional) - Varias publicaciones separadas por delimitadores claros (--- o numerados)
Si falta algún campo: Infiere lo que puedas del texto de la descripción. Si faltan company_name o job_description_text, pídelos antes de continuar.
2d: Entradas Opcionales
Si el usuario proporciona alguna de estas, captúralas:
account_notes: contexto adicional por empresa (financiamiento, stack tecnológico, herramientas conocidas, contactos)focus_dimension: "pipeline" (sesgo hacia la puntuación y priorización), "positioning" (sesgo hacia ángulos de mensajería) o "both" (predeterminado)
Paso 3: Extraer Señales
Para cada publicación de empleo, analiza y extrae:
- Equipo / función: ¿En qué equipo está este rol? (GTM, Producto, Infraestructura, Datos, RevOps, CS, Ingeniería, etc.)
- Seniority: IC, Senior IC, Gerente, Director, VP, C-level
- Énfasis de responsabilidades: Clasifica el modo dominante:
- Apagar incendios: "estabilizar", "arreglar", "reducir tiempo de inactividad", "desbloquear"
- Construir nuevo: "construir desde cero", "0→1", "greenfield", "diseñar e implementar"
- Optimizar: "escalar", "optimizar", "mejorar eficiencia", "automatizar"
- Reemplazar: "reemplazar legado", "migrar desde", "modernizar"
- Lenguaje de requisitos: Nota palabras clave que indican intención: "primera contratación X", "rol crítico", "inmediato", "debe tener"
- Pistas de herramientas / stack: Cualquier referencia a herramientas específicas, plataformas o categorías tecnológicas que se superpongan con el área del producto del usuario
Agrupa por empresa. Si varias publicaciones provienen de la misma empresa, agrupa sus señales juntas.
Declara: "Señales extraídas de X publicaciones en Y empresas."
Paso 4: Puntuación con el LLM
Lee references/scoring-rubric.md para el modelo de puntuación completo.
Construye la solicitud LLM:
cat > /tmp/pain-map-score-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Eres un analista de GTM que se especializa en decodificar señales de contratación en intención de compra. Para cada cuenta proporcionada, puntuarás tres dimensiones e inferirás el contexto de la empresa. Reglas: (1) Cada puntuación debe incluir una explicación de una oración en texto plano. (2) signal_strength mide cuántas y qué tan específicas son las señales de contratación en relación con el área del producto del usuario. (3) urgency mide qué tan urgente parece la necesidad de contratación. (4) icp_fit mide qué tan cerca coincide la empresa con la descripción del ICP del usuario. (5) Cada puntuación es de 1 a 10. (6) overall_score = round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10). (7) Infiere buy_vs_build del lenguaje del trabajo. Usa EXACTAMENTE una de estas etiquetas: 'Leaning build', 'Leaning buy', 'Hybrid (buy-and-build)', 'Unknown'. (8) Infiere stage_guess a partir de pistas de la empresa: etapa de financiamiento, número de empleados, tipo de empresa. (9) Genera solo JSON válido."
}]
},
"contents": [{
"parts": [{
"text": "SCORING_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.2,
"maxOutputTokens": 4096
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-score-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Reemplaza SCORING_CONTEXT_HERE con:
- El resumen del producto y la descripción del ICP del Paso 2
- Las señales extraídas por empresa del Paso 3
- Las reglas de la rúbrica de puntuación de
references/scoring-rubric.md - Instrucciones para generar JSON con:
company_name,headline,overall_score,score_breakdown(signal_strength, urgency, icp_fit — cada uno con puntuación y explicación),stage_guess,buy_vs_build_guess
Paso 5: Construir Mapa de Dolor
Para cada cuenta, usa las señales extraídas y el contexto de puntuación del LLM para construir el mapa de dolor del comprador.
cat > /tmp/pain-map-analysis-request.json << 'ENDJSON'
{
"system_instruction": {
"parts": [{
"text": "Eres un analista de dolor B2B que lee descripciones de trabajo e identifica los dolores operativos que está experimentando una empresa. Reglas: (1) Cada dolor debe tener una etiqueta corta, una descripción de 1-3 oraciones y frases específicas citadas de la publicación de empleo como evidencia de respaldo. (2) Clasifica los dolores como primarios (directamente relevantes para el producto del usuario) o secundarios (dolor real pero tangencial al producto). (3) Si una publicación es demasiado genérica para inferir dolor específico, indícalo explícitamente — no inventes. (4) Para cada cuenta, genera también 1-3 ángulos de alcance recomendados. Cada ángulo tiene: angle_name (corto), narrative (1-2 oraciones sobre cómo liderar) y talk_track_bullets (2-4 puntos de conversación concretos). (5) Los ángulos de alcance deben hacer referencia a dolores y evidencia específicos, no a propuestas de valor genéricas. Sin palabras prohibidas: sinergia, apalancamiento, innovador, de punta, mejor-en-su-clase, clase mundial, transformador, disruptivo, sin fisuras, robusto, integral, revolucionar, transformar, optimizar. (6) Genera solo JSON válido."
}]
},
"contents": [{
"parts": [{
"text": "ANALYSIS_CONTEXT_HERE"
}]
}],
"generationConfig": {
"temperature": 0.4,
"maxOutputTokens": 8192
}
}
ENDJSON
curl -s -X POST \
"https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d @/tmp/pain-map-analysis-request.json \
| python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"
Reemplaza ANALYSIS_CONTEXT_HERE con:
- El resumen del producto y la descripción del ICP
- Las publicaciones de empleo de cada empresa (texto completo)
- Las puntuaciones y el contexto del Paso 4
- Notas de la cuenta si se proporcionaron
- La preferencia de focus_dimension (pipeline / positioning / both)
- Instrucciones para generar por cuenta:
buyer_pain_map(primary_pains, secondary_pains) yrecommended_outreach_angles
Lee references/examples.md para calibrar la calidad y profundidad esperadas del resultado.
Paso 6: Construir Objeto de Transferencia
Para cada cuenta, genera un bloque de transferencia estructurado que outreach-sequence-builder pueda consumir directamente:
handoff:
for_outreach_sequence_builder:
account_summary: Resumen de 2-3 oraciones de la situación de la empresa y el contexto de contratación
key_pain: El dolor más procesable en una oración
suggested_personas: 2-4 títulos de trabajo de las personas con más probabilidades de ser dueñas de este dolor
tone: Una oración que describe el tono de alcance recomendado
La transferencia debe ser lo suficientemente concreta como para que alguien pueda pegarla en el mensaje de outreach-sequence-builder y obtener una secuencia utilizable sin tener que investigar la cuenta nuevamente.
Paso 7: Autoverificación
Ejecuta cada verificación y corrige las violaciones antes de presentar:
- Cada dolor inferido cita al menos una frase específica de la descripción del trabajo
- No se inventaron dolores para publicaciones genéricas/de baja señal (verifica publicaciones con signal_strength ≤ 3)
- Las tres puntuaciones (signal_strength, urgency, icp_fit) tienen una explicación de una oración
- La puntuación general coincide con la fórmula:
round((0.4 × signal + 0.3 × urgency + 0.3 × icp_fit) × 10) - La etiqueta de compra-vs-construcción es una de: "Leaning build", "Leaning buy", "Hybrid (buy-and-build)", "Unknown"
- Sin palabras prohibidas en los ángulos de alcance: sinergia, apalancamiento, innovador, de punta, mejor-en-su-clase, clase mundial, transformador, disruptivo, sin fisuras, robusto, integral, revolucionar, transformar, optimizar
- Cada ángulo de alcance tiene 2-4 puntos de conversación, no declaraciones de valor genéricas
- Las cuentas fuera del ICP están marcadas con una recomendación clara para despriorizar
- Los objetos de transferencia están completos con los 4 campos (account_summary, key_pain, suggested_personas, tone)
- No se infirieron atributos personales o características protegidas sobre los candidatos
- Las publicaciones están agrupadas por empresa cuando varias publicaciones provienen de la misma empresa
Corrige cualquier violación antes de presentar.
Paso 8: Salida y Guardado
Salida legible para humanos
Presenta el análisis completo en este formato:
## Mapa de Dolor del Comprador — [YYYY-MM-DD]
**Producto:** [nombre del producto del resumen]
**Publicaciones analizadas:** X publicaciones en Y empresas
**Enfoque:** [pipeline / positioning / both]
---
### [Nombre de la Empresa] — Puntuación: [N]/100
**Titular:** [resumen de una línea de lo que revela la contratación]
| Dimensión | Puntuación | Explicación |
|-----------|-------|-------------|
| Intensidad de Señal | N/10 | [una oración] |
| Urgencia | N/10 | [una oración] |
| Ajuste ICP | N/10 | [una oración] |
**Etapa:** [etapa inferida] | **Compra-vs-Construcción:** [etiqueta de postura]
#### Dolores Primarios
- **[Etiqueta del dolor]:** [descripción de 1-3 oraciones]
- Evidencia: "[frase citada de la publicación de empleo]"
#### Dolores Secundarios
- **[Etiqueta del dolor]:** [descripción de 1-3 oraciones]
- Evidencia: "[frase citada de la publicación de empleo]"
#### Ángulos de Alcance Recomendados
1. **[Nombre del ángulo]:** [narrativa]
- [punto 1]
- [punto 2]
- [punto 3]
#### Transferencia → outreach-sequence-builder
> **Resumen:** [2-3 oraciones]
> **Dolor clave:** [una oración]
> **Personas sugeridas:** [lista]
> **Tono:** [una oración]
---
[repite para cada empresa, ordenado por overall_score descendente]
Guardar en archivo
mkdir -p docs/pain-maps
OUTFILE="docs/pain-maps/$(date +%Y-%m-%d).md"
cat > "$OUTFILE" << 'EOF'
REPORT_CONTENT_HERE
EOF
echo "Mapa de dolor guardado en $OUTFILE"
Si se analizan varias empresas, también guarda archivos individuales usando nombres de empresa en slug (minúsculas, reemplaza espacios y caracteres especiales con guiones, elimina guiones finales):
Por ejemplo, "ACME, Inc." → acme-inc.md, "CoolStartup Inc" → coolstartup-inc.md
SLUG=$(echo "NOMBRE_EMPRESA" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/-$//')
cat > "docs/pain-maps/${SLUG}.md" << 'EOF'
CONTENIDO_CUENTA_INDIVIDUAL_AQUI
EOF
Cuándo Usar
- Tienes de 1 a 15 descripciones de trabajo pegadas y quieres saber qué dolor siente cada empresa
- Estás planificando un alcance basado en cuentas y necesitas un análisis estructurado del dolor antes de escribir secuencias
- Quieres priorizar qué cuentas con señales de contratación abordar primero
- Un PMM quiere lenguaje de dolor real de publicaciones de empleo para refinar el posicionamiento
Cuándo NO Usar
- Necesitas encontrar empresas que están contratando (usa
linkedin-hiring-intent-scanneroyc-intent-radar-skill) - Necesitas escribir mensajes de alcance (usa
outreach-sequence-builder— aliméntalo con la transferencia de esta habilidad) - Quieres monitorear una plataforma en busca de señales a lo largo del tiempo (usa
reddit-icp-monitorotwitter-GTM-find-skill) - Necesitas información de contacto o enriquecimiento de correo electrónico (esta habilidad no proporciona eso)
Funciona Bien Con
- outreach-sequence-builder: Pasa el bloque
handoff.for_outreach_sequence_builderdirectamente como contexto al construir una secuencia. - noise-to-linkedin-carousel: Usa los dolores primarios y las citas de evidencia como material fuente para un carrusel sobre los problemas del comprador.
- reddit-icp-monitor: Compara temas de dolor de publicaciones de empleo con temas de dolor que aparecen en discusiones de Reddit.