taufiquebuilds/launchday

launchday 是做什麼的？

大多數優秀的開源專案都以失敗的方式發布：README 只會解釋卻不會展示、沒有示範、沒有安裝指令、名稱與其他三個工具衝突，並且在美國時間凌晨 3 點張貼 Show HN。這個技能會一次解決所有這些問題，然後交給使用者一份他們可以在一個晚上執行的發布計畫。

你負責準備工作。使用者負責任何公開的事務：建立公開儲存庫、推送標籤、上傳社群預覽圖以及發文。發布很難撤銷，而且是以他們的名義發言，所以你將一切準備到只需複製貼上的程度，然後停下來交給他。

如何執行

依序執行各個階段。每個階段都會在儲存庫中留下具體的產出。告知使用者你正在進行哪個階段，以便他們跟上進度。

腳本位於此檔案旁邊的 scripts/ 目錄中。它們僅使用 Python 標準函式庫（外加用於預覽圖的 ffmpeg）。使用此技能資料夾的路徑來執行它們，例如 python3 <skill-dir>/scripts/audit.py .。

階段	產出	腳本或參考文件
1. 理解	一段摘要，需與使用者確認	無
2. 名稱檢查	保留或重新命名的決定	scripts/name_check.py
3. 稽核	分數與修正清單	scripts/audit.py
4. README	改寫為登陸頁面的 README	references/readme.md
5. 示範	GIF 或螢幕截圖，加上社群預覽圖	references/demo.md, scripts/social_preview.sh
6. 發布	CI 與發布工作流程	references/release.md
7. 啟動套件	包含貼文與時程的 LAUNCH.md	references/launch-posts.md, scripts/launch_time.py
8. 交接	使用者需要執行的確切指令	無

如果使用者只要求其中一部分（「只要修正我的 README」、「幫我寫 Show HN」），就只執行那個階段。但如果成本不高，仍請先執行稽核，因為它通常會揭露真正的阻礙。

階段 1：理解專案

閱讀 README、套件清單（package.json、Cargo.toml、pyproject.toml、go.mod）以及進入點。如果安全無虞，試著執行專案。然後撰寫一段涵蓋三件事的摘要：

• 它做什麼，用一句非專家也能理解的話說明。
• 誰有這個痛點。 要具體：「維護 10 個以上儲存庫的維護者」，而不是「開發者」。
• 證明時刻：新使用者看到後會說「哦，真不錯」的第一件事。README 和示範都是圍繞這個來建立的。

用簡短的訊息與使用者確認。錯誤的摘要會毒害所有下游工作。同時也詢問你無法自行找到的任何資訊：哪個 GitHub 帳號將託管該儲存庫，以及他們用於發布時程的時區。

階段 2：名稱檢查

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

此腳本會檢查 crates.io、npm、PyPI、Homebrew 和 GitHub。名稱衝突會分散搜尋結果，導致聽說此專案的人找不到它，而已被佔用的註冊表名稱則會阻擋發布。如果判定結果為 AVOID 或 CROWDED，請提出 3 到 4 個替代名稱，並在同一次執行中檢查它們。好的名稱要能說明或暗示工具的功能，並且容易在聽過一次後就能拼寫出來。

重新命名與否由使用者決定。如果他們決定重新命名，請更改所有出現的地方：清單、二進位檔名稱、README、連結、CI、設定路徑和使用者代理字串。使用能走訪檔案的腳本，而不是 shell 的單詞分割，因為後者在路徑包含空格時會出錯。然後重新建置並執行測試。

階段 3：稽核

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

你會得到一個滿分 100 的分數以及一個按權重排序的修正清單。它涵蓋了 README 鉤子、靠近頂部的視覺元素和安裝指令、授權和社群文件、CI 和發布工作流程、洩漏的密碼、個人提交電子郵件，以及如果已登入 gh，還包括 GitHub 描述、主題、社群預覽圖和版本。

有兩個發現結果優先於其他所有事項，因為它們在公開推送後就無法挽回：

• 追蹤檔案中的密碼。 移除它，並告訴使用者去輪換它。它已經在 git 歷史中了。
• 個人提交電子郵件（Gmail 等）。每一次公開提交都會顯示它。將儲存庫的電子郵件設為使用者的 GitHub noreply 地址，[email protected]。從 gh api user --jq .id 取得 ID。

在階段 6 結束時重新執行稽核。分數上升就是使用者的進度條，所以請顯示它。

階段 4：將 README 改寫為登陸頁面

閱讀 references/readme.md 並按照該結構改寫 README。核心概念：訪客大約在 10 秒內，僅透過第一個畫面做出決定。因此，第一個畫面必須包含痛點、證明（GIF）和安裝指令。說明則放在後面。

README 中的每個宣稱都必須與當前的程式碼相符。在撰寫之前，請根據原始碼或實際執行檢查每個功能、標誌和數字。過度宣稱會在 HN 的第一則留言中被發現，而且它所消耗的信任遠多於宣稱所帶來的。將未來的工作放在「路線圖」章節中，並明確標示。

階段 5：示範和社群預覽圖

閱讀 references/demo.md。根據專案類型選擇格式：

• CLI 或 TUI： 用 VHS 錄製 GIF，並將 tape 檔案提交到 docs/demo.tape，以便任何人都可以重新錄製。
• Web 應用程式： 螢幕截圖，或一段簡短的螢幕錄影。
• 函式庫： 一個包含真實輸出的前後對比程式碼片段。

然後製作社群預覽圖：

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

在繼續之前，親自查看這些影格。 使用 ffmpeg 提取 2 或 3 個影格並檢視它們。錄製會悄悄地失敗：因為環境中設定了 NO_COLOR 而導致顏色消失、Token 被打字顯示在畫面上、文字在所選列上無法閱讀，或者你抓取的影格顯示的是載入轉圈圈。修正並重新錄製。查看影格的成本很低；而 README 頂端有一個壞掉的 GIF 則不然。

階段 6：發布和 CI

閱讀 references/release.md 以了解專案所屬生態系。目標是為沒有工具鏈的人提供安裝途徑：從標籤推送中產生預先建置的二進位檔，或發布套件。讓任何發布步驟在未設定其密鑰時能優雅地跳過，這樣使用者的第一次發布就不會顯示紅色的失敗訊息。在本機執行專案自己的 lint、格式化與測試指令，並讓它們通過，因為 CI 會在第一次推送時執行它們。

階段 7：啟動套件

python3 <skill-dir>/scripts/launch_time.py --tz <user's IANA time zone>

這會選取下週的星期二、星期三或星期四的美國東部時間早上 8:30，並將時程轉換為使用者的時區，同時遵循日光節約規則。它會跳過美國選舉週、感恩節週、聖誕節到新年期間以及 7 月 4 日，並說明原因。不要在你的腦中進行轉換：美國/歐洲的日光節約變更每年會使時區偏移兩次，各一個小時。如果你可以搜尋網路，也請檢查所選的週是否有任何會主導科技新聞的大事（Apple、Google 或 OpenAI 的重大活動、大規模中斷），必要時將日期延後一天。

然後閱讀 references/launch-posts.md，並在儲存庫的父資料夾中（或如果使用者偏好，在 docs/ 中）撰寫 LAUNCH.md。其中包含時程、發布前檢查清單、Show HN 標題和第一則留言、針對最適合的子版塊的 2 或 3 篇 Reddit 貼文、一條 X 推文串，以及隔天計畫。

貼文中的故事必須是真實的。使用關於專案存在原因或建置過程中學到的事情中實際為真的事物。如果你不知道，請向使用者詢問一句他們真正的動機。絕不要編造背景故事、使用者數量或基準測試。

階段 8：交接

最後用一條簡短的訊息總結，內容包括：

1. 稽核分數（前後對比）。
2. 現在儲存庫中有哪些東西，以檔案清單形式列出。
3. 使用者發布所需執行的確切指令，依序為：建立公開儲存庫、推送、等待 CI、為版本打標籤。
4. 沒有 API 能做到的手動步驟：上傳社群預覽圖（設定 -> 社群預覽圖）、釘選儲存庫，以及修正個人檔案細節。
5. 其時區的發布日期和時間，以及 LAUNCH.md 的位置。

在使用者告知已發布之後，主動提出要驗證。檢查儲存庫是否已公開、CI 是否為綠色、版本是否包含資產、安裝指令是否能從一個乾淨的目錄中正常執行，以及社群預覽圖是否已設定（gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}'）。

什麼讓發布成功

以下是各階段所服務的理念。使用它們來處理步驟未涵蓋的狀況。

• 先展示，再解說。 一張工具運作的 GIF 勝過三段關於它的文字。
• 一行指令就能試用。 在第一次「哦，真不錯」之前，每多一個步驟就會流失使用者。
• 誠實且具體。「依照本週獲得的星星數排名你的儲存庫」勝過「AI 驅動的分析平台」。HN 的讀者會懲罰誇大，並獎勵真實的故事。
• 時機和回覆與貼文本身同樣重要。 在受眾清醒時發文，並在前 3 小時內回覆每一則留言。
• 絕不要要求按讚或星星。 在 HN 上這會讓貼文被標記；在其他地方則會被視為垃圾郵件。