dev-resume

チェックポイントから再開する

ステップ 0：プロジェクトのルートを特定する

検出スクリプトを実行します：

bash "$DISCOVER" root

$DISCOVER は、このスキルのディレクトリ内にある scripts/discover.sh の絶対パスです。

パスの安全性 — ツール呼び出し間でシェルの状態は保持されないため、呼び出しのたびにスクリプトのフルパスを指定する必要があります：

• ホームディレクトリを直接記述せず、$HOME を使用してください（例：bash "$HOME/code/…/discover.sh"。bash "/Users/name/…/discover.sh" とはしないでください）。ユーザー名の誤生成を防げます。
• ツールの出力から値をコピーしてください。 前のコマンドが返した値（$PROJECT_ROOT など）を再利用する場合は、そのコマンドの出力から一字一句そのままコピーしてください。パスを記憶から入力し直さないでください。
• 最初の呼び出しで確認してください：スクリプト呼び出しが「No such file」で失敗した場合、パスが間違っています — 停止し、スキル読み込みのコンテキストからパスを導き直してください。
• ゼロ以外の終了コードを無視しないでください。 このスキル内のスクリプトが失敗した場合は、続行せずに停止し、エラーを報告してください。

出力を $PROJECT_ROOT として保存します。コマンドが失敗した場合は、ユーザーに伝えて停止してください。

ステップ 1：再開する機能を特定する

検出スクリプトを実行して、チェックポイントを検索します：

bash "$DISCOVER" checkpoints "$PROJECT_ROOT" "$ARGUMENTS"

ユーザーが引数を指定した場合に限り、$ARGUMENTS を第 3 引数として渡してください。それ以外の場合は省略します。

• スクリプトがゼロ以外の終了コードで終了した場合（.dev/ ディレクトリがない場合）：ユーザーに伝えて停止してください。
• 出力が空の場合：チェックポイントは見つかりませんでした。何に取り組むか尋ねてください。
• 1 行の場合：その値を $FEATURE_DIR（チェックポイントを含むディレクトリ）として使用してください。
• 複数行の場合：再開する機能を尋ねてください。

生の $ARGUMENTS からパスを構築しないでください。スクリプトの出力に含まれるパスのみを使用してください。

選択後、検証スクリプトで検証します：

bash "$VALIDATE" checkpoint-path "$CHECKPOINT_PATH" "$PROJECT_ROOT"

$VALIDATE は、このスキルのディレクトリ内にある scripts/validate.sh の絶対パスです。ステップ 0 のパス安全性のルール（$HOME の使用、出力からのコピー）を適用してください。成功すると $FEATURE_NAME が出力されます。失敗した場合は、直ちに停止してください — 検証されていないパスで処理を続行しないでください。

$FEATURE_DIR を $PROJECT_ROOT/.dev/$FEATURE_NAME に設定します。

ステップ 2：resume-context でコンテキストを読み込む

resume-context を 1 回だけ呼び出します。これにより、以前のステップ 2～5（git-state、checkpoint-read、feature-show、有効性の比較）が置き換えられます。

node "$CLI" resume-context --json --dir "$FEATURE_DIR"

$CLI は、このスキルのディレクトリ内にある scripts/dev-workflow.cjs の絶対パスです。ステップ 0 のパス安全ルール（$HOME、出力からコピー）を適用します。

JSON 出力を解析します。複数のツール呼び出しで以前に収集していたデータがすべて含まれています。

• feature：{ name, status, progress {done, total, percent}, currentPhase {number, total, title} }
• checkpoint：{ context, nextAction, decisions[], blockers[], notes[] }
• validity："fresh" | "stale" | "drifted" — ブランチの一致と最新性を事前に確認した結果
• validityDetails：{ checkpointBranch, currentBranch, checkpointUncommitted, currentUncommitted }
• currentPhasePrd：現在のフェーズのみを対象に抽出した Markdown セクション（マスタープラン全体ではありません）
• referenceFiles：マスタープランの「Reference Files」セクションに記載されているファイルパス
• sessionDigest：以前のセッション末尾を要約したダイジェスト — { sessionCount, consolidatedThrough, generated, aggregate, decisions[] } — 機能が統合のしきい値（≥10 sessions）を超えた時点で /dev-checkpoint が書き込みます。しきい値未満の場合、またはダイジェストがまだ書き込まれていない場合は null です。
• recentSessionHistory：直近の未加工セッションウィンドウ（直近 N 件。既定値は 5 件。すべて取得するには --sessions=all を指定します）。ウィンドウより前のセッションは、sessionDigest がある場合はその中に要約されます。（以前の sessionHistory フィールドに代わるものです。）
• accumulatedDecisions：上限付きの決定事項セット — sessionDigest がある場合は、ダイジェストに引き継がれた決定事項と直近のウィンドウの決定事項の和集合（重複排除済み）です。ダイジェストがない場合は、すべてのセッションにわたる決定事項の完全な和集合（重複排除済み）です（従来の動作）。

LLM は git-state.sh、checkpoint-read --json、feature-show --json を呼び出さなくなりました。ブランチを手動で比較することもなくなりました。マスタープラン全体を読み込むこともなくなりました（currentPhasePrd には関連するセクションのみが含まれます）。

終了コードを確認します。 終了コードが 0 以外の場合、コマンドは失敗しています（例：機能ディレクトリが見つからない、チェックポイントがない）。0 以外の終了コードを決して無視しないでください。 resume-context が失敗した場合は、停止してエラーを報告します。別々のツール呼び出しからデータを再構成しようとしてはいけません。

ステップ 3：コンテキストの有効性を確認する

resume-context の出力から validity フィールドを読み取ります。

• fresh：ブランチが一致し、チェックポイントは最近のもの（3 日未満）です。通常どおり進めます。
• stale：ブランチは一致していますが、チェックポイントが古くなっています。情報として警告を表示してから進めます。
• drifted：ブランチが一致しません。警告を表示し、「チェックポイントは X にあり、現在は Y です。切り替えますか、それとも続行しますか？」と尋ねます。ユーザーの応答を待ってから進めます。

"drifted" の場合、validityDetails フィールドに、プロンプトに使う両方のブランチ名が表示されます。

ステップ 4：再開時の概要を提示する

resume-context の出力から、再開時の概要をまとめます。これは LLM にしかできない重要なステップです。CLI は処理を担い、LLM は判断を担います。

**Status**: [feature.currentPhase.title] — [feature.progress.done]/[feature.progress.total] ([feature.progress.percent]%)
**Last session**: [Derive from checkpoint.context field]
**Decisions**: [checkpoint.decisions, or "None recorded"]
**Session history**: [If sessionDigest present: "sessions 1–{sessionDigest.consolidatedThrough} consolidated into a digest + {recentSessionHistory.length} recent raw"; otherwise "{recentSessionHistory.length} sessions tracked"] — {accumulatedDecisions.length} decisions carried forward
**Feature arc**: [Only when sessionDigest present — summarize sessionDigest.aggregate so the distilled older-session history isn't lost. Omit this line entirely when sessionDigest is null.]
**Watch out for**: [checkpoint.blockers, or "Nothing flagged"]

**Current phase PRD**: [currentPhasePrd — summarize or reference; don't re-read the full master plan]

**Start with**: [First concrete action from checkpoint.nextAction field]

関連する場合は accumulatedDecisions を取り入れます。以前のセッションでの決定事項が、現在のステップの背景を理解するのに役立つことがあります。sessionDigest がある場合は、古い履歴については aggregate を参照し、直近の数セッションのみを含む未加工の recentSessionHistory には頼りすぎないようにします。

ユーザーの了承を待ちます — 確認を得るまで先に進んではいけません。

ステップ 5：不一致への対応

状況	対応
ファイルがチェックポイントと異なる	進めて、差異を記録します
重要なファイルが見つからない、または名前が変更されている	停止 — どう進めるか尋ねます
チェックポイントにない新しいファイルがある	進めて、それらに言及します
PRD ファイルが見つからない	停止 — PRD がないと再開できません

ステップ 6：主要ファイルと参考パターンを読む

作業を始める前に、次のことを行ってください。

1. resume-context の currentPhasePrd フィールドには、該当フェーズのセクションが含まれています。マスタープラン全体ではなく、こちらを読んでください。
2. resume-context の出力にある referenceFiles を使って、読むべきファイルを特定してください。これらは PRD で推奨されている参考実装です。
3. その中から 2～3 個のファイルを読み、新しいコードにもその規約（命名、構造、API、エラー処理）を反映してください。
4. 必要に応じて、プロジェクト横断の情報（関連機能、先行事例）を確認するため、$HOME/.dev-wiki/index.md を確認してください。ファイルがない場合は、何も表示せずにスキップしてください。

コードベースに類似したコードがすでにある場合は、決して新しいコードを一から書かないでください。

ステップ 7：作業を開始する

確認を得たら、エージェントの要約にある最初のアクションに進んでください。PRD のフェーズとゲートに従ってください。

重要：フェーズゲートの厳守

フェーズの作業が完了したら、CLI を実行してゲートの状態を機械的に検証してください。

node "$CLI" gate-check --json --dir "$FEATURE_DIR"

ここで $CLI は、このスキルのディレクトリにある scripts/dev-workflow.cjs の絶対パスです。

このコマンドは、成功時は常に終了コード 0（エラー時は終了コード 1）を返します。JSON 出力の atGate と allComplete フィールドを確認し、ゲートの状態を判定してください。Markdown のマーカーを目視するのではなく、この結果でフェーズの完了を確認してください。

各ゲート（gate-check で検出されたゲート、または PRD の ⏸️ **GATE**: マーカーによるゲートのどちらも）では、必ず作業を停止してください。

1. 停止 — 次のフェーズに進まないでください。
2. 完了した作業を報告してください。
3. 次のように確認してください。「フェーズ [N] が完了しました。フェーズ [N+1] に進みますか、それとも /dev-checkpoint を実行しますか？」
4. 続行についてユーザーから明示的な返答があるまで待機してください。
   • gate-check が allComplete: true を返した場合、または次のフェーズが最終の検証／テストフェーズである場合は、ゲートの確認に次の文を加えてください。「これが最後の実装フェーズです。最終テストの前に、PRD と実装の整合性レポートを作成するため、/dev-review の実行をご検討ください。」

ステップ単位の停止

フェーズ内の各実装ステップが完了したら、次のことを行ってください。

1. 完了した作業を報告してください。
2. 次のように確認してください。「ステップが完了しました。次のステップに進みますか？」
3. 続行について確認を得るまで待機してください。

これにより、現在のタスクのテストが完了する前に次のタスクへ進むことを防ぎます。

プライバシーに関するルール

チェックポイント／PRD ファイルに、ユーザー名を含む絶対パス、秘密情報／認証情報、または個人情報が含まれている場合は、ユーザーに警告してください。