launchday は何をしますか？
優秀なオープンソースプロジェクトの多くは、ローンチに失敗します。READMEは「見せる」ではなく「説明」に終始し、デモもインストール行もなく、名前は他の3つのツールと衝突し、Show HNの投稿は米国時間の午前3時になっています。このスキルはそれらすべてを一発で修正し、ユーザーが一晩で実行できるローンチ計画を手渡します。
準備はあなたが行います。ユーザーが公開作業（パブリックリポジトリの作成、タグのプッシュ、ソーシャルプレビューのアップロード、投稿）を行います。公開は取り消しが難しく、ユーザーの名義で行われるため、コピー＆ペーストが可能な状態まで準備し、そこで手を止めて引き継ぎます。
実行方法
フェーズを順番に進めてください。各フェーズは、リポジトリに具体的な成果物を生成して終了します。どのフェーズを実行しているかをユーザーに伝え、追跡できるようにしてください。
スクリプトはこのファイルと同じディレクトリの scripts/ にあります。Pythonの標準ライブラリのみを使用し（プレビュー用に ffmpeg も使用）、実行時はスキルフォルダへのパスを指定します。例: python3 <skill-dir>/scripts/audit.py .
| フェーズ | 出力 | スクリプトまたはリファレンス |
|---|---|---|
| 1. 理解 | ユーザーと確認する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）、およびエントリポイントを読みます。安全に実行できるならプロジェクトを実行します。その後、以下の3つをカバーする1段落を書きます。
- 何をするか: 非専門家でも理解できる一文で。
- 誰が困っているか: 具体的に。「10以上のリポジトリを持つメンテナー」のように、「開発者」ではなく。
- 証明の瞬間: 新しいユーザーが最初に目にし、「おっ、いいね」と思わせるもの。READMEとデモはこれを中心に構築されます。
短いメッセージでユーザーに確認します。ここでの誤った要約は、以降のすべてを台無しにします。また、自分で見つけられない情報（リポジトリをホストするGitHubアカウント、ローンチスケジュール用のタイムゾーン）も尋ねてください。
フェーズ2: 名前チェック
python3 <skill-dir>/scripts/name_check.py <名前> [代替案 ...]
スクリプトはcrates.io、npm、PyPI、Homebrew、GitHubをチェックします。名前が被ると検索結果が分散し、プロジェクトを知った人が見つけられなくなり、レジストリ名が取得済みだと公開がブロックされます。判定がAVOIDまたはCROWDEDの場合は、3～4の代替案を提案し、同じ実行でチェックしてください。良い名前は、ツールの機能を説明または連想させ、一度聞けば綴れるものです。
名前変更はユーザーの判断です。変更する場合、マニフェスト、バイナリ名、README、リンク、CI、設定パス、User-Agent文字列など、すべての出現箇所を変更します。シェルの単語分割ではなく、ファイルを走査するスクリプトを使用してください（空白を含むパスで壊れないように）。その後、リビルドしてテストを実行します。
フェーズ3: 監査
python3 <skill-dir>/scripts/audit.py <リポジトリパス>
100点満点のスコアと、重み順の修正リストが得られます。カバー範囲は、READMEのフック、先頭付近のビジュアルとインストール行、ライセンスとコミュニティファイル、CIとリリースワークフロー、漏洩したシークレット、個人のコミットメール、そしてghがログイン済みの場合はGitHubの説明、トピック、ソーシャルプレビュー、リリースです。
以下の2つは、何よりも先に処理します。公開プッシュ後は取り消し不可能だからです。
- 追跡ファイル内のシークレット: 削除し、ユーザーにローテーションを伝えます。Gitの履歴に残っています。
- 個人のコミットメール（Gmailなど）: すべての公開コミットに表示されます。リポジトリのメールをユーザーのGitHub noreplyアドレス（
[email protected]）に設定します。IDはgh api user --jq .idで取得します。
フェーズ6の最後に監査を再実行します。スコアの上昇がユーザーの進捗バーになるため、表示してください。
フェーズ4: READMEをランディングページに
references/readme.md を読み、その構造でREADMEを書き直します。核となる考え：訪問者は最初の画面だけで約10秒で判断します。そのため、最初の画面には「痛み」「証明（GIF）」「インストールコマンド」を配置しなければなりません。説明はその後です。
READMEの主張はすべて、現在のコードに基づいて真実でなければなりません。各機能、フラグ、数値をソースまたは実際の実行と照合してから記述してください。誇張は最初のHNコメントで指摘され、得られる信頼よりも多くの信頼を失います。将来の作業は「ロードマップ」セクションに明確にマークして配置します。
フェーズ5: デモとソーシャルプレビュー
references/demo.md を読みます。プロジェクトの種類に応じて形式を選びます。
- CLIまたはTUI: VHSでGIFを録画します。テープファイルを
docs/demo.tapeにコミットし、誰でも再録画できるようにします。 - Webアプリ: スクリーンショット、または短い画面録画。
- ライブラリ: 実際の出力付きのbefore/afterコードスニペット。
次にソーシャルプレビューを作成します。
sh <skill-dir>/scripts/social_preview.sh docs/demo.gif docs/social-preview.png
先に進む前に、自分でフレームを確認してください。 ffmpeg で2～3フレームを抽出し、表示します。録画は静かに失敗します：環境で NO_COLOR が設定され色が消える、トークンが画面にタイプされる、選択した行でテキストが読めない、キャプチャしたフレームにローディングスピナーが表示される、などです。修正して再録画してください。フレームを確認するのは簡単ですが、READMEの先頭で壊れたGIFを表示するのは簡単ではありません。
フェーズ6: リリースとCI
プロジェクトのエコシステムに応じて references/release.md を読みます。目標は、ツールチェーンを持たない人向けのインストールパス（タグプッシュからのプレビルドバイナリ、または公開パッケージ）です。シークレットが設定されていない場合、公開ステップはクリーンにスキップされるようにし、ユーザーの最初のリリースで赤色の失敗が表示されないようにします。プロジェクト独自のlint、フォーマット、テストコマンドをローカルで実行し、パスさせます。CIは最初のプッシュでそれらを実行するからです。
フェーズ7: ローンチキット
python3 <skill-dir>/scripts/launch_time.py --tz <ユーザーのIANAタイムゾーン>
これは次の火曜日、水曜日、または木曜日の米国東部時間午前8時30分を選び、そのスケジュールをサマータイムルールに従ってユーザーのタイムゾーンに変換します。米国の選挙週、感謝祭の週、クリスマスから新年、7月4日はスキップし、その理由を示します。変換は頭で行わないでください。米国/ヨーロッパのサマータイム変更により、オフセットが年に2回1時間ずれます。ウェブ検索ができる場合は、選択した週にテクノロジーニュースを席巻するイベント（Apple、Google、OpenAIの大規模イベント、大規模な障害）がないかも確認し、必要に応じて日付を移動します。
次に references/launch-posts.md を読み、リポジトリの親フォルダ、またはユーザーが希望する場合は docs/ に LAUNCH.md を書きます。これにはスケジュール、ローンチ前チェックリスト、Show HNのタイトルと最初のコメント、最適なサブレディットへの2～3のReddit投稿、Xスレッド、そして翌日の計画が含まれます。
投稿のストーリーは本物でなければなりません。プロジェクトが存在する理由や、構築中に学んだことについて、実際に真実であることを使用します。わからない場合は、ユーザーに実際の動機を一文尋ねてください。決してバックストーリー、ユーザー数、ベンチマークを捏造しないでください。
フェーズ8: 引き継ぎ
以下の内容を含む短いメッセージで終了します。
- 監査スコア（前後）。
- リポジトリに追加されたものの一覧（ファイルリスト）。
- ユーザーが公開のために実行する正確なコマンド（順番に：パブリックリポジトリの作成、プッシュ、CIの待機、リリースのタグ付け）。
- APIではできない手動ステップ：ソーシャルプレビューのアップロード（設定 → ソーシャルプレビュー）、リポジトリのピン留め、プロフィール詳細の修正。
- ユーザーのタイムゾーンでのローンチ日時、および
LAUNCH.mdの場所。
公開したとユーザーが言ったら、確認を申し出ます。リポジトリが公開されていること、CIがグリーンであること、リリースにアセットがあること、インストールコマンドがクリーンなディレクトリから動作すること、ソーシャルプレビューが設定されていること（gh api graphql -f query='{repository(owner:"o",name:"r"){usesCustomOpenGraphImage}}'）を確認します。
ローンチを成功させるもの
これらのアイデアが各フェーズの基盤です。ステップでカバーされていない判断に使用してください。
- 説明する前に見せる。動作するGIFは、それに関する3段落に勝ります。
- 試すための一行。「おっ、いいね」の前の追加ステップごとに人は離れます。
- 正直かつ具体的に。「今週獲得したスターでリポジトリをランク付け」は「AI搭載分析プラットフォーム」より効果的です。HNの読者は誇大広告を罰し、本当のストーリーに報います。
- タイミングと返信は投稿自体と同じくらい重要。視聴者が起きている時間に投稿し、最初の3時間ですべてのコメントに返信してください。
- アップ投票やスターを決して求めない。HNではフラグが立てられます。それ以外ではスパムと見なされます。