夜間ビルドプロンプト
完全なテンプレートは references/overnight-build-template.md にあります。作成前に必ず読んでください。 ルール構造を記憶から再導出しないでください。テンプレートの [角括弧] セクションをユーザーの具体的な内容で埋め、ユーザーが自身のコピーに加えた編集は保持してください。
不可欠な要件
すべての出力には ルール8（利用制限リセットを乗り切る） と ランチャーセクション を含めなければなりません。これらがビルドを再起動可能にする要素です。これらがないプロンプトは、最初の利用制限リセット後に静かに最初からやり直し、夜を無駄にします。
作成手順
- テンプレートを読む。 ユーザーが編集済みのコピーを保持している場合、ユーザーのコピーを優先し、その変更を保持します。
- 仕様を記入する — 何をビルドするか、コンテキスト、設計要件、技術要件、優先順位付きの機能、シードデータ、デプロイ、成功基準。ここでの具体性が全てです。曖昧な仕様は曖昧な夜を生みます。
- フェーズを設定する — 4〜8段階。各フェーズは独立して完了・検証可能で、時間配分の合計が予算に一致すること。
- ピボットプレイブック に、テンプレートの定常的なブロッカーに加えて、プロジェクト固有のブロッカーを記入します。
- ランチャーの種類を1回だけ尋ねる（A: OSスケジューラ · B: bashループ · C: スケジュールタスクMCP）。リクエストに明示されていない場合のみ。1回だけ尋ね、その後は進めます。
- 単一のコピー可能なコードブロックとして出力し、プロジェクトルートに
overnight-build-prompt.txtとして保存してから起動するようユーザーに注意を促します。
完了シグナル
プロンプトは、ビルドが最終行として BUILD_COMPLETE を出力するよう指示しなければなりません — bashループランナーはこれをgrepして終了します。プロンプト内で明示的に、P0基準のいずれかが真に満たされていない場合、BUILD_COMPLETE を出力しないことが正しい動作である と述べてください。未完了のビルドでランナーが終了するのは、継続するよりも悪い結果を招きます。
ガードレール
無人エージェントには質問できる相手がいないため、プロンプトは自身の境界を持たなければなりません。
ターゲットが既存の本番コードベースの場合、まずファイルの所有権とDO-NOTリストを導出し（fleet-brief スキルが両方を生成します）、プロジェクトの検証チェックをテストフェーズに組み込んで、「完了」が「マージされた」ではなく「検証された」を意味するようにします。
夜間プロンプトに決して許可してはいけないこと： データベースマイグレーションの適用、スキーマのプッシュ、ホスティングCLIを介したデプロイ、電話番号やドメインの購入・リリース、実際の連絡先への送信メッセージ。これらには人間が起きている必要があります。プロジェクト固有の不可逆操作もそのリストに追加してください。
ビルドが書き出すべき成果物
BUILD_LOG.md— フェーズエントリ、決定、ピボット、既知の問題、および正確な次のステップを示す## CHECKPOINT — <ISO>ブロックRESEARCH_NOTES.md— 実装開始前の調査結果
再開時、ビルドの最初のアクションは BUILD_LOG.md を最初から最後まで読み、最新のチェックポイントから続行することです — 再調査、再スキャフォールディング、再起動は決して行わないでください。