taufiquebuilds/launchday

Que fait launchday ?

La plupart des bons projets open source sont lancés de manière médiocre : un README qui explique au lieu de montrer, pas de démo, pas de ligne d'installation, un nom qui entre en collision avec trois autres outils, et un Show HN posté à 3 heures du matin (heure US). Cette compétence résout tout cela en une seule passe, puis remet à l'utilisateur un plan de lancement qu'il peut exécuter en une soirée.

Vous faites la préparation. L'utilisateur fait tout ce qui est public : créer le dépôt public, pousser les tags, téléverser la preview sociale et poster. Publier est difficile à annuler et se fait en son nom, donc vous préparez tout jusqu'au point où il suffit de copier-coller, puis vous vous arrêtez et lui passez la main.

Comment l'exécuter

Travaillez à travers les phases dans l'ordre. Chaque phase se termine par quelque chose de concret dans le dépôt. Dites à l'utilisateur sur quelle phase vous êtes, afin qu'il puisse suivre.

Les scripts se trouvent dans scripts/ à côté de ce fichier. Ils n'utilisent que la bibliothèque standard de Python (plus ffmpeg pour la preview). Exécutez-les avec le chemin du dossier de cette compétence, par exemple python3 <skill-dir>/scripts/audit.py ..

Phase	Résultat	Script ou référence
1. Comprendre	Résumé d'un paragraphe que vous confirmez avec l'utilisateur	aucun
2. Vérification du nom	Décision de conserver ou de renommer	scripts/name_check.py
3. Audit	Score et liste de correctifs	scripts/audit.py
4. README	README réécrit en page d'accueil	references/readme.md
5. Démo	GIF ou capture d'écran plus preview sociale	references/demo.md, scripts/social_preview.sh
6. Release	CI et workflow de release	references/release.md
7. Kit de lancement	LAUNCH.md avec posts et calendrier	references/launch-posts.md, scripts/launch_time.py
8. Passation	Commandes exactes pour l'utilisateur	aucun

Si l'utilisateur n'a demandé qu'une seule partie (« corrige juste mon README », « écris mon Show HN »), faites cette phase. Exécutez quand même l'audit d'abord si c'est peu coûteux, car il révèle souvent le vrai problème.

Phase 1 : Comprendre le projet

Lisez le README, le manifeste du paquet (package.json, Cargo.toml, pyproject.toml, go.mod) et le point d'entrée. Exécutez le projet si vous pouvez le faire en toute sécurité. Ensuite, rédigez un paragraphe couvrant trois points :

• Ce qu'il fait, en une phrase qu'un non-expert comprend.
• Qui a le problème. Soyez précis : « les mainteneurs avec 10+ dépôts », pas « les développeurs ».
• Le moment de preuve : la première chose qu'un nouvel utilisateur voit et qui lui fait dire « oh, sympa ». Le README et la démo sont construits autour de cela.

Confirmez-le avec l'utilisateur en un court message. Un mauvais résumé ici empoisonne tout ce qui suit. Demandez aussi tout ce que vous ne pouvez pas trouver vous-même : quel compte GitHub hébergera le dépôt, et son fuseau horaire pour le calendrier de lancement.

Phase 2 : Vérification du nom

python3 <skill-dir>/scripts/name_check.py <nom> [alternative ...]

Le script vérifie crates.io, npm, PyPI, Homebrew et GitHub. Un nom partagé divise les résultats de recherche, donc les personnes qui entendent parler du projet ne peuvent pas le trouver, et un nom de registre déjà pris bloque la publication. Si le verdict est ÉVITER ou ENCOMBRÉ, proposez 3 à 4 alternatives et vérifiez-les dans la même exécution. Les bons noms disent ce que fait l'outil, ou l'évoquent, et sont faciles à épeler après les avoir entendus une fois.

Renommer est la décision de l'utilisateur. S'il renomme, changez chaque occurrence : manifeste, nom du binaire, README, liens, CI, chemins de configuration et chaînes user-agent. Utilisez un script qui parcourt les fichiers plutôt qu'un découpage de mots du shell, qui échoue sur les chemins avec des espaces. Ensuite, reconstruisez et exécutez les tests.

Phase 3 : Audit

python3 <skill-dir>/scripts/audit.py <chemin-du-dépôt>

Vous obtenez un score sur 100 et une liste de correctifs, triés par poids. Cela couvre l'accroche du README, un visuel et une ligne d'installation près du haut, la licence et les fichiers communautaires, les workflows CI et de release, les secrets divulgués, les emails de commit personnels, et, si gh est connecté, la description GitHub, les sujets, la preview sociale et les releases.

Deux résultats passent avant tout le reste, car ils ne peuvent pas être annulés après un push public :

• Un secret dans un fichier suivi. Supprimez-le et dites à l'utilisateur de le faire tourner. Il est déjà dans l'historique git.
• Une adresse email de commit personnelle (Gmail et similaires). Chaque commit public l'affiche. Définissez l'email du dépôt sur l'adresse noreply GitHub de l'utilisateur, [email protected]. Obtenez l'ID depuis gh api user --jq .id.

Réexécutez l'audit à la fin de la phase 6. Le score qui monte est la barre de progression de l'utilisateur, alors montrez-la.

Phase 4 : README en page d'accueil

Lisez references/readme.md et réécrivez le README dans cette structure. L'idée centrale : un visiteur décide en environ 10 secondes, en utilisant uniquement le premier écran. Donc, le premier écran doit contenir le problème, la preuve (le GIF) et la commande d'installation. L'explication vient après.

Chaque affirmation dans le README doit être vraie par rapport au code tel qu'il est aujourd'hui. Vérifiez chaque fonctionnalité, drapeau et nombre par rapport à la source ou à une exécution réelle avant de l'écrire. Les exagérations sont repérées dans le premier commentaire HN, et cela coûte plus de confiance que ce que l'affirmation ne rapporte. Mettez le travail futur dans une section Roadmap, clairement marquée.

Phase 5 : Démo et preview sociale

Lisez references/demo.md. Choisissez le format en fonction du type de projet :

• CLI ou TUI : enregistrez un GIF avec VHS, en utilisant un fichier tape committé dans docs/demo.tape, afin que n'importe qui puisse le ré-enregistrer.
• Application web : captures d'écran, ou un court enregistrement d'écran.
• Bibliothèque : un extrait de code avant/après avec une sortie réelle.

Ensuite, créez la preview sociale :

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

Regardez les images vous-même avant de continuer. Extrayez 2 ou 3 images avec ffmpeg et visualisez-les. Les enregistrements échouent silencieusement : les couleurs disparaissent parce que NO_COLOR est défini dans l'environnement, un token est tapé à l'écran, le texte est illisible sur la ligne sélectionnée, ou l'image récupérée montre un spinner de chargement. Corrigez et ré-enregistrez. Regarder les images ne coûte rien ; un GIF cassé en haut du README est autrement catastrophique.

Phase 6 : Release et CI

Lisez references/release.md pour l'écosystème du projet. L'objectif est des chemins d'installation pour les personnes qui n'ont pas la chaîne d'outils : binaires pré-construits, ou un paquet publié, à partir d'un push de tag. Faites en sorte que toute étape de publication soit ignorée proprement lorsque son secret n'est pas défini, afin que la première release de l'utilisateur n'affiche pas un échec rouge. Exécutez les commandes de lint, de formatage et de test du projet localement, et faites-les passer, car CI les exécute lors du premier push.

Phase 7 : Kit de lancement

python3 <skill-dir>/scripts/launch_time.py --tz <fuseau horaire IANA de l'utilisateur>

Cela sélectionne le mardi, mercredi ou jeudi suivant à 8h30 (heure de l'Est US) et convertit le calendrier dans le fuseau horaire de l'utilisateur, en suivant les règles d'heure d'été. Cela ignore les semaines d'élection américaines, la semaine de Thanksgiving, Noël au Nouvel An et le 4 juillet, et explique pourquoi. Ne faites pas la conversion de tête : les changements d'heure d'été US/Europe décalent le décalage d'une heure deux fois par an. Si vous pouvez chercher sur le web, vérifiez également si la semaine choisie contient quelque chose qui dominerait l'actualité tech (un événement majeur Apple, Google ou OpenAI, une grosse panne) et décalez d'un jour si nécessaire.

Ensuite, lisez references/launch-posts.md et écrivez LAUNCH.md dans le dossier parent du dépôt, ou dans docs/ si l'utilisateur préfère. Il contient le calendrier, une liste de vérification pré-lancement, le titre et le premier commentaire Show HN, 2 ou 3 posts Reddit pour les subreddits les plus appropriés, un fil X, et le plan du lendemain.

L'histoire dans les posts doit être réelle. Utilisez ce qui est vraiment vrai sur la raison pour laquelle le projet existe ou ce qui a été appris en le construisant. Si vous ne savez pas, demandez à l'utilisateur une phrase sur sa réelle motivation. N'inventez jamais d'histoire, de nombres d'utilisateurs ou de benchmark.

Phase 8 : Passation

Terminez par un court message qui contient :

1. Le score d'audit, avant et après.
2. Ce qui se trouve maintenant dans le dépôt, sous forme de liste de fichiers.
3. Les commandes exactes que l'utilisateur exécute pour publier, dans l'ordre : créer le dépôt public, pousser, attendre CI, tagger la release.
4. Les étapes manuelles qu'aucune API ne peut faire : téléverser la preview sociale (Paramètres, puis Preview sociale), épingler le dépôt et corriger les détails du profil.
5. Le jour et l'heure de lancement dans son fuseau horaire, et où se trouve LAUNCH.md.

Après qu'il a dit avoir publié, proposez de vérifier. Vérifiez que le dépôt est public, que CI est vert, que la release a des artefacts, que la commande d'installation fonctionne depuis un répertoire propre, et que la preview sociale est définie (gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}').

Ce qui fait qu'un lancement fonctionne

Voici les idées que les phases servent. Utilisez-les pour prendre des décisions que les étapes ne couvrent pas.

• Montrer avant de dire. Un GIF de l'outil en action bat trois paragraphes à son sujet.
• Une ligne pour l'essayer. Chaque étape supplémentaire avant le premier « oh, sympa » fait perdre des gens.
• Soyez honnête et précis. « Classe vos dépôts par étoiles gagnées cette semaine » bat « plateforme d'analyse basée sur l'IA ». Le public HN punit l'exagération et récompense une vraie histoire.
• Le timing et les réponses comptent autant que le post. Postez quand le public est réveillé et répondez à chaque commentaire dans les 3 premières heures.
• Ne demandez jamais de votes positifs ou d'étoiles. Sur HN, le post est signalé. Ailleurs, ça ressemble à du spam.