McKinsey Talento Humano

Cerebro de Talento Humano McKinsey

Consultor de RRHH MBB extraído con 200W tokens, con 10 años de experiencia, enfocado en talento, organización y transformación con IA.

Forma de Trabajo Principal

Esta Skill divide la tarea en dos pasos:

1. Recolección de fuentes oficiales: Descubrir páginas candidatas en los sitios web oficiales de MBB, extraer el cuerpo del texto, título, fecha, URL final, estado y captura original.
2. Construcción de base de datos para el agente: Normalizar URLs, deduplicar, aplicar control de calidad, clasificar por tema y generar salidas en JSON, CSV y SQLite.

La escritura en Feishu es un adaptador de publicación posterior a la construcción de la base de datos. Es opcional, se puede re-ejecutar y re-leer, y no debe ser la única fuente de verdad para la base de datos local.

Ámbito de Aplicación

Invocar esta Skill cuando el usuario solicite lo siguiente:

• Buscar contenido en los sitios web de MBB (McKinsey, BCG, Bain) sobre gestión del talento, organización, liderazgo, habilidades, rendimiento, IA y el futuro del trabajo.
• Actualizar la base de contenido existente de MBB, identificando fuentes nuevas, actualizadas, restringidas, sin cuerpo y duplicadas.
• Construir una base de datos que pueda ser consultada por un agente a partir de registros que hayan pasado el control de calidad.
• Con autorización del usuario, escribir incrementalmente los registros validados en una Base o Wiki personal de Feishu.

El alcance de las fuentes se limita a los dominios oficiales: mckinsey.com, bcg.com, bain.com y sus subdominios regionales oficiales. Los resúmenes de terceros, páginas de resultados de búsqueda y páginas republicadas solo pueden usarse como pistas de descubrimiento, no deben entrar en el registro final de fuentes.

Fase 1: Recolección de Fuentes Oficiales

Primero, leer la configuración de fuentes del proyecto y el manifiesto anterior. La configuración debe incluir al menos: firma, dominio oficial, palabras clave temáticas, URLs semilla, ritmo de captura y número mínimo de caracteres del cuerpo.

La prioridad es: sitemap oficial o índice temático, resultados de búsqueda interna del sitio, y actualización de URLs ya registradas. Los resultados del descubrimiento se escriben primero en targets.json, luego se capturan uno por uno en fetched.json. Cada ejecución usa un run_id independiente, conservando las capturas originales en raw/ y el collect-manifest.json.

Reglas de captura:

• Usar HTTPS, conservar la URL final después de redirecciones, eliminar parámetros de seguimiento y fragmentos, generar un ID estable a partir de la URL normalizada.
• Reintentos limitados y con backoff para errores 429, 5xx y de red; los fallos individuales se registran con su estado, sin interrumpir la ejecución completa del lote.
• Respetar robots.txt, frecuencia de acceso, y los límites de inicio de sesión y muros de pago. Cuando se encuentren restricciones, marcar como restricted, sin rellenar el cuerpo con resúmenes de búsqueda o contenido especulativo.
• ok significa que el cuerpo alcanza el umbral y la fuente, el título y la URL pasan la validación; no_body, restricted y error deben conservar la razón del fallo.
• El script de captura solo se encarga de obtener y almacenar los datos, no escribe directamente en Feishu durante la fase de captura.

Si el proyecto ya tiene un adaptador específico para el sitio, reutilizarlo; para sitios nuevos, primero crear y probar el adaptador antes de incluirlo en la ejecución por lotes. La validación general y la construcción de la base de datos utilizan los scripts dentro de esta Skill.

Fase 2: Construcción de la Base de Datos del Agente

Ejecutar después de fusionar fetched.json con el base-corpus histórico opcional:

python3 scripts/build_agent_db.py \
  --run-dir data/runs/20260806-01 \
  --base-corpus data/agent-db/records.json \
  --min-body-chars 800

El script realiza las siguientes acciones:

• Normalizar URLs y eliminar registros duplicados de la misma fuente.
• Seleccionar el registro a conservar basándose en la calidad del cuerpo, la integridad del título y la hora de captura, registrando duplicate_of.
• Validar dominio, firma, estado, longitud del cuerpo, recuento de caracteres y título.
• Clasificar en temas unificados: estrategia de talento, diseño organizacional, IA y futuro del trabajo, habilidades y aprendizaje, rendimiento e incentivos, People Analytics, experiencia del empleado, liderazgo, planificación de la fuerza laboral.
• Generar agent-db/records.json, agent-db/source-register.csv, agent-db/agent-db.sqlite, agent-db/manifest.json.

Control de calidad:

python3 scripts/validate_records.py data/runs/20260806-01/fetched.json --min-body-chars 800 --strict

Solo los registros que pasen el control de calidad son aptos para entrar en el conjunto de cuerpos referenciables. Los registros restringidos y sin cuerpo pueden entrar en un conjunto de monitoreo, pero deben incluir estado y razón del fallo.

Fase 3: Escritura Incremental en Feishu

Antes de escribir, confirmar el perfil CLI actual, identity=user, la Base/Wiki de destino y el mapeo de campos. Feishu personal y Feishu empresarial son dos inquilinos independientes, no se puede inferir el destino basándose en el perfil predeterminado.

Se recomienda usar el valor normalizado de source_url como clave de idempotencia:

1. Leer los campos de la tabla de destino y los registros existentes.
2. Construir un índice URL → record_id.
3. Crear registros para URLs nuevas, actualizar campos necesarios para URLs existentes, y solo actualizar estado y razón de fallo para registros restringidos.
4. Después de cada lote de escritura, leer inmediatamente por URL para verificar título, estado, fecha, tema y enlace de origen.
5. Detenerse si la escritura falla o la identidad expira, conservando los artefactos locales y la lista pendiente de escritura.

No enviar a GitHub: número de filas de Base, tokens de Wiki, ID de inquilino, URLs internas, tokens de acceso, rutas personales o capturas de pantalla de páginas web originales.

Contrato de Registro

Los campos mínimos del registro son: id, firm, title, source_url, final_url, published_date, status, failure_reason, body_text, body_chars, tags, themes, fetched_at_utc.

Los estados permitidos son solo: ok, restricted, no_body, error. Las reglas detalladas están en references/data-contract.md.

Lista de Verificación para Revisión de Código

• La recolección y la construcción de la base de datos se pueden ejecutar de forma independiente, los fallos se pueden localizar por run_id y URL.
• La re-ejecución no genera registros duplicados para la misma URL, las salidas se escriben en archivos temporales y luego se reemplazan atómicamente.
• La captura original, el resultado limpio y el manifiesto se pueden rastrear entre sí.
• Separación de fuentes públicas y datos internos; el repositorio no contiene tokens, cookies, rutas personales, identificadores de inquilino ni datos comerciales reales.
• Errores HTTP, cuerpo vacío, cambios en la estructura del sitio, claves duplicadas en la base de datos y fallos de autenticación en Feishu tienen resultados claros.
• Las pruebas cubren normalización de URLs, restricción de dominios, umbral de cuerpo, preferencia de deduplicación y estados de fallo.

Archivos de Referencia

• data-contract.md: campos de registro, estados, control de calidad y estructura de salida.
• source-adapters.md: descubrimiento de fuentes oficiales de MBB y convenciones de adaptadores de sitio.
• feishu-publish.md: verificación de identidad en Feishu, escritura idempotente y requisitos de relectura.
• scripts/validate_records.py: script independiente de validación de calidad.
• scripts/build_agent_db.py: script independiente de construcción de base de datos.