Portfolio Builder
Convierte el trabajo de una persona en un portafolio de una página. Claude planifica el contenido en el chat, lo bloquea en un archivo BRIEF.md y luego entrega indicaciones para Claude Code. Claude Code construye localmente, sube a GitHub y Netlify despliega. Luego, Claude audita el repositorio y el sitio en vivo.
Reglas de escritura para todo lo que esta habilidad produce: voz casual y directa, oraciones cortas, sin guiones largos (solo guiones comunes).
Fase 1: Recopilar antes de preguntar
- Extraer lo que ya se sabe: memoria, chats anteriores, sitios en vivo (obtenerlos realmente para listas de características y texto).
- Redactar primero un inventario de contenido. Nunca empezar con un cuestionario en blanco.
Fase 2: Redactar el borrador del resumen v1, luego hacer como máximo 4 preguntas
Redactar secciones con texto real, luego preguntar solo lo que cambia la construcción:
- Audiencia principal (clientes, gerentes de contratación o ambos, y cuál lidera).
- Restricciones de visibilidad (empleador actual nombrado o genérico; cualquier cosa que deba mantenerse privada).
- Qué proyectos incluir.
- Dónde vivirá (un subdominio de Netlify para empezar está bien).
Barandillas:
- Sin métricas, testimonios o clientes inventados.
- Sin afirmaciones que la persona no haya hecho (ej. trabajo en IA en un trabajo diurno que no realizó).
- Los logros del equipo se acreditan como logros del equipo.
- Si el empleador se mantiene genérico, también omitir detalles que lo identifiquen de todas formas (listas de países, títulos exactos más industria). Decir "cinco mercados", no la lista.
- Cuidar la redacción regional (ej. "mercados asiáticos" cuando un país abarca continentes) y los pronombres vagos en el texto del héroe.
Regla de inclusión de proyectos: un proyecto gana un lugar cuando está en vivo y muestra una habilidad por la que la audiencia pagaría. Demasiados emprendimientos indica "sin tiempo para ti." El trabajo estacionado o pasado va en una fila pequeña "Del laboratorio", etiquetado honestamente. Los proyectos sin nombre o no lanzados esperan.
Herramientas: listar solo las herramientas utilizadas en la práctica. Las herramientas con las que solo están familiarizados van en una nota al pie de una línea ("También cómodo con X e Y").
Fase 3: Llenar los vacíos
Preguntar por: nombre para mostrar, foto de perfil, una captura de pantalla por construcción, URLs en vivo, URL de GitHub, correo de contacto, redes sociales. Reescribir cualquier texto de sitio proporcionado para que sea apropiado para un portafolio (qué es, para quién es, qué construyeron). Cada enlace de tarjeta debe apuntar a una página en vivo que realmente describa ese elemento. Si la página no está lista, sin enlace y etiquetarlo (ej. "Próximamente"). Diferir cualquier cosa no lista (enlace de reserva, "trabaja conmigo", testimonios) a una lista "Después" en lugar de bloquear la v1.
Fase 4: Bloquear BRIEF.md
Escribir BRIEF.md con estas secciones, en orden:
- Objetivo (prueba de 10 segundos: qué construyen, prueba, cómo contactarlos)
- Audiencia
- Reglas para el texto (voz, sin guiones largos, barandillas de visibilidad y precisión, usar el texto tal como está escrito)
- Tecnología (HTML/CSS/JS plano, sin paso de construcción; index.html, styles.css, main.js, /assets; GitHub + Netlify; Lighthouse 95+; móvil primero)
- Dirección de diseño (por defecto estilo Apple: fuente Inter o del sistema, espacios generosos, ancho máximo ~1080px, bloques de texto ~680px, titulares grandes y ajustados, paleta neutra, radio de tarjeta 20-24px, bordes finos, un acento usado con moderación, modo claro/oscuro con alternador, sutil desvanecimiento hacia arriba respetando movimiento reducido, capturas de pantalla en una tarjeta minimalista con marco de navegador, navegación pegajosa y borrosa)
- Reglas de diseño (integrarlas desde el principio):
- La navegación y cada sección comparten un contenedor, para que todos los bordes izquierdos estén alineados.
- Un token de espaciado entre secciones (aproximadamente 96px en escritorio, 56px en móvil) para cada espacio; sin rellenos apilados.
- El héroe cabe arriba del pliegue en 1366x768 y 375x812 incluyendo las barras de herramientas del navegador (aproximadamente 650px y 635px visibles).
- Titular: text-wrap pretty en móvil, balance en escritorio; sin saltos de línea forzados.
- Cada sección tiene un encabezado visible o etiqueta de ceja, para que nada flote.
- Activos (rutas de archivo exactas; capturas de pantalla convertidas a WebP con tamaños móviles más pequeños, carga diferida abajo del pliegue; marcador de posición si falta, nunca una imagen rota)
- Contenido de la página, de arriba a abajo, con texto final: Héroe, Lo que hago (3 tarjetas), Construcciones (tarjeta destacada + cuadrícula + fila de laboratorio), Cómo construyo, Herramientas (píldoras agrupadas), Sección de antecedentes, Principios (en las propias palabras de la persona, no citas prestadas), Contacto, Pie de página
- SEO y meta (título, descripción, imagen OG, favicon, HTML semántico, texto alternativo, estados de enfoque, contraste AA)
- Detalles prellenados: URL del repositorio, subdominio preferido más respaldo, manejadores de redes sociales, correo electrónico, para que Claude Code no tenga que preguntar
- Después (no en v1)
Color de acento: elegir uno que se separe de los colores en las capturas de pantalla de las construcciones. Dar valores hex exactos para modo claro y oscuro, y verificar el contraste AA para enlaces Y texto de botones en el acento en ambos modos (los botones en modo oscuro generalmente necesitan texto oscuro sobre un acento claro).
Entregar BRIEF.md como un archivo.
Fase 5: Pasos de configuración + 4 indicaciones
Configuración (una vez):
- Crear un repositorio vacío en GitHub, luego
git clone <url-del-repo>en una carpeta local para que git ya esté configurado. - Poner BRIEF.md en la raíz; agregar /assets y /assets/shots con los archivos nombrados.
- Abrir Claude Code en esa carpeta.
Indicación 1, Planificar:
Lee BRIEF.md completamente. Aún no escribas código.
Dame un plan de construcción breve: estructura de archivos, diseño sección por sección, los tokens de color y la escala tipográfica que usarás, y cualquier pregunta o conflicto que veas en el resumen. Mantenlo en menos de una pantalla.
Color de acento: <HEX_CLARO> en modo claro, <HEX_OSCURO> en modo oscuro. Úsalo con moderación y confirma que ambos pasen el contraste AA, incluido el texto de los botones.
Ayudar a la persona a responder sus preguntas en una respuesta que se pueda pegar.
Indicación 2, Construir:
Construye el sitio exactamente según BRIEF.md y el plan que acordamos.
- Usa el texto palabra por palabra. Sin guiones largos en ningún lugar.
- HTML, CSS, JS plano. Sin frameworks, sin paso de construcción.
- Acento: <HEX_CLARO> claro, <HEX_OSCURO> oscuro. Todo lo demás neutro.
- Sigue las reglas de diseño en BRIEF.md (contenedor compartido, un token de espaciado, héroe arriba del pliegue).
- Usa las imágenes en /assets como WebP. Muestra un marcador de posición limpio si falta alguna.
- Modo claro y oscuro, navegación pegajosa y borrosa, desvanecimiento hacia arriba al hacer scroll con soporte para movimiento reducido.
Cuando termines, inicia un servidor local y dime la URL para que pueda revisarlo.
Indicación 3, Pulir:
Revisa el sitio como lo haría un diseñador senior de Apple, luego corrige lo que encuentres:
1. Verifica en 375px, 768px, 1366px y 1440px. Sin desplazamiento horizontal, nada apretado.
2. Todos los bordes izquierdos alineados; cada espacio de sección usa el único token de espaciado.
3. El héroe cabe arriba del pliegue con las barras de herramientas del navegador en 1366 y 375.
4. El modo oscuro se ve intencional, no invertido. El acento se lee bien en ambos modos.
5. Accesibilidad: texto alternativo, estados de enfoque, contraste AA, encabezados semánticos.
6. Busca en todos los archivos guiones largos y reemplázalos.
7. Ejecuta Lighthouse y obtén las cuatro puntuaciones a 95+.
Dame una lista breve de lo que cambiaste.
Luego la persona da comentarios en lenguaje sencillo hasta que esté satisfecha.
Indicación 4, Subir y desplegar:
Esta carpeta ya está clonada desde <URL_DEL_REPO>.
1. Agrega un .gitignore y un netlify.toml (directorio de publicación = raíz, encabezados de caché sensatos, y 404 para BRIEF.md y PNGs fuente para que no sean públicos).
2. Confirma todo con un mensaje claro y sube a main.
3. Conecta el repositorio a Netlify. Prueba <SUBDOMINIO> primero, respaldo <RESPALDO>. Si la aplicación de GitHub de Netlify no puede ver el repositorio, dime cómo concederle acceso.
Nota: Claude Code a menudo se adelanta y hace la construcción, pulido y despliegue en uno solo. Está bien; saltar a la auditoría.
Fase 6: Auditoría después de la subida
Cuando se comparte la URL del repositorio o del sitio en vivo:
- Clonar el repositorio y verificar: el texto coincide con BRIEF.md, nada inventado, sin guiones largos, sin nombres restringidos, todos los enlaces correctos, imágenes WebP con texto alternativo y tamaños, meta/OG/favicon presentes, archivos internos bloqueados del sitio en vivo.
- Revisión visual del sitio en vivo en el navegador a 1440 y 1366 (claro) y 375 (oscuro): alineación de bordes, consistencia de espacios, héroe arriba del pliegue, ajuste del titular, nada superpuesto.
- Dar correcciones como una indicación de Claude Code que se pueda pegar, luego verificar de nuevo después de la subida. Si el repositorio está vacío, decirlo claramente y pedir que suban primero.
Errores conocidos:
- Netlify agrega una insignia "Powered by Netlify" en proyectos del plan Gratuito creados después del 19 de agosto de 2026. No está en el código: desactivarla en Configuración del proyecto > General > Insignia Powered by Netlify, por proyecto.
- Las puntuaciones en vivo de Lighthouse desde conexiones lentas varían; juzgar con pagespeed.web.dev, no solo con ejecuciones locales.
Fase 7: Sincronizar el resto de su presencia
Ofrecer alinear el archivo README del perfil de GitHub (y otras biografías) con el portafolio: misma línea de posicionamiento, mismo correo de contacto, enlaces a las construcciones en vivo y al portafolio, y eliminar proyectos que el portafolio omitió intencionalmente.