taufiquebuilds/launchday

¿Qué hace launchday?

La mayoría de los buenos proyectos de código abierto se lanzan mal: un README que explica en lugar de mostrar, sin demo, sin línea de instalación, un nombre que choca con otras tres herramientas y un Show HN publicado a las 3 AM hora de EE. UU. Este skill soluciona todo eso en una sola pasada y luego entrega al usuario un plan de lanzamiento que puede ejecutar en una tarde.

Tú haces la preparación. El usuario hace cualquier cosa pública: crear el repositorio público, hacer push de las etiquetas, subir la vista previa social y publicar. Publicar es difícil de deshacer y habla en su nombre, así que preparas todo hasta el punto de copiar y pegar, luego te detienes y entregas.

Cómo ejecutarlo

Trabaja a través de las fases en orden. Cada fase termina con algo concreto en el repositorio. Dile al usuario en qué fase estás, para que pueda seguir el proceso.

Los scripts viven en scripts/ junto a este archivo. Usan solo la biblioteca estándar de Python (más ffmpeg para la vista previa). Ejecútalos con la ruta a la carpeta de este skill, por ejemplo python3 <skill-dir>/scripts/audit.py ..

Fase	Salida	Script o referencia
1. Comprender	Resumen de un párrafo que confirmas con el usuario	ninguno
2. Verificar nombre	Decisión de mantener o renombrar	scripts/name_check.py
3. Auditar	Puntuación y lista de correcciones	scripts/audit.py
4. README	README reescrito como página de aterrizaje	references/readme.md
5. Demo	GIF o captura de pantalla más vista previa social	references/demo.md, scripts/social_preview.sh
6. Lanzamiento	Flujo de trabajo de CI y lanzamiento	references/release.md
7. Kit de lanzamiento	LAUNCH.md con publicaciones y cronograma	references/launch-posts.md, scripts/launch_time.py
8. Entrega	Comandos exactos para que el usuario ejecute	ninguno

Si el usuario pidió solo una parte ("solo arregla mi README", "escribe mi Show HN"), haz esa fase. Aún así, ejecuta la auditoría primero si es barata, porque a menudo revela el verdadero bloqueador.

Fase 1: Comprender el proyecto

Lee el README, el manifiesto del paquete (package.json, Cargo.toml, pyproject.toml, go.mod) y el punto de entrada. Ejecuta el proyecto si puedes hacerlo de forma segura. Luego escribe un párrafo que cubra tres cosas:

• Qué hace, en una frase que entienda un no experto.
• Quién tiene el problema. Sé específico: "mantenedores con 10+ repos", no "desarrolladores".
• El momento de prueba: la primera cosa que ve un nuevo usuario que le hace decir "oh, qué bien". El README y la demo se construyen alrededor de esto.

Confírmalo con el usuario en un mensaje corto. Un resumen incorrecto aquí envenena todo lo que sigue. También pregunta por cualquier cosa que no puedas encontrar por ti mismo: qué cuenta de GitHub alojará el repositorio y su zona horaria para el cronograma de lanzamiento.

Fase 2: Verificar nombre

python3 <skill-dir>/scripts/name_check.py <nombre> [alternativa ...]

El script verifica crates.io, npm, PyPI, Homebrew y GitHub. Un nombre compartido divide los resultados de búsqueda, por lo que las personas que oyen hablar del proyecto no pueden encontrarlo, y un nombre de registro ocupado bloquea la publicación. Si el veredicto es EVITAR o SATURADO, propón de 3 a 4 alternativas y verifícalas en la misma ejecución. Los buenos nombres dicen lo que hace la herramienta, o lo evocan, y son fáciles de deletrear después de oírlos una vez.

Renombrar es decisión del usuario. Si renombra, cambia cada aparición: manifiesto, nombre del binario, README, enlaces, CI, rutas de configuración y cadenas de agente de usuario. Usa un script que recorra los archivos en lugar de dividir palabras del shell, lo que falla con rutas que contienen espacios. Luego reconstruye y ejecuta las pruebas.

Fase 3: Auditar

python3 <skill-dir>/scripts/audit.py <ruta-del-repo>

Obtienes una puntuación sobre 100 y una lista de correcciones, ordenadas por peso. Cubre el gancho del README, un elemento visual y una línea de instalación cerca de la parte superior, la licencia y los archivos comunitarios, los flujos de trabajo de CI y lanzamiento, los secretos filtrados, los correos electrónicos personales de commit y, si gh está conectado, la descripción de GitHub, los temas, la vista previa social y los lanzamientos.

Dos hallazgos vienen antes que cualquier otro, porque no se pueden deshacer después de un push público:

• Un secreto en un archivo rastreado. Elimínalo y dile al usuario que lo rote. Ya está en el historial de git.
• Un correo electrónico personal de commit (Gmail y similares). Cada commit público lo muestra. Configura el correo del repositorio con la dirección noreply de GitHub del usuario, [email protected]. Obtén el ID con gh api user --jq .id.

Vuelve a ejecutar la auditoría al final de la fase 6. El aumento de la puntuación es la barra de progreso del usuario, así que muéstralo.

Fase 4: README como página de aterrizaje

Lee references/readme.md y reescribe el README en esa estructura. La idea central: un visitante decide en unos 10 segundos, usando solo la primera pantalla. Por lo tanto, la primera pantalla debe contener el problema, la prueba (el GIF) y el comando de instalación. La explicación viene después.

Cada afirmación en el README debe ser cierta sobre el código tal como es hoy. Verifica cada característica, indicador y número contra el código fuente o una ejecución real antes de escribirlo. Exagerar se descubre en el primer comentario de HN y cuesta más confianza de la que la afirmación gana. Pon el trabajo futuro en una sección de Roadmap, claramente marcada.

Fase 5: Demo y vista previa social

Lee references/demo.md. Elige el formato según el tipo de proyecto:

• CLI o TUI: graba un GIF con VHS, usando un archivo de cinta comprometido en docs/demo.tape, para que cualquiera pueda volver a grabarlo.
• Aplicación web: capturas de pantalla o una grabación de pantalla corta.
• Librería: un fragmento de código antes/después con salida real.

Luego crea la vista previa social:

sh <skill-dir>/scripts/social_preview.sh docs/demo.gif docs/social-preview.png

Mira los fotogramas tú mismo antes de seguir adelante. Extrae 2 o 3 fotogramas con ffmpeg y míralos. Las grabaciones fallan silenciosamente: los colores desaparecen porque NO_COLOR está configurado en el entorno, aparece un token escrito en pantalla, el texto es ilegible en la fila seleccionada o el fotograma que capturaste muestra un spinner de carga. Corrige y vuelve a grabar. Mirar los fotogramas es barato; un GIF roto en la parte superior del README no lo es.

Fase 6: Lanzamiento y CI

Lee references/release.md para el ecosistema del proyecto. El objetivo es rutas de instalación para personas que no tienen el conjunto de herramientas: binarios precompilados o un paquete publicado, a partir de un push de etiqueta. Haz que cualquier paso de publicación se salte limpiamente cuando su secreto no esté configurado, para que el primer lanzamiento del usuario no muestre un error rojo. Ejecuta los comandos de lint, formato y prueba del proyecto localmente y haz que pasen, porque CI los ejecuta en el primer push.

Fase 7: Kit de lanzamiento

python3 <skill-dir>/scripts/launch_time.py --tz <zona horaria IANA del usuario>

Esto elige el próximo martes, miércoles o jueves a las 8:30 AM hora del este de EE. UU. y convierte el cronograma a la zona horaria del usuario, siguiendo las reglas de horario de verano. Omite las semanas de elecciones en EE. UU., la semana de Acción de Gracias, Navidad a Año Nuevo y el 4 de julio, y explica por qué. No hagas la conversión mentalmente: los cambios de horario de verano de EE. UU./Europa desplazan el desfase una hora dos veces al año. Si puedes buscar en la web, también verifica la semana elegida para cualquier cosa que domine las noticias tecnológicas (un evento importante de Apple, Google u OpenAI, una gran interrupción) y cambia un día si es necesario.

Luego lee references/launch-posts.md y escribe LAUNCH.md en la carpeta principal del repositorio, o en docs/ si el usuario lo prefiere. Contiene el cronograma, una lista de verificación previa al lanzamiento, el título de Show HN y el primer comentario, 2 o 3 publicaciones de Reddit para los subreddits más adecuados, un hilo de X y el plan del día después.

La historia en las publicaciones debe ser real. Usa lo que sea realmente cierto sobre por qué existe el proyecto o lo que se aprendió al construirlo. Si no lo sabes, pídele al usuario una frase de su motivación real. Nunca inventes una historia de fondo, conteos de usuarios o un punto de referencia.

Fase 8: Entrega

Termina con un mensaje corto que tenga:

1. La puntuación de la auditoría, antes y después.
2. Lo que ahora está en el repositorio, como una lista de archivos.
3. Los comandos exactos que el usuario ejecuta para publicar, en orden: crear el repositorio público, hacer push, esperar a CI, etiquetar el lanzamiento.
4. Los pasos manuales que ninguna API puede hacer: subir la vista previa social (Settings, luego Social preview), fijar el repositorio y corregir detalles del perfil.
5. El día y hora de lanzamiento en su zona horaria, y dónde está LAUNCH.md.

Después de que digan que han publicado, ofrécete a verificar. Verifica que el repositorio sea público, que CI esté en verde, que el lanzamiento tenga activos, que el comando de instalación funcione desde un directorio limpio y que la vista previa social esté configurada (gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}').

Qué hace que un lanzamiento funcione

Estas son las ideas a las que sirven las fases. Úsalas para tomar decisiones que los pasos no cubren.

• Muestra antes de contar. Un GIF de la cosa funcionando supera a tres párrafos sobre ella.
• Una línea para probarlo. Cada paso extra antes del primer "oh, qué bien" pierde personas.
• Sé honesto y específico. "Clasifica tus repositorios por estrellas ganadas esta semana" supera a "Plataforma de análisis impulsada por IA". La audiencia de HN castiga el bombo y recompensa una historia real.
• El momento y las respuestas importan tanto como la publicación. Publica cuando la audiencia esté despierta y responde a cada comentario en las primeras 3 horas.
• Nunca pidas votos positivos o estrellas. En HN hace que la publicación sea marcada. En otros sitios se lee como spam.