emrekgn/tailored-resume-skill

Currículum Adaptado (Tailored Resume)

Convierte el currículum base de una persona más una oferta de trabajo en un currículum adaptado (.md + .pdf). Luego informa qué tan bien cubre la oferta y qué falta.

La precisión es el objetivo de este skill. Un currículum adaptado que exagere la experiencia puede costarle al usuario una oferta, o un trabajo después de la oferta. Por eso, este skill mantiene un registro de hechos verificados, nunca inventa nada y trata las brechas como algo que debe informarse, no ocultarse.

El espacio de trabajo del currículum

Trabaja en la carpeta de currículums del usuario, generalmente el directorio actual. Contiene:

Archivo	Propósito
base-resume.md	El currículum maestro en el formato Markdown de este skill. Cada variante adaptada parte de él.
facts.md	El registro: correcciones, hechos confirmados que faltan en el currículum base, cosas que nunca se deben afirmar y preferencias (número de páginas, tamaño de papel, línea de contacto).
<slug>-resume-<company>.md / .pdf	Una variante adaptada por solicitud. <slug> es el nombre de la persona en kebab-case.
cualquier otro	Fuentes de apoyo que el usuario proporciona: una exportación de LinkedIn, PDFs antiguos, un perfil de GitHub, READMEs de proyectos.

Si la carpeta tiene un currículum con otro nombre, úsalo y anota su nombre en facts.md, en lugar de renombrar los archivos del usuario.

Primera ejecución: bootstrap

Si aún no hay un currículum base:

1. Pide el currículum existente del usuario (PDF, DOCX, texto o una exportación de LinkedIn). Para un PDF, extráelo con pdftotext -layout.
2. Conviértelo al formato en references/format.md, conservando la redacción. No adaptes en esta etapa.
3. Crea facts.md a partir de assets/facts-template.md, completando la línea de contacto y las preferencias que el usuario mencione.
4. Muestra al usuario el currículum base y pídele que lo revise antes de adaptar cualquier cosa. Los errores aquí se propagan a cada variante.

Flujo de trabajo para una nueva oferta

1. Lee las fuentes. Lee base-resume.md, facts.md y cualquier fuente de apoyo. facts.md anula el currículum base en cualquier punto donde difieran.

2. Analiza la oferta. Clasifica sus requisitos en tres niveles:

   • P1: imprescindibles (factores decisivos)
   • P2: muy deseados
   • P3: agradables de tener

   Anota el vocabulario de la oferta y las palabras clave repetidas. La coincidencia de palabras clave ATS es literal, por lo que los términos de la oferta superan a los sinónimos cuando ambos son ciertos.

3. Mapea la evidencia. Para cada requisito, busca evidencia real en las fuentes. Márcalo como fuerte, parcial o brecha.

4. Escribe la variante en <slug>-resume-<company>.md. Parte de una copia del currículum base, luego:

   • Resumen: reescríbelo para que comience con lo que más valora este rol. Es lo primero que lee un reclutador.
   • Habilidades: reordena y reagrupa las filas para que las más relevantes aparezcan primero, y renombra las etiquetas de las filas con los términos de la oferta (ej. "Message Queues & Streaming", "Platform & Delivery"). Escribe el término completo junto a los acrónimos clave que usa la oferta, una vez cada uno, ej. "Terraform (Infrastructure as Code, IaC)", "Kubernetes (K8s)". Un ATS puede buscar cualquiera de las formas.
   • Viñetas: reordena y reformula las viñetas dentro de cada rol para que las más relevantes aparezcan primero, y recorta las que no importan para esta oferta. Los roles más antiguos pueden reducirse a 1–3 viñetas.
   • Registro de hechos: aplica cada elemento en facts.md.
   • Código abierto / proyectos: para roles técnicos con trabajo público, añade el enlace de GitHub/portfolio a la línea de contacto y una sección corta ## Open Source o ## Proyectos. Elige los 2–3 elementos más relevantes.
   • Cambio de carrera: si el rol es un giro (ej. de ingeniero a relaciones con desarrolladores), mantén el diseño cronológico normal. Añade una sección corta de aspectos destacados entre el resumen y las habilidades que recoja evidencia real y transferible. No uses un currículum "funcional"; los reclutadores y el software ATS tienden a desconfiar de él.

5. Construye y verifica (ver más abajo). Corrige los problemas de diseño antes de informar.

6. Informa en el formato a continuación.

Reglas de honestidad

Estas reglas existen porque la tentación de exagerar es constante y sutil. Cada una protege contra un error que realmente ocurrió en la práctica.

• Nunca inventes habilidades, herramientas, métricas, números de escala, títulos o responsabilidades. Si la oferta pide algo que las fuentes no muestran, déjalo fuera y enuméralo como una brecha. Es posible que el usuario tenga la experiencia. Preguntar toma un mensaje; una afirmación inventada puede surgir en una entrevista.
• Reformular está bien; fortalecer no. Coincidir con el vocabulario de la oferta está bien. Aumentar la fuerza de una afirmación no lo está, por ejemplo:
  • "trabajé en" convertido en "lideré"
  • añadir "en minutos", "a escala" o "bajo carga de producción" sin una fuente
  • fusionar dos hechos separados en una afirmación más grande. Por ejemplo, "lideré el equipo en proyectos de código abierto y empresariales; los empresariales tenían 200k usuarios" no debe convertirse en "lideré un equipo de código abierto cuyos proyectos alcanzaron 200k usuarios".
• Sin autoelegios que las fuentes no contengan, ej. "ingeniero de referencia para problemas difíciles" o "puedo explicar cualquier cosa a cualquier audiencia". Muéstralo con evidencia en su lugar.
• Atribuye con cuidado. Mantén un hecho vinculado al rol del que proviene. Un hecho que el usuario confirmó sin un rol ("He usado Terraform") va en el resumen o las habilidades, no bajo un trabajo adivinado.
• Mantén las métricas textualmente. Porcentajes, conteos y plazos se mantienen exactamente como los indican las fuentes.
• Mantén los títulos de trabajo reales. El encuadre en el resumen ("Ingeniero Backend Nivel Staff") está bien.
• Verifica cada viñeta nueva o modificada contra una fuente antes de construir. Cuando algo es una inferencia razonable pero no está declarado, elimínalo o márcalo en tu informe.

Cuando el usuario corrige o confirma algo

Agrégalo a facts.md de inmediato, con la fecha y, si se conoce, el rol al que pertenece. Luego busca en todas las demás variantes el mismo error y corrígelas también. Omite aquellas que el usuario dijo que ya se habían enviado, y enuméralas en facts.md para que futuras ejecuciones las dejen en paz. Reconstruye los PDF que cambiaste e informa al usuario qué archivos cambiaron.

Construir y verificar

python3 "${CLAUDE_SKILL_DIR}/scripts/build_resume.py" <slug>-resume-<company>.md --check

• Qué hace: escribe el PDF junto al archivo Markdown, luego imprime el número de páginas y el texto que un parser ATS extraería. Pasa --paper a4 si facts.md dice que el usuario prefiere A4.
• Si ${CLAUDE_SKILL_DIR} no está configurado: usa la ruta absoluta del directorio de este skill.
• Si no se encuentra un navegador: pide al usuario que instale Chrome o Chromium, o que configure CHROME_BIN con su ruta.

Luego verifica tres cosas:

1. Número de páginas. Usa la preferencia del usuario de facts.md. De lo contrario, apunta a 1 página para menos de ~10 años de experiencia y 2 páginas para más.
2. Diseño visual. Si pdftoppm está disponible, ejecuta pdftoppm -r 60 -png <pdf> <tmpdir>/preview y revisa cada imagen de página. Busca saltos de página incómodos y líneas que se ajustan mal.
3. Texto extraído. Cada fila de habilidades debe leerse como una línea con su etiqueta, y cada encabezado de rol debe ser una línea que incluya sus fechas. Si no, probablemente el Markdown se desvió del formato.

Si supera el objetivo de páginas, recorta en este orden

1. viñetas menos relevantes en roles más antiguos
2. filas de habilidades largas (fusiona filas, mantén cada una en una línea)
3. certificados (fusiona en una línea, elimina los no relacionados)
4. extensión del resumen

No reduzcas fuentes o márgenes para ajustarlo. Las páginas densas se leen peor para los humanos y no ganan nada con un ATS.

Reglas de diseño

El diseño del constructor está optimizado para el análisis ATS, así que no lo cambies. Las tablas, múltiples columnas y fechas alineadas a la derecha (flex o float) se ven bien pero se extraen mal: las etiquetas se separan de los valores, y las fechas se separan de los títulos de trabajo. El constructor también mantiene las palabras con guión sin romper, porque un guión en un salto de línea se elimina en la extracción ("high-throughput" se convierte en "highthroughput").

Formato del informe

Después de construir, responde con:

1. Archivos: las rutas del .md y .pdf.

2. Tabla de cobertura:

   Nivel	Requisito	Evidencia en el currículum (o brecha)

3. Énfasis: algunas líneas sobre lo que enfatizaste y lo que recortaste.

4. Preguntas: pregunta sobre experiencia que podría cerrar brechas P1/P2, o sobre afirmaciones que inferiste y necesitas confirmar. Sé específico: "¿Trabajaste directamente con X, o solo a través de Y?"

5. Ofertas opcionales: menciona, sin escribirlas sin que te lo pidan, que puedes redactar aperturas de cartas de presentación, respuestas a preguntas de solicitud o puntos de conversación para entrevistas.

Si el rol es un gran estiramiento (varias brechas P1), dilo claramente y sugiere qué ayudaría más. Por ejemplo: un proyecto de portafolio, una contribución de código abierto a los repositorios de la empresa, o una carta de presentación explicando el cambio de carrera.

Preguntas de solicitud y cartas de presentación

Usa el mismo registro de hechos y reglas de honestidad. Responde en la voz del usuario (primera persona), de forma concisa, y nombra cualquier detalle específico que hayas inferido para que el usuario pueda corregirlo. Escribe las cartas de presentación como <slug>-cover-letter-<company>.md. build_resume.py está diseñado para currículums, así que para una carta en PDF escribe HTML simple e imprímelo con el mismo comando de navegador sin cabeza que usa el script.

Archivos de referencia

• references/format.md: el formato Markdown exacto que analiza el constructor, con un ejemplo completo. Léelo antes de escribir o convertir un currículum.
• assets/facts-template.md: punto de partida para un nuevo facts.md.
• assets/example-resume.md: un currículum de muestra ficticio para probar el constructor.