LaunchRepoCLIを使ってください： 最良の結果を得るには、デスクトップアプリではなく、常にClaude Code CLIまたはCodex CLIを使ってください。
ワークスペースとダッシュボードの準備ができたら、エージェントはONBOARDING.mdに従って、検証済みの情報源からファイルを埋め、既存の回答は再利用します。セッションが途中で止まっても、onboarding.jsonとSESSION.mdに次のアクションが残ります。
フェーズ1〜2：全体像の説明とプライベートな保存場所
エージェントはまず計画を説明します。プロダクトを理解する、ブラウザと認証用のメールボックスを接続する、掲載やウェブサイトのバッジをどのように公開してよいかを取り決める、そして今後のセッションのためにセットアップを保存する、という流れです。最初のプロダクトの名前、URL、ローカルのコードフォルダを尋ね、ほかの質問をする前にそれらを読み込みます。また、このセッションで実際に何ができるかも確認します。ターミナルがあるだけではブラウザを操作できるわけではなく、キットは、セッションから呼び出せないツールを使えると主張することを禁じています。
フェーズ2では、あなたのデータのためのプライベートな保存場所を用意します。エージェントがまだ購入した配布用リポジトリの中にいる場合は、3ステップのスタートで作成される独立したワークスペースを初期化し、あなた専用のプライベートなリモートの設定を手伝います。ログイン情報を保存することに同意した場合、その情報はそのプライベートリポジトリに保存されること――つまり、アクセス権を持つ人なら誰でも履歴も含めて読めること――そして配布用リポジトリには決して保存されないことを、エージェントははっきりと伝えます。オーナー、リポジトリ、公開範囲の確認結果、認証情報の保存方法はworkspace.jsonに記録されます。シークレットマネージャーを使う場合は、参照だけが保存されます。
フェーズ3：プロダクトブリーフとローンチ日
エージェントは短い小文字のスラッグを指定してscripts/new-product.pyを実行し、あなたの回答をもとにproduct.jsonを埋めます。これは、すべてのプレイブックが参照するプロダクトコンテキストファイルです。対象ユーザー、課題、差別化要素、実際の機能、価格またはトライアル、ローンチの段階、本物のスクリーンショットとロゴが含まれます。できあがったコピーはあなたに提示され、修正を加えられます。恥ずかしい掲載を防ぐためのルールが2つあります。機能を競合製品から推測して書くことはなく、予定している機能を提供中のものとして書くこともありません。不明な項目は空欄のままにします。
このフェーズでは、最初のローンチをいつ公開したいか、そしてそれより前には何も公開してはいけない日付があるかどうかも尋ねます。その際エージェントは、無料枠のディレクトリは申請を審査待ちの列に入れるため、公開まで数日ではなく数週間かかることがある、とはっきり警告します。あなたの回答はproduct.jsonのearliest_launch_dateになります。これが、後でrecord.pyが適用するローンチ日の下限です。
続いてidentity.jsonに、あなたが許可した公開用の名前、連絡先メールアドレス、ニックネーム、組織に関する情報を記録します。非公開のアカウント用メールアドレスは、公開用の連絡先アドレスとは分けて管理します。これらの情報が掲載に使われる前に、エージェントは短い紹介文ブリーフィングを実施します。
フェーズ4：Chromeとメールボックス
エージェントはChrome接続ガイドに沿って、Chromeのリモートデバッグ画面と必要なmacOSの権限の設定を案内し、公開ページで目に見える動作確認を行います。接続したブラウザでウェブメールにログインするのは、あなた自身です。エージェントは、メッセージをコピーすることなく、それが意図したアカウントであることを確認します。登録や掲載は認証メールによって完了するため、メールボックスへのアクセス範囲はauthorizations.jsonに記録されます。コードを手作業で転送する方法もフォールバックとしてサポートされており、その場合は自動アクセスではなく人への引き継ぎとして記録されます。
フェーズ5：権限はプロダクトごとに1回だけ取り決める
エージェントは、プロダクトのウェブサイトのコードがどこにあるか、どのようにデプロイしているか、本番ブランチはどれか、正規URLは何かを尋ねます。そして、後々の手間を最も減らしてくれる質問をします。そのプロダクトのフッターに公式のディレクトリバッジを追加し、コミット、プッシュ、再デプロイしてよいか、という質問です。範囲、回答、日付、許可されたリポジトリとブランチはauthorizations.jsonに記録されます。「いいえ」と答えても、バッジを必要としないディレクトリへの申請が妨げられることはありません。同じファイルには、無料の登録、無料の最終申請、特定の認証メールでの操作が許可されているかどうかも記録されます。支出はゼロのままで、あるプロダクトに対する許可が別のプロダクトに及ぶことはありません。
フェーズ6〜7：ランを計画し、進捗を保持する
セットアップが終わると、エージェントはdoctor.pyを実行し、足りないセットアップと、あなたが意図的に断った権限とを区別します。ランプランナーを開き、新規の確認済み申請10件、並列は最大2件から始めてください。ローカルのハードウェアに基づく推奨値は、あくまで出発点です。メモリに余裕がない場合、マシンの負荷が高い場合、ブラウザを別々に操作できない場合は、ワーカーを1つにしてください。並列で作業する前に、エージェントは各ワーカーに専用の担当プラットフォームと分離されたブラウザ環境が割り当てられているかを確認します。関連するプレイブックを選んで適合する理由を説明し、利用可能な無料ルートから始めます。既存の掲載を検索し、申請先を確認し、正確なコピーを用意し、料金が発生しないことを確かめ、許可の範囲内で申請し、実際の結果を記録する、という流れです。最初の成果は、公開ページではなく審査待ちの申請であることもよくあります。詳しくは結果の記録ガイドを参照してください。
エージェントが/goalに対応していれば、保存したランのプロンプトで使います。対応していなければ、プロンプトを通常のメッセージとして貼り付けてください。狙いは、最初の結果が出たところで止まらず、取り決めたランを最後までやり遂げることです。審査待ち、キュー登録済み、予約済み、公開中のいずれかになった確認済みの新規申請は、プラットフォームごとに1件として数えます。下書き、既存の掲載、有料ルート、人への引き継ぎは数えません。エージェントは結果を1件ずつ記録し、証跡を保存してから、その申請に割り当てたウィンドウだけを閉じ、適切な代替先で作業を続けます。未保存のフォームと人への引き継ぎは、そのまま残します。
セッションを一時停止または終了するとき、エージェントは実際に確認できたチェックだけでonboarding.jsonを更新し、機密性のない証跡と未完了の手順をSESSION.mdに、フォローアップの日付をFOLLOW-UP.mdに書き込みます。そのうえで、完了したこと、保留中のこと、あなたの対応待ちのこと、次にやることをまとめます。プッシュの前には毎回、gitのプライバシーチェックが実行されます。良い最初のセッションだったかどうかは、次のエージェントが何も登録し直すことなく、継続的な権限を二度尋ねることもなく作業を続けられるかどうかでわかります。これが全体の流れのどこに位置するかは、仕組みのページで確認できます。