# Lead Research Brief > Investiga un lead comercial B2B, mapea sus procesos operativos AS-IS y genera el backlog de una app a medida. Entrega 3 artefactos (resumen en chat + HTML interactivo + Word) y opcionalmente una demo-app funcional con datos sintéticos y branding del cliente (Fase 6). USAR SIEMPRE cuando el usuario diga "investiga este lead", "haz el brief de", "prepara la propuesta para", "genera el mapa de procesos de", "brief_investigacion", o proporcione un formulario de lead con organización, sector o problema. - Skill: `luispitik/lead-research-brief` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add luispitik/lead-research-brief` - Raw SKILL.md: https://api.skillmd.com/api/skills/luispitik/lead-research-brief/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: CC-BY-NC-SA-4.0 - Author: luispitik (https://skillmd.com/u/luispitik) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/luispitik/lead-research-brief --- # Brief · Investigación · Propuesta ## ¿Qué hace esta skill? Dado un lead (organización + contexto), esta skill ejecuta una investigación exhaustiva y genera tres entregables sincronizados. Opcionalmente (Fase 6) produce una cuarta pieza: una demo-app funcional con datos sintéticos y branding del cliente para enseñar en vivo en la reunión comercial. 1. **Resumen en chat** — hallazgos clave, fricciones detectadas y oportunidades IA 2. **HTML interactivo** — dos pestañas: Mapa de Procesos AS-IS + Funcionalidades app a medida 3. **Documento Word (.docx)** — informe estructurado listo para entregar o archivar 4. **Demo-app pre-reunión (opcional)** — single-file HTML con 4 vistas, datos sintéticos del sector y paleta/logo del cliente --- ## FASE 0 — Recoger el formulario del lead Si el usuario no ha proporcionado aún todos los datos, pedirle que rellene (o confirmar los que ya dio): ``` FORMULARIO DE LEAD — BRIEF INVESTIGACIÓN PROPUESTA 1. Nombre de la organización: 2. Sector / actividad principal: 3. URL web (si existe): 4. Nombre del interlocutor/a y cargo: 5. Problema o necesidad detectada (en sus propias palabras): 6. Contexto adicional (tamaño, número de empleados, software actual conocido, etc.): 7. Objetivo de la reunión o de la propuesta: ``` Extraer del formulario: `org_name`, `sector`, `url`, `contact_name`, `contact_role`, `pain_statement`, `context`, `goal`. --- ## FASE 1 — Investigación exhaustiva (web_search o launch_extended_search_task) **OBLIGATORIO usar búsqueda web.** No inventar datos. Si hay herramienta de investigación extendida disponible, usarla. Si solo hay web_search, hacer al menos 6-8 búsquedas combinando los vectores siguientes: ### Vectores de investigación Leer `references/research_vectors.md` para la guía completa de búsquedas por sector. En resumen, investigar siempre: | # | Vector | Ejemplo de query | |---|--------|-----------------| | 1 | Organización en sí | `"[org_name]" [ciudad] [sector]` | | 2 | Software / herramientas actuales | `"[org_name]" software gestión OR ERP OR CRM` | | 3 | Normativa sectorial relevante | `normativa [sector] España 2024 2025` | | 4 | Benchmark competencia / equivalentes | `colegios [sector] España digitalización software` | | 5 | Casos de uso IA en el sector | `inteligencia artificial [sector] automatización España` | | 6 | Dolores comunes del sector | `[sector] problemas gestión ineficiencias digitalización` | | 7 | Contexto regulatorio IA | `EU AI Act [sector] obligaciones riesgo` | | 8 | Noticias recientes de la org | `"[org_name]" site:es OR noticias 2024 2025` | ### Qué extraer - **Datos verificados de la organización**: tamaño, sede, web, redes, responsables - **Software o herramientas actuales** (si se pueden inferir o encontrar) - **Contexto normativo** que afecta al sector (fechas clave, obligaciones) - **Fricciones comunes** del sector (validadas por el pain_statement del formulario) - **Oportunidades IA** concretas y aplicables (no genéricas) - **Integraciones externas** habituales del sector --- ## FASE 2 — Construir el Mapa de Procesos AS-IS Con los datos investigados, identificar entre **6 y 10 áreas operativas** de la organización. Para cada área construir: ``` Área {N}: id: snake_case_único label: "Nombre del área" icon: emoji representativo color: color HEX (asignar uno de la paleta: ver references/palette.md) light: versión clara del color (para fondos) desc: "Descripción de una línea de qué gestiona esta área" steps: [ entre 6 y 9 pasos, cada uno con: label: descripción del paso (acción concreta) actor: quién lo ejecuta (persona, sistema, organización externa) type: "entrada" | "proceso" | "decisión" | "integración" | "salida" ] integrations: [ 2-4 sistemas o plataformas externas relevantes ] pains: [ 2-4 fricciones actuales concretas y verificadas ] ``` **Reglas de calidad del mapa:** - Cubrir el ciclo de vida completo de la organización (no solo lo que mencionó el lead) - Al menos un paso de tipo `integración` por área - Los `pains` deben ser concretos y ligados al sector (no genéricos) - Los actores deben ser realistas para el tamaño de la organización --- ## FASE 3 — Construir el Backlog de Funcionalidades Diseñar entre **6 y 10 módulos** de una app a medida que resuelva los pain points del mapa. Para cada módulo: ``` Módulo {N}: cat: "Nombre del módulo" icon: emoji color: color HEX de la paleta items: [ entre 3 y 6 funcionalidades, cada una con: label: "Nombre de la funcionalidad" desc: "Descripción de qué hace y qué problema resuelve (2-3 líneas)" prioridad: "Esencial" | "Recomendado" | "A valorar" ] ``` **Reglas de priorización:** - `Esencial`: resuelve el pain principal del lead, obligatorio en MVP - `Recomendado`: alto valor, implementar en segunda fase - `A valorar`: interesante pero no crítico, para valorar con el cliente Cada módulo debe corresponder a al menos un área del mapa de procesos. Incluir siempre un módulo de **IA Aplicada** y uno de **Cumplimiento / Gobernanza**. --- ## FASE 4 — Generar los tres entregables ### 4A — Resumen en chat Responder en el chat con esta estructura: ``` ## Brief: [Nombre organización] **Interlocutor/a:** [nombre] · [cargo] **Sector:** [sector] · **Tamaño estimado:** [dato] ### Hallazgos clave - [hallazgo 1 con dato concreto] - [hallazgo 2] - ... ### Fricciones principales detectadas - [fricción 1 — área] - [fricción 2 — área] - ... ### Oportunidades IA prioritarias 1. [oportunidad con impacto esperado] 2. ... ### Ecosistema digital actual [software/herramientas detectadas] ### Contexto normativo relevante [normativa + fechas clave que crean urgencia] ``` ### 4B — HTML interactivo Leer `references/html_template_guide.md` para la guía completa de generación del HTML. En resumen: - Estructura idéntica a `procesos_premium.html` (misma estética, mismos colores CSS) - Dos pestañas en nav: **Mapa de Procesos** / **Funcionalidades** - Los datos de AREAS[] y FUNCIONALIDADES[] se inyectan con los datos del lead - El nombre de la organización aparece en el nav y en los títulos de sección - Guardar como `brief_[org_slug]_[YYYYMMDD].html` en /mnt/user-data/outputs/ ### 4C — Documento Word (.docx) Leer `/mnt/skills/public/docx/SKILL.md` para generar el Word correctamente. Estructura del Word: 1. Portada (nombre org, fecha, ref, operador/consultora) 2. Resumen ejecutivo (hallazgos, fricciones, oportunidades) 3. Mapa de Procesos AS-IS (tabla por área: pasos + integraciones + fricciones) 4. Propuesta de Funcionalidades (tabla por módulo con prioridad) 5. Contexto normativo y oportunidad IA 6. Próximos pasos recomendados Guardar como `brief_[org_slug]_[YYYYMMDD].docx` en /mnt/user-data/outputs/ --- ## FASE 5 — Presentar al usuario Usar `present_files` con ambos archivos (HTML primero, luego Word). Confirmar en el chat que la investigación está completa y ofrecer ajustes. Tras presentar, ofrecer explícitamente la Fase 6 (demo-app pre-reunión) si el lead parece de alto potencial: *"¿Quieres que te genere también una demo-app funcional para enseñar en la reunión, con su logo y datos sintéticos del sector?"* --- ## FASE 6 (opcional) — Generar demo-app funcional pre-reunión **No ejecutar esta fase por defecto.** Ejecutar **solo** si el usuario lo pide explícitamente con frases como "genera la demo", "prepara la app pre-reunión", "hazme la aplicación para enseñar", "haz el demo para la reunión", o confirma tras la oferta de Fase 5. El objetivo es producir una mini-aplicación funcional con datos sintéticos que demuestre 2-3 módulos del backlog (prioridad Esencial) como si fueran un producto ya existente. El operador la enseña en vivo en la reunión comercial con el lead. ### Inputs - `backlog` de Fase 3 (módulos priorizados Esencial / Recomendado / A valorar) - `pain_statement` del formulario (Fase 0) - `org_name`, `sector`, `url` del lead (Fase 0) - Si hay URL, intentar extraer el **logo del cliente**. Rutas típicas: `/logo.png`, `/logo.svg`, `/brand/-icon.png`, `/_next/image?url=...`, `/favicon.ico`, o ``. - **Paleta**: extraer de la web del cliente si es posible (CSS variables, classes Tailwind, inspección visual). Fallback: paleta neutral según sector. ### Output Archivo `demo_[org_slug]_[YYYYMMDD].html` en `/mnt/user-data/outputs/`. Single-file HTML autocontenido. Abre offline en cualquier navegador, sin servidor ni build step. ### Guía completa Leer `references/app_demo_guide.md` para: - Stack técnico exacto y CDNs - Plantilla de layout (sidebar + topbar + vistas) - Patrones de datos sintéticos por sector (colegio, clínica, staffing, despacho, PYME, agri, ayuntamiento) - Reglas de selección de módulos a demostrar del backlog - Librería de respuestas IA mock por categoría - Reglas de branding (logo con fallback monograma, paleta, tipografía) En resumen: - **Stack**: React 18 + ReactDOM + Tailwind 3 + Babel standalone (todo vía CDN, sin npm). - **4 vistas**: Home (dashboard ejecutivo) + 2-3 módulos del backlog + Asistente IA. - **Datos sintéticos** contextualizados al sector: 20-40 registros por entidad principal. - **IA mock**: 4 respuestas pre-baked, redactadas por Claude en el tono + idioma del cliente. - **CRUD ligero** con persistencia en `localStorage`. - **Branding**: logo cliente si disponible (con fallback monograma), paleta, tagline. ### Reglas de selección de módulos a demostrar 1. Priorizar 2-3 módulos con prioridad **Esencial** del backlog de Fase 3. 2. Preferir los que tienen máximo impacto visual (tablas con acciones, dashboards, chat IA). 3. Incluir siempre: Home/Dashboard + módulo que resuelve el pain principal + Asistente IA (4 presets). 4. Si no hay 3 módulos Esenciales, completar con 1 Recomendado de alto impacto visual. ### Tono y localización del contenido - **Idioma**: el del cliente. Lead en EE.UU. → inglés; España → español; LATAM → español. - **Voz del sector**: warehouse/ops → directo y operativo; clínica/colegio → calmo y confiable; despacho jurídico → formal y preciso; ayuntamiento → institucional. - **Datos sintéticos**: nombres, direcciones, clientes realistas del país y sector. - **Respuestas IA**: deben sonar como output real, no como placeholder. Citar datos concretos del sector y del propio dataset sintético. ### Límites importantes - No ejecutar sin autorización explícita del usuario (consume tiempo y tokens). - Usar **sólo** datos sintéticos. Nunca datos reales del cliente ni de terceros. - No prometer funcionalidad que la demo no muestre ("aún aprendiendo" para input libre). - Incluir nota visible al pie del Asistente IA: *"Demo — respuestas pre-configuradas. La versión conectada usa los datos reales del cliente."* - Mostrar botón **Reset demo** en topbar para restaurar el estado inicial entre demos. --- ## Referencias de esta skill - `references/research_vectors.md` — guía de búsquedas por sector con queries tipo - `references/html_template_guide.md` — guía completa del HTML premium + datos de colores - `references/palette.md` — paleta de colores por área/módulo - `references/pain_library.md` — biblioteca de fricciones comunes por sector - `references/app_demo_guide.md` — guía de la demo-app funcional (Fase 6 opcional) Leer solo la referencia necesaria en cada fase. No cargarlas todas a la vez.