career-record

---

name: career-record description: Úsalo cuando alguien quiera un registro de sus logros en la empresa (salida, despido, caso de ascenso, revisión de desempeño, actualización de CV, '¿qué he hecho en los últimos N años?'). Captura evidencia desde GitHub, Jira, Confluence, Slack, Culture Amp y opcionalmente Amplitude, y luego construye dos artefactos HTML privados más PDFs: un informe extenso (resumen, viñetas de CV, historias STAR, cronología, tarjetas de proyecto, reconocimientos, apéndice completo) y un breve resumen para selección con un gráfico de línea de tiempo. Estrictamente de solo lectura contra las herramientas de la empresa.

Registro profesional

Construye un registro profesional a partir de la evidencia real del trabajo de una persona:

• Informe extenso: un resumen ejecutivo, tarjetas de impacto, un gráfico de PRs por trimestre, viñetas de CV, historias STAR, una línea de tiempo trimestral, tarjetas de proyecto, habilidades, liderazgo, reconocimientos, momentos de crecimiento y un apéndice que enumera cada PR, ticket de Jira y página de Confluence.
• Informe breve para entrevistas de selección: un pitch, datos clave, una línea de tiempo profesional interactiva, los mayores logros, citas y el stack tecnológico.

Ambos se publican como artefactos privados y se exportan a PDF.

Ejecuta esto como una colaboración en varias sesiones con la persona; no es una tarea de una sola vez. Espera varias rondas de su revisión.

Reglas estrictas

1. Solo lectura en todas partes. Nunca envíes mensajes de Slack, añadas reacciones, crees o actualices tickets de Jira o páginas de Confluence, ni guardes gráficos de Amplitude. Incluye esta regla en cada prompt de subagente.

2. Captura primero, analiza después. El acceso puede desaparecer en cualquier momento, por ejemplo, en un despido. Vuelca los datos sin procesar al disco antes de resumir, y no esperes al análisis para capturar la siguiente fuente.

3. Sin métricas inventadas. Cada número necesita una fuente. Si falta un número, escribe [PREGUNTAR A <NOMBRE>: …] en las notas y pregunta a la persona; nunca adivines.

4. Confidencialidad. Sigue references/confidentiality.md al completo. En resumen:

   • sin nombres ni IDs de clientes;
   • sin cifras internas de ingresos o ARR;
   • sin contenido de compensación, RRHH o personal;
   • sin credenciales;
   • sin URLs internas como contenido.

   Los volcados sin procesar permanecen locales.

5. Atribuye con precisión. Para funciones de equipo, di "función de equipo". Si un compañero implementó algo, dilo. La persona decide el énfasis de cada elemento.

6. Antes de editar notas después de una ronda de revisión, cópialas a notes/backups/<archivo>.pre-<ronda>.md.

Espacio de trabajo

Por defecto: ~/career-record/. Pregunta a la persona si quiere una ubicación diferente.

career.json          # identidad + contenido frontal para ambas páginas (ver examples/career.json)
raw/{github,jira,confluence,slack,cultureamp,amplitude}/   # exportaciones sin procesar
notes/               # resúmenes por fuente + los archivos de síntesis que la compilación lee
notes/session-handoff.md   # estado en ejecución; leer primero después de cada compactación
output/              # achievements.html, overview.html, *-standalone.html, *.pdf

Mantén notes/session-handoff.md actualizado a medida que avanzas. Registra:

• estado de la fase;
• hechos confirmados;
• decisiones de la persona y preferencias de énfasis;
• URLs de los artefactos;
• los pasos para reconstruir.

Guarda una memoria corta del proyecto que apunte a él, para que una sesión posterior pueda retomar.

Fases

0. Entrevista (AskUserQuestion)

Pregunta por:

• fechas de inicio y fin;
• equipos o tribus, con fechas;
• niveles y fechas de promoción;
• gerentes (solo para contexto);
• el propósito del registro (búsqueda de empleo, promoción, archivo) y la audiencia;
• la org y el inicio de sesión de GitHub;
• los aspectos destacados que recuerden, como una lista semilla para verificar;
• cualquier cliente o tema que nunca deba mencionarse. Van a la lista de bloqueo.
• los canales importantes de Slack:
  • canales del equipo y la tribu;
  • canales de misión, proyecto o squad;
  • canales de guardia o alertas;
  • canales de incidentes;
  • canales de reconocimiento como #shoutouts;
  • canales de procesos o lanzamiento.
• si algún canal privado o DM importa, como hilos con gerentes, colaboradores cercanos o un canal privado de squad.

Diles claramente que las herramientas de Slack solo pueden capturar canales públicos. Si quieren que se incluyan canales privados o DMs, deben copiar esos mensajes ellos mismos en raw/slack/, como archivos .txt o .md, uno por canal o persona. Los pasos están en la sección de Slack de references/sources.md.

Escribe las respuestas en notes/phase0-background.md, incluyendo la lista de canales y qué fuentes privadas pegará la persona. Crea <scratchpad>/blocklist.txt, un término por línea: nombres de clientes, IDs de empresa y cualquier otra cosa que hayan marcado. Mantenlo fuera del espacio de trabajo.

1–5. Captura

Sigue references/sources.md para cada fuente:

1. GitHub
2. Jira
3. Confluence
4. Slack
5. Culture Amp (PDFs manuales)
6. Amplitude, opcionalmente

Ejecuta fuentes independientes en paralelo con subagentes. Si el acceso pudiera revocarse pronto, captura Slack y Culture Amp primero. Son los más difíciles de recrear.

Después de la captura, escribe un resumen por fuente: notes/<fuente>-summary.md.

5b. Referencia cruzada

Construye notes/crossref.md, más crossref.json si es útil:

1. Asigna cada PR a sus claves de Jira.
2. Agrupa cada ticket de Jira en su épica o misión.
3. Adjunta documentos de Confluence e hilos de Slack a esos grupos.

Trabajo anterior a 2 años. El historial de Slack solo abarca aproximadamente los últimos 2 años desde hoy. Slack contiene la mayor parte del "pegamento" que explica por qué se hizo el trabajo y cómo se relacionan las piezas, así que para cualquier cosa más antigua, reconstruye la historia a partir de GitHub y Jira, más Confluence donde exista:

• Busca grupos. Muchos tickets en el mismo tablero sobre el mismo tema o similar, creados o resueltos cerca en el tiempo, probablemente sean una misión o proyecto. Ejemplos: una serie de tickets IM, QOL o IL en un área de funcionalidad. Señales adicionales:

  • una épica o padre compartido;
  • una etiqueta o nombre de sprint compartido;
  • PRs a los mismos repos en las mismas semanas;
  • una lista de verificación de Confluence o documento de diseño de ese período.

• Registra cada grupo en las notas como una misión probable, marcada como reconstruida. Enumera:

  • los tickets y PRs;
  • el rango de fechas;
  • tu suposición sobre el objetivo;
  • la evidencia para ello.

  Por ejemplo: **Misión probable (reconstruida, pre-Slack):** reglas de visibilidad, Sep 2023, IM-762/763/764 + 3 PRs. [PREGUNTAR A <NOMBRE>: nombre de la misión, objetivo, ¿tu rol?]

• Confirma el contexto con la persona a menos que estés seguro, por ejemplo, el nombre y la descripción de la épica lo expliquen. Pregunta sobre:

  • el nombre y propósito de la misión;
  • quién más participó;
  • su rol en ella;
  • el resultado;
  • cualquier cosa que saliera mal.

  Agrupa estas preguntas por período en lugar de hacerlas una por una.

• Nunca inventes el pegamento. Sin Slack o la confirmación de la persona, describe lo que muestran los tickets y PRs, no la motivación ni el impacto.

• Sin revisiones anteriores a 2024. Culture Amp solo llega hasta 2024. Para cualquier cosa anterior no hay calificaciones ni citas de revisores. No dejes un vacío que parezca que la persona no tuvo reconocimiento en ese período: indica que la fuente no existe y pide a la persona cualquier comentario que recuerde o haya guardado.

Cada PR con autoría debe terminar exactamente en un grupo o en "varios/mantenimiento". Marca los PR que agrupaste por repositorio, tiempo o título como inferidos. Las épicas sin PRs son trabajo no relacionado con código, como diseño, coordinación o liderazgo, así que mantenlas. Muestra los grupos a la persona y aplica sus correcciones.

6. Síntesis

Escribe los archivos de notas en los formatos de references/notes-format.md:

• notes/timeline.md: la trayectoria profesional más una sección por trimestre.
• notes/project-cards.md: una tarjeta por grupo, cubriendo problema, rol, lo que construyeron, impacto/resultado, tecnología y evidencia.
• notes/people-skills-recognition.md: cifras destacadas, matriz de habilidades, liderazgo, citas de reconocimiento y momentos de crecimiento.
• notes/cv-and-stories.md: de 8 a 12 viñetas de CV y de 5 a 8 historias STAR.

Cada afirmación lleva una referencia (fuente: …). Luego haz que la persona revise las tarjetas y las métricas. Esta ronda suele reordenar prioridades y corregir atribuciones incorrectas.

7. Salida

1. Ejecuta el inicio rápido de Artifact con intent: "other", que cubre la guía de diseño de la página.

2. Rellena career.json a partir de examples/career.json:

   • nombre, fechas y subtítulo;
   • párrafos de resumen;
   • tarjetas de impacto. Las tarjetas de recuento como PRs, repositorios, revisiones, tickets de Jira y páginas de Confluence se generan automáticamente; solo añade extras.
   • bandas de gráfico como promociones;
   • patrones de redacción;
   • el bloque overview: carriles, hitos (row 0/1 y anchor start/middle/end evitan colisiones de etiquetas), logros, citas, hechos y stack.

   Los tipos de barra son role, promoted, lead, work, oncall y alt.

3. Compila:

   python3 <skill>/scripts/build.py <workspace>
   python3 <skill>/scripts/build_overview.py <workspace>
   <skill>/scripts/check_blocklist.sh <scratchpad>/blocklist.txt <workspace>/output/achievements.html <workspace>/output/overview.html   # debe ser 0
   

4. Verifica el diseño:

   • scripts/export_pdf.sh escribe *-standalone.html.
   • scripts/screenshot.sh lo renderiza; mira el PNG para detectar colisiones de etiquetas o desbordamientos.
   • Observa especialmente los hitos de la línea de tiempo.

5. Publica cada página como un artefacto privado con la herramienta Artifact, luego pasa la misma file_path para republicar más tarde. Da a la persona ambos enlaces.

6. Exporta los PDFs con scripts/export_pdf.sh <workspace>/output/achievements.html y scripts/export_pdf.sh <workspace>/output/overview.html. El PDF extenso es principalmente apéndice y suele tener de 50 a 100 páginas.

7. Pide a la persona que verifique al azar unas 10 afirmaciones contra la evidencia.

Bucle de ajuste

La persona pedirá reordenar el énfasis, añadir o intercambiar citas, o añadir trabajo temprano faltante.

1. Edita las notas o career.json.
2. Recompila.
3. Ejecuta la verificación de la lista de bloqueo.
4. Republica en las mismas URLs.
5. Vuelve a exportar los PDFs.
6. Registra cada decisión en el archivo de traspaso.

Los primeros años suelen estar infradocumentados: el historial de Slack solo llega unos 2 años atrás, y Culture Amp solo cubre desde 2024. Busca en Jira, Confluence y GitHub específicamente para ese período.

Lecciones de ejecuciones anteriores

• Tooltips: El hover de SVG <title> no funciona dentro de los artefactos. La vista general usa un tooltip JS impulsado por data-tip="Label|detail", y la compilación ya lo maneja.
• Historias STAR largas: mantén las viñetas cortas y anidadas en lugar de párrafos largos.
• Preferencias de las personas:
  • destacar squads o misiones completas en lugar de tickets individuales;
  • enmarcar las señales de confianza en relación con el nivel, ej. "siendo todavía junior";
  • incluir entrevistas de contratación, charlas y liderazgo de procesos, no solo código.
• Errores y reversiones son material valioso de "Crecimiento" cuando se cuentan con honestidad. No los ocultes, pero deja que la persona decida si se convierten en una historia STAR.