デイリーマスタープロンプトを作成する
概要
デイリーマスタープロンプトは、DAILY_PROMPT.md という1つの自己完結型ファイルです。新しいセッションはこれを実行するだけで、プロジェクトを再開し、1日の作業を行い、次の日のために準備を整えることができます。プロジェクトの記憶は会話ではなく、このファイルと並ぶ5つの状態ファイルに保持されます。初回実行後、ユーザーは次のように入力するだけです：
Read <folder>/DAILY_PROMPT.md and execute it.
ユーザーからの入力：$ARGUMENTS（フォルダと/またはプロジェクトの説明。どちらかが欠けていても構いません）。
完了時に存在するもの
すべてプロジェクトフォルダ（<folder>）内に、${CLAUDE_SKILL_DIR}/templates/ のテンプレートから生成されます：
| ファイル | 保持する内容 | 変更のタイミング |
|---|---|---|
DAILY_PROMPT.md | ミッション、マイルストーン、ルール、コンテキストマップ、セッション手順 | ユーザーが依頼した場合のみ |
BACKLOG.md | IDとステータスを持つ、順序付けられた作業項目 | 実行のたび |
DEVLOG.md | 各実行の日付付きログ（追記専用） | 実行のたび |
HANDOFF.md | 現在の状態、次の3つのアクション、警告 | 実行のたびに書き換え |
QUESTIONS.md | ユーザーへの質問（各質問に推奨事項付き） | 実行時に質問、ユーザーが回答 |
APPROVALS.md | リスクのある、または不可逆的なアクションの承認待ち | 実行時にリクエスト、ユーザーが決定 |
進捗は状態ファイルに記録されます。DAILY_PROMPT.md は、何週間も変わらない情報のみを保持します。
手順
- フォルダを見つける。 引数にフォルダが指定されていればそれを使用します。それ以外の場合は、プロジェクトの仕様やコードが置かれているフォルダを使用します。複数該当する場合は質問します。
- 質問ではなく読み取りによってコンテキストを収集する。 ユーザーの説明、
README*、CLAUDE.md、AGENTS.md、仕様書（GDD、PRD、ロードマップ、docs/）、git log --oneline -30とgit status、2〜3階層のファイルツリー、ビルド・テスト・リント・実行コマンドを明らかにするマニフェストやスクリプト、作業に必要な接続済みMCPサーバー、TODO/FIXMEノート、既存の状態ファイル。完了したことと未完了のことを区別します。 - ファイルに記載されていないことだけを質問する。 1回のAskUserQuestion呼び出しで（最大4質問）、以下のリストから質問します：現在のマイルストーンとその完了の定義、完了した項目の検証方法、ハードルール（公開/デプロイ禁止、新しい依存関係の前に確認、ブランチとプッシュのポリシー）、実行が有人か無人か、またはその両方か。誰も回答しない場合は、最も安全な読み取り（無人、プッシュなし、公開なし）を採用し、各仮定を
QUESTIONS.mdに「回答があるまで仮定」という行とともに記録します。 DAILY_PROMPT.mdをDAILY_PROMPT.template.mdから作成する。 すべてのセクションに、このプロジェクトの実際のパス、コマンド、ツール、マイルストーンを記述します。daily lineには、絶対パスではなく、リポジトリルート（ユーザーがClaudeを開く場所）からの相対パスでフォルダを記述します。フォルダがルート自身である場合、行はRead DAILY_PROMPT.md and execute it.となります。プロジェクトの実行やテストが実際のデータ（ユーザーファイル、ライブアカウント、本番環境、公開された場所）に影響を与える可能性がある場合は、代わりに一時的またはテスト用のコピーを使用する基本ルールと検証方法を追加します。- 状態ファイルをテンプレートから作成する。 既に存在する場合は、マージします。ユーザーの履歴を上書きしたり並べ替えたりしないでください。
BACKLOG.mdには、マイルストーン、仕様のギャップ、TODO、ユーザーの目標から項目をシードし、項目1が今日開始でき、各項目が1回のセッションに収まるように順序付け、各項目に具体的な「完了条件」を設定します。HANDOFF.mdには開始状態をシードします。テンプレートのエントリ例がまだ該当しない場合は、ヘッダーとフォーマット行を保持し、エントリの代わりにNone yet.と記述します。 チェック：grep -n "{{" <folder>/*.mdが何も返さないことを確認します。 - 新しいファイルをコミットする。 フォルダがgitリポジトリ内にある場合（
chore: add daily master prompt）、リポジトリのコミットルールに従います。 - 初回実行。 ユーザーが不要と言わない限り、新しいセッションが行うのとまったく同じように、今すぐ
DAILY_PROMPT.mdを実行します。これがプロンプトのテストです。手順が曖昧だったり、失敗したり、ファイルにない知識が必要だった場合は、プロンプトを修正し、その修正をDEVLOG.mdに記録します。 - 引き継ぎ。 ユーザーに、作成したもの、初回実行で行ったこと、そしてdaily lineをコードブロックで伝えます：
Read <folder>/DAILY_PROMPT.md and execute it./daily-master-prompt:run <folder>も同じ意味であること、そしてこの行をスケジュールされたタスクのプロンプトとしても使用できることを伝えます。
既存プロンプトの更新
DAILY_PROMPT.md が既に存在する場合、まずそれとすべての状態ファイルを読み取ります。変更をその場で適用するか、ユーザーが追記を依頼した場合は ## Addenda の下に日付付きエントリとして追加します。すべての状態を保持します。変更を DEVLOG.md に記録します。
よくある間違い
| 間違い | 結果 | 代わりに行うこと |
|---|---|---|
| 汎用的なプロンプト（「プロジェクトに取り組む」） | 実行のたびにプロジェクトを再発見する | 実際のパス、コマンド、マイルストーン、完了の定義 |
進捗を DAILY_PROMPT.md に書き込む | プロンプトが古くなり、状態ファイルと矛盾する | 進捗は BACKLOG/HANDOFF/DEVLOG に記録 |
| 検証手順がない | 「完了」した項目が機能しない | 項目ごとに具体的なチェック（テスト、ビルド、プレイテスト、リント） |
| 実行が最初の障害で止まる | 無人日は何も生産されない | QUESTIONS/APPROVALS に記録し、次の項目を続行 |
| バックログ項目が大きすぎる | 毎日中途半端な作業になる | 1項目が1セッションに収まるまで分割 |
| 既存の状態ファイルを上書きする | ユーザーが履歴を失う | マージ |