executing-plans-preflight

プラン実行前の事前確認

半自動の Git 状態チェックです。問題を検出し、修正を提案して、確認後に実行します。実装作業を始める前に実行してください。Git の状態が整っていることを確認し、適切でクリーンな状態から作業を開始できます。

Git リポジトリではない場合は、Not a git repository — skipping preflight. と伝えて、そのまま続行してください。

チェック項目

順番に実行します。問題がなければ何も言わず、修正が必要な場合にのみ伝えてください。

1. ブランチの確認

origin/HEAD でデフォルトブランチを検出します。検出できない場合は、main／master をデフォルトブランチとして扱います。

• Detached HEAD → 切り替え先のブランチを尋ねます（推測できません）。
• デフォルトブランチ上 → 会話内のプランからブランチ名を推測します（タイトルをケバブケースにし、従来型コミットの種類を接頭辞に付けます：feat/、fix/、docs/、refactor/、perf/、test/、chore/、ci/、build/。デフォルトは feat/）。候補を提示し、ユーザーに確認または名前の変更をしてもらってから、git switch -c を実行します。 会話内にプランがない場合は、直接尋ねてください。ファイルシステムから推測してはいけません。
• それ以外 → 何もせず通過します。

2. 作業ツリーがクリーンか確認

git status --porcelain を実行します。ステージ済み、未ステージ、未追跡のものはすべて変更ありとして扱います。

• クリーン → 何もせず通過します。
• 変更あり → パスを列挙し、ユーザーに解決するか、上書きするために「continue」と伝えるよう尋ねます。上書きしたことを記録してください。チェック 3 でこの情報が必要になります。コミットやスタッシュの手助けはしないでください。コミットの範囲とメッセージは意図的に決めるべき事項であり、事前確認に埋もれさせるべきではないため、ユーザーに判断を委ねます。

3. リモートとの同期

git fetch を実行します。fetch に失敗した場合は警告し、ローカル情報で続行してください。リモートの状態が最新ではないのに、最新だと断言してはいけません。

• 追跡先なし／先行／最新 → 何もせず通過します。
• 追跡先が消失 → 追跡設定を解除するか、再作成するかを尋ねます。
• 遅れ／分岐 → git pull --rebase を提案します。チェック 2 で変更ファイルの上書きを許可された場合は、プルによって競合する可能性があると警告し、同期をスキップする選択肢を提示します。

チェック 1 で作成したブランチには追跡先がありません。これは想定どおりです。プッシュしてはいけません。

結果

すべてのチェック後に、結論を 1 行で示します。その前に、修正ごとに個別の行を追加してください。

Switched to `feat/add-auth` (was on main)
Preflight passed. Ready to go.

変更ファイルの上書きが許可されている場合は、Ready to go. ではなく、最後に Proceeding with uncommitted changes. と記してください。

このガードレールが必要な理由

• 実行前に確認する — Git の操作は元に戻しにくく、誤ったブランチで switch -c や pull --rebase を実行すると、実作業が失われるおそれがあります。
• 変更の上書きを許可する — 無条件にブロックすることが、v2 で最大の摩擦点でした。ユーザーの作業状態については、事前確認よりもユーザー自身のほうがよく把握しています。
• プッシュしない — 事前確認で管理するのはローカルの状態だけです。公開は別途、意図をもって行う手順です。