crea-tu-skill-pdf

Crea una skill personalizada que genera documentos PDF profesionales y consistentes (guías, propuestas comerciales, reportes, one-pagers, lead magnets, case studies, cotizaciones) con el branding del usuario. Activar SIEMPRE que el usuario diga "quiero crear una habilidad/skill para PDFs", "ayúdame a crear una skill que haga mis documentos", "quiero una skill personalizada para mis propuestas/guías/reportes", "necesito estandarizar mis PDFs", "hazme una habilidad que genere PDFs con mi marca", "crea una skill para documentos con mi branding", o cualquier variante. También activar cuando describa el problema de no tener consistencia en sus documentos enviados o quiera automatizar la creación de PDFs con identidad visual propia. La skill entrevista al usuario sobre marca, diseño y tipo de documento, y produce un paquete .skill listo para instalar en Claude.

Crea Tu Skill de PDF

Esta skill es un constructor de skills. Su output no es un PDF: es otra skill — un paquete .skill instalable que, una vez instalado, generará PDFs con el branding y la estructura del usuario cada vez que lo invoque.

El usuario sale de esta skill con una habilidad personalizada suya que sabe generar sus guías, propuestas, reportes o el tipo de documento que haya definido — siempre con el mismo diseño, sin improvisar.

Qué hace diferente a este flujo

La mayoría de los intentos de generar documentos con IA fracasan por tres razones: el diseño es inconsistente entre documentos, la estructura varía cada vez, y el resultado depende del prompt del día. Esta skill resuelve eso externalizando todas las decisiones a archivos fijos (tokens de diseño, componentes, estructura) de forma que la skill resultante no improvise nada — solo ejecute.

El trabajo acá es una entrevista guiada que convierte el branding del usuario en parámetros concretos, y luego arma los archivos de la skill a partir de plantillas probadas.

Flujo de trabajo

Paso 0 — Preámbulo y expectativas

Antes de hacer preguntas, explicar brevemente al usuario qué va a pasar (2–3 líneas máximo):

"Vamos a construir tu skill personalizada. Te voy a hacer preguntas sobre tu marca y el tipo de documento que quieres estandarizar. Al final te entrego un archivo .skill que instalas en Claude y queda activo para que le pidas documentos cuando quieras. Son unas 6–8 preguntas, hagámoslo."

No saturar con detalles técnicos. El usuario quiere su skill, no una clase sobre skills.

Paso 1 — Entrevista

Hacer las preguntas en el orden de references/entrevista.md. Cada pregunta tiene una razón y un fallback razonable si el usuario no sabe. Leer ese archivo antes de empezar la entrevista.

Reglas de conducción:

  • Agrupar preguntas relacionadas en una sola vuelta cuando sea natural (ej: nombre + cargo + web juntos). No convertir esto en 15 mensajes.
  • Aceptar fallbacks cuando el usuario dude. Si dice "no sé qué tipografía uso", ofrecer DM Sans o Inter como default moderno. No paralizar el flujo.
  • Confirmar al cierre de cada bloque temático. Después de identidad, después de diseño, después de estructura — resumir lo capturado en 3–4 líneas antes de avanzar.
  • Pedir assets (logo, foto) al final de la entrevista, no al inicio. Así el usuario no se queda buscando archivos a mitad del flujo.

Paso 2 — Consolidar el brief

Antes de generar la skill, consolidar toda la información en un objeto mental (o un JSON si ayuda). La consolidación es explícita porque es el contrato que va a quedar fijado dentro de la skill resultante.

Campos mínimos:

identidad:
  nombre_marca
  nombre_autor
  cargo_autor
  web
  correo_o_linkedin
  bio_corta (1-3 oraciones)

tipo_documento:
  nombre_tipo (ej: "Guía completa", "Propuesta comercial", "Reporte mensual")
  trigger_phrases (qué frases activarán la skill generada)
  secciones_fijas (portada + [...] + página final)

diseno:
  color_principal
  color_secundario
  color_fondo_paginas
  color_fondo_portada
  color_acentos
  fuente_titulos (+ fallback)
  fuente_cuerpo (+ fallback)
  fuente_mono (opcional, + fallback)
  radio_esquinas (0 = brutalista, 4-8 = suave, 12+ = amigable)
  sombras (sí/no, estilo)
  estilo_general (brutalista / minimalista / editorial / corporativo)

bloques_fijos:
  - nombre_bloque            (ej: "Página final — Bio + CTA", "Metodología", "Disclaimer")
    posicion                 (inicio / después de X / final / antes de X)
    tipo                     (bio_cta / texto / bullets / tabla / mixto)
    contenido_literal        (el texto exacto o los datos del bloque)
    componentes_especiales   (foto, ícono, tabla, link, etc.)
  # puede haber 1 o muchos — mínimo suele ser el bloque bio+CTA

assets:
  logo_path (o nota "usuario aportará después")
  foto_autor_path (o nota)

Mostrar el brief consolidado al usuario y pedir confirmación antes de generar. Esta es la última oportunidad de corregir algo sin regenerar todo.

Paso 3 — Generar los archivos de la skill

Usar las plantillas en references/ y reemplazar los placeholders con los valores del brief. Los archivos que hay que producir están en references/estructura_output.md.

Estructura esperada de la skill resultante:

{nombre-skill}/
├── SKILL.md
├── references/
│   ├── design_system.md
│   └── bloques_fijos.md
└── assets/
    ├── logo.png         (si el usuario lo aportó)
    └── autor_circle.png (si el usuario lo aportó — solo aplica si hay bloque bio+CTA)

Reglas al generar:

  • El nombre de la skill resultante debe ser kebab-case corto y descriptivo (ej: guias-acme, propuestas-jorge, reportes-mensuales-xyz). Si el usuario no propone uno, sugerir 2–3 opciones.
  • El description del SKILL.md generado debe ser "pushy" (incluir variantes de triggers) siguiendo el patrón de skill-creator.
  • El código ReportLab embebido en el design_system.md generado debe ser copy-paste funcional — no pseudocódigo. Ver references/plantilla_design_system.md.
  • Si el usuario eligió estilo brutalista, incluir sombras offset y 0px border-radius. Si eligió estilo minimalista o corporativo, ajustar los componentes (ver references/variantes_estilo.md).

Paso 4 — Procesar assets (si se aportaron)

Si el usuario subió logo o foto, aplicar el preprocesado de references/preparacion_assets.md:

  • Logo: convertir a PNG con fondo transparente si no lo está
  • Foto autor: crop cuadrado → máscara circular → guardar como PNG circular listo para usar

Copiar los assets procesados a {nombre-skill}/assets/.

Si el usuario no aporta assets, incluir una nota clara en el SKILL.md generado indicando dónde debe colocarlos y cómo nombrarlos.

Paso 5 — Prueba interna antes de empaquetar

No empaquetar sin probar. Ejecutar la skill recién generada como si fueras un usuario pidiendo un documento real, y verificar que produce un PDF válido.

Procedimiento:

  1. Inventar un caso de prueba representativo del tipo de documento. Ejemplos:

    • Si la skill es de propuestas → "Cliente: ACME Corp. Necesitan rediseño web. Scope: diseño + dev. Precio: $8K. Timeline: 6 semanas."
    • Si es de guías → "Guía sobre cómo empezar con Claude Code"
    • Si es de reportes mensuales → "Reporte de marzo 2026, cliente ACME, conversión subió 18%"

  2. Ejecutar el código Python del design_system.md de la skill generada con datos de prueba, produciendo un PDF real en /sessions/bold-wizardly-darwin/test-preview-{nombre-skill}.pdf.

  3. Renderizar las páginas con pdftoppm -r 100 -jpeg y revisar visualmente cada una. Verificar:

    • Portada con branding correcto (colores, fuentes, logo si aplica)
    • Header/footer consistentes en páginas interiores
    • Cada bloque fijo aparece en su posición con el contenido literal correcto
    • Colores y tipografía coinciden con el brief consolidado
    • Ninguna página queda vacía o con contenido cortado

  4. Si algo falla (código no corre, diseño no coincide, placeholders sin reemplazar, bloques mal posicionados), corregir los archivos de la skill y volver a probar. No avanzar al empaquetado con errores.

  5. Mostrar el PDF de prueba al usuario antes de empaquetar:

    "Antes de empaquetar, te muestro un PDF de prueba que generé con tu skill para validar que funciona. Revísalo: [link al PDF]. ¿Se ve como esperabas?"

    Esperar respuesta del usuario. Si pide ajustes menores (color, tamaño, espaciado), aplicarlos y regenerar la prueba. Si el PDF de prueba se ve bien, avanzar al empaquetado.

Paso 6 — Empaquetar con skill-creator

Usar el script de empaquetado de skill-creator:

python -m scripts.package_skill /sessions/bold-wizardly-darwin/{nombre-skill}

Esto produce un archivo .skill que el usuario puede instalar directamente en Claude.

Copiar el .skill a /mnt/outputs/ y presentarlo con present_files.

Paso 7 — Entrega + pedido explícito de feedback

Cerrar con instrucciones de instalación y un pedido claro de feedback para iterar. Esta skill se optimiza con uso real — el primer draft casi nunca es el final.

Mensaje de cierre sugerido:

"Listo. Tu skill está en [link]. Para instalarla:

  1. Descarga el archivo .skill
  2. Ábrelo — Claude lo instalará automáticamente
  3. Úsala escribiendo: '[frase de trigger que definimos]'

Ahora lo importante: esta es la v1. Quiero que la pruebes con 2–3 documentos reales y me cuentes:

  • ¿El diseño te quedó como querías? ¿Algún color, fuente, espaciado que ajustar?
  • ¿Los bloques fijos aparecen bien y en la posición correcta?
  • ¿Hay algo que el modelo improvisó y debería estar fijado? ¿O al revés, algo fijado que debería ser flexible?
  • ¿Qué le falta o qué le sobra?

Mándame los PDFs que generes con feedback puntual y la regeneramos mejor. Este tipo de skills se afinan con 2–3 iteraciones."

Por qué pedir feedback así: El usuario no siempre sabrá formular feedback genérico, pero sí puede responder preguntas concretas mirando un PDF que acaba de generar. Las 4 preguntas de arriba cubren los 4 ejes donde típicamente fallan estas skills (diseño, bloques fijos, flexibilidad/rigidez, completitud).

Paso 8 — Iterar cuando el usuario traiga feedback

Si el usuario vuelve con observaciones sobre la skill v1:

  1. Identificar en qué archivo(s) de la skill aplica el cambio (SKILL.md, design_system.md, bloques_fijos.md).
  2. Hacer los edits específicos — no regenerar la skill entera.
  3. Ejecutar de nuevo el Paso 5 (prueba interna con PDF de muestra).
  4. Re-empaquetar (Paso 6).
  5. Entregar la nueva versión como v2, v3, etc., y volver a preguntar si hace falta otra ronda.

Cada iteración debería cerrar al menos un punto de feedback. Si después de 2–3 rondas el usuario sigue pidiendo cambios grandes, revisar si el brief inicial estaba bien capturado — puede ser más eficiente rehacer la entrevista desde cero que seguir parchando.

Referencias

Leer estos archivos cuando se llegue al paso correspondiente:

  • references/entrevista.md — Preguntas exactas, orden, razón de cada una, fallbacks
  • references/extraccion_recursos.md — Cómo extraer diseño/estructura desde una URL o documento subido por el usuario (opciones B/C del Bloque 3)
  • references/plantilla_skill_md.md — Template del SKILL.md que se va a generar
  • references/plantilla_design_system.md — Template del design_system.md con código ReportLab parametrizable
  • references/plantilla_bloques_fijos.md — Templates para cualquier bloque que siempre se repita igual: página final con bio+CTA, metodología, disclaimer, términos, "cómo leer este documento", garantías, etc. Soporta texto, listas, tablas y componentes custom.
  • references/variantes_estilo.md — Ajustes según estilo (brutalista / minimalista / editorial / corporativo)
  • references/preparacion_assets.md — Cómo procesar logo y foto del autor
  • references/estructura_output.md — Qué archivos producir y dónde colocarlos

Principios de fondo

No improvisar dentro de la skill generada. Todo lo que el modelo tenga que decidir al momento de generar un PDF debe estar ya decidido en los archivos de diseño. La skill resultante solo ejecuta, no piensa decisiones estéticas.

Consistencia > flexibilidad. El valor de la skill no es que el usuario pueda personalizar cada documento — es que cada documento salga igual sin esfuerzo. Si el usuario quiere algo distinto para un documento puntual, que lo pida por fuera.

Un tipo de documento por skill. Si el usuario quiere skills para guías Y propuestas, son dos skills separadas. Forzarlas en una sola produce instrucciones confusas y documentos inconsistentes. Ofrecer hacer la segunda después si lo pide.

Brutalismo es una elección, no el default. La skill lead-magnet-otherway usa brutalismo porque coincide con la marca de Otherway. No asumir que el usuario lo quiere — preguntar.