taufiquebuilds/launchday

Was macht launchday?

Die meisten guten Open-Source-Projekte starten schlecht: eine README, die erklärt statt zeigt, kein Demo, keine Installationszeile, ein Name, der mit drei anderen Tools kollidiert, und ein Show HN, das um 3 Uhr morgens US-Zeit gepostet wird. Dieser Skill behebt das alles in einem Durchgang und übergibt dem Nutzer einen Startplan, den er an einem Abend umsetzen kann.

Du bereitest vor. Der Nutzer macht alles Öffentliche: das öffentliche Repository erstellen, Tags pushen, die Social Preview hochladen und posten. Veröffentlichen ist schwer rückgängig zu machen und spricht im Namen des Nutzers, also bereitest du alles bis zum Punkt des Kopierens vor, dann stoppst du und übergibst.

So wird es ausgeführt

Arbeite die Phasen der Reihe nach durch. Jede Phase endet mit etwas Konkretem im Repository. Teile dem Nutzer mit, in welcher Phase du dich befindest, damit er folgen kann.

Die Skripte liegen im Ordner scripts/ neben dieser Datei. Sie verwenden nur Pythons Standardbibliothek (plus ffmpeg für die Vorschau). Führe sie mit dem Pfad zu diesem Skill-Ordner aus, z.B. python3 <skill-verz>/scripts/audit.py ..

Phase	Ausgabe	Skript oder Referenz
1. Verstehen	Ein-Absatz-Zusammenfassung, die du mit dem Nutzer bestätigst	keine
2. Namensprüfung	Entscheidung: behalten oder umbenennen	scripts/name_check.py
3. Audit	Bewertung und Liste der Korrekturen	scripts/audit.py
4. README	README als Landing Page umgeschrieben	references/readme.md
5. Demo	GIF oder Screenshot plus Social Preview	references/demo.md, scripts/social_preview.sh
6. Release	CI und Release-Workflow	references/release.md
7. Launch-Kit	LAUNCH.md mit Beiträgen und Zeitplan	references/launch-posts.md, scripts/launch_time.py
8. Übergabe	Genaue Befehle, die der Nutzer ausführen soll	keine

Wenn der Nutzer nur einen Teil möchte („repariere nur meine README“, „schreibe mein Show HN“), mache nur diese Phase. Führe trotzdem zuerst das Audit durch, wenn es günstig ist, denn es zeigt oft den wahren Engpass.

Phase 1: Das Projekt verstehen

Lies die README, das Paketmanifest (package.json, Cargo.toml, pyproject.toml, go.mod) und den Einstiegspunkt. Führe das Projekt aus, wenn du es sicher tun kannst. Schreibe dann einen Absatz, der drei Dinge abdeckt:

• Was es tut, in einem Satz, den auch ein Laie versteht.
• Wer das Problem hat. Sei spezifisch: „Entwickler mit 10+ Repos“, nicht „Entwickler“.
• Der Aha-Moment: Das Erste, was ein neuer Nutzer sieht und das ihn „oh, nice“ sagen lässt. Die README und das Demo werden darum herum aufgebaut.

Bestätige es mit dem Nutzer in einer kurzen Nachricht. Eine falsche Zusammenfassung hier vergiftet alles Weitere. Frage auch nach Dingen, die du nicht selbst finden kannst: welches GitHub-Konto das Repository hosten wird und ihre Zeitzone für den Startplan.

Phase 2: Namensprüfung

python3 <skill-verz>/scripts/name_check.py <name> [alternative ...]

Das Skript prüft crates.io, npm, PyPI, Homebrew und GitHub. Ein gemeinsamer Name spaltet die Suchergebnisse, so dass Leute, die von dem Projekt hören, es nicht finden können, und ein belegter Registry-Name blockiert die Veröffentlichung. Wenn das Urteil AVOID oder CROWDED lautet, schlage 3 bis 4 Alternativen vor und prüfe sie im selben Durchlauf. Gute Namen sagen, was das Tool tut, oder rufen es hervor, und sind nach einmaligem Hören leicht zu buchstabieren.

Die Umbenennung ist die Entscheidung des Nutzers. Wenn sie umbenennen, ändere jedes Vorkommen: Manifest, Binärname, README, Links, CI, Konfigurationspfade und User-Agent-Strings. Verwende ein Skript, das die Dateien durchläuft, anstatt Shell-Worttrennung, die bei Pfaden mit Leerzeichen versagt. Baue dann neu und führe die Tests aus.

Phase 3: Audit

python3 <skill-verz>/scripts/audit.py <repo-pfad>

Du erhältst eine Punktzahl von 100 und eine nach Gewichtung sortierte Liste von Korrekturen. Es umfasst den README-Haken, eine visuelle und eine Installationszeile oben, die Lizenz- und Community-Dateien, CI- und Release-Workflows, durchgesickerte Geheimnisse, persönliche Commit-E-Mails und, wenn gh eingeloggt ist, die GitHub-Beschreibung, Themen, Social Preview und Releases.

Zwei Befunde kommen vor allem anderen, weil sie nach einem öffentlichen Push nicht rückgängig gemacht werden können:

• Ein Geheimnis in einer versionierten Datei. Entferne es und sage dem Nutzer, es zu rotieren. Es ist bereits in der Git-Historie.
• Eine persönliche Commit-E-Mail (Gmail und ähnliche). Jeder öffentliche Commit zeigt sie. Setze die E-Mail des Repos auf die GitHub-No-Reply-Adresse des Nutzers, [email protected]. Hole die ID mit gh api user --jq .id.

Führe das Audit am Ende von Phase 6 erneut aus. Die steigende Punktzahl ist der Fortschrittsbalken des Nutzers, also zeige sie.

Phase 4: README als Landing Page

Lies references/readme.md und schreibe die README in dieser Struktur um. Die Kernidee: Ein Besucher entscheidet in etwa 10 Sekunden, nur mit dem ersten Bildschirm. Daher muss der erste Bildschirm das Problem, den Beweis (das GIF) und den Installationsbefehl enthalten. Die Erklärung kommt danach.

Jede Behauptung in der README muss für den Code so, wie er heute ist, wahr sein. Überprüfe jedes Feature, jedes Flag und jede Zahl anhand der Quelle oder eines echten Durchlaufs, bevor du sie schreibst. Übertreibungen werden im ersten HN-Kommentar aufgedeckt und kosten mehr Vertrauen, als die Behauptung einbringt. Setze zukünftige Arbeit in einen Roadmap-Abschnitt, deutlich gekennzeichnet.

Phase 5: Demo und Social Preview

Lies references/demo.md. Wähle das Format basierend auf dem Projekttyp:

• CLI oder TUI: Nimm ein GIF mit VHS auf, unter Verwendung einer Tape-Datei, die in docs/demo.tape eingecheckt ist, damit jeder es neu aufnehmen kann.
• Web-App: Screenshots oder eine kurze Bildschirmaufnahme.
• Bibliothek: Ein Vorher/Nachher-Code-Snippet mit tatsächlicher Ausgabe.

Erstelle dann die Social Preview:

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

Sieh dir die Frames selbst an, bevor du weitermachst. Extrahiere 2 oder 3 Frames mit ffmpeg und betrachte sie. Aufnahmen schlagen leise fehl: Farben verschwinden, weil NO_COLOR in der Umgebung gesetzt ist, ein Token wird auf dem Bildschirm getippt, Text ist in der ausgewählten Zeile unlesbar, oder der aufgenommene Frame zeigt einen Lade-Spinner. Korrigiere und nimm neu auf. Das Ansehen der Frames ist billig; ein kaputtes GIF oben in der README ist es nicht.

Phase 6: Release und CI

Lies references/release.md für das Ökosystem des Projekts. Das Ziel sind Installationspfade für Leute, die die Toolchain nicht haben: vorgefertigte Binärdateien oder ein veröffentlichtes Paket, ausgelöst durch einen Tag-Push. Sorge dafür, dass jeder Veröffentlichungsschritt sauber übersprungen wird, wenn sein Secret nicht gesetzt ist, damit die erste Veröffentlichung des Nutzers keinen roten Fehler anzeigt. Führe die eigenen Lint-, Format- und Testbefehle des Projekts lokal aus und bringe sie zum Laufen, da CI sie beim ersten Push ausführt.

Phase 7: Launch-Kit

python3 <skill-verz>/scripts/launch_time.py --tz <IANA-Zeitzone des Nutzers>

Dies wählt den nächsten Dienstag, Mittwoch oder Donnerstag um 8:30 Uhr US Eastern und konvertiert den Zeitplan in die Zeitzone des Nutzers, unter Berücksichtigung der Sommerzeitregeln. Es überspringt US-Wahlwochen, die Thanksgiving-Woche, Weihnachten bis Neujahr und den 4. Juli und erklärt warum. Führe die Umrechnung nicht im Kopf durch: Die US/Europa-Sommerzeitumstellung verschiebt den Offset zweimal im Jahr um eine Stunde. Wenn du im Internet suchen kannst, überprüfe auch die ausgewählte Woche auf alles, was die Techniknachrichten dominieren würde (ein großes Apple-, Google- oder OpenAI-Event, ein großer Ausfall) und verschiebe einen Tag, falls nötig.

Lies dann references/launch-posts.md und schreibe LAUNCH.md im übergeordneten Ordner des Repos oder in docs/, wenn der Nutzer das bevorzugt. Es enthält den Zeitplan, eine Checkliste vor dem Start, den Show-HN-Titel und den ersten Kommentar, 2 oder 3 Reddit-Beiträge für die am besten passenden Subreddits, einen X-Thread und den Plan für den Tag danach.

Die Geschichte in den Beiträgen muss echt sein. Verwende, was tatsächlich wahr ist, warum das Projekt existiert oder was beim Bauen gelernt wurde. Wenn du es nicht weißt, frage den Nutzer nach einem Satz seiner wahren Motivation. Erfinde niemals eine Hintergrundgeschichte, Nutzerzahlen oder einen Benchmark.

Phase 8: Übergabe

Beende mit einer kurzen Nachricht, die Folgendes enthält:

1. Die Audit-Punktzahl, vorher und nachher.
2. Was sich jetzt im Repository befindet, als Liste von Dateien.
3. Die genauen Befehle, die der Nutzer ausführt, um zu veröffentlichen, in der richtigen Reihenfolge: Erstelle das öffentliche Repo, push, warte auf CI, tagge das Release.
4. Die manuellen Schritte, die keine API erledigen kann: Hochladen der Social Preview (Einstellungen, dann Social Preview), Anheften des Repos und Korrigieren von Profildetails.
5. Den Starttag und die Startzeit in ihrer Zeitzone und wo sich LAUNCH.md befindet.

Nachdem sie gesagt haben, dass sie veröffentlicht haben, biete an, zu überprüfen. Prüfe, ob das Repo öffentlich ist, CI grün ist, das Release-Assets hat, der Installationsbefehl aus einem sauberen Verzeichnis funktioniert und die Social Preview gesetzt ist (gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}').

Was einen Start zum Erfolg macht

Dies sind die Ideen, denen die Phasen dienen. Verwende sie, um Entscheidungen zu treffen, die die Schritte nicht abdecken.

• Zeigen, bevor du erzählst. Ein GIF des funktionierenden Dings schlägt drei Absätze darüber.
• Eine Zeile zum Ausprobieren. Jeder zusätzliche Schritt vor dem ersten „oh, nice“ verliert Leute.
• Sei ehrlich und konkret. „Bewertet deine Repos nach den Sternen, die du diese Woche gewonnen hast“ schlägt „KI-gestützte Analyseplattform“. Das HN-Publikum bestraft Hype und belohnt eine echte Geschichte.
• Timing und Antworten sind genauso wichtig wie der Beitrag. Poste, wenn das Publikum wach ist, und beantworte jeden Kommentar in den ersten 3 Stunden.
• Bitte niemals um Upvotes oder Sterne. Auf HN führt das zur Markierung des Beitrags. Anderswo wirkt es wie Spam.