Preflight

Preflight: 実行前タスク明確化

複雑なタスクを実行する前に「何を・どこまで・どのツールで」を明確にして、 実行後の手戻りをなくすためのスキル。

入力

タスク内容: $ARGUMENTS

引数がない場合は「どのタスクを明確化したいですか？」と聞く。

---

Phase 1 — 意図の解像度を上げる

タスク文を読んで、実行の方向性が変わりうる曖昧な点を最大3つ特定して質問する。

良い質問の条件:

• タスク文中の具体的な言葉を引用して聞く（「整理して」→「何を基準に整理？ファイル名順？種類別？」）
• 回答によって実行ステップが変わるもの（スコープ・対象・破壊性）を優先する
• 汎用的な「どんな出力形式ですか？」のような質問はしない

質問が不要なケース: タスクが十分に具体的で、解釈の余地がない場合はPhase 1をスキップしてPhase 2へ進む。

ユーザーの回答を受け取ってからPhase 2へ進む。

---

Phase 2 — ツール選択

明確化された意図に基づき、必要なツールを選定する。 詳細なツール選択基準は references/tool-selection.md を参照。

出力形式:

## 使用ツール

| ツール | 用途 | 理由 |
|--------|------|------|
| Grep   | ファイル検索 | TODOコメントのパターン検索に適切 |
| Edit   | ファイル編集 | 既存行の削除・書き換え |

不要なツールは省く。各ツールの選定理由はこのタスク固有の内容にする（「存在するから」ではなく「〇〇が必要だから」）。

---

Phase 3 — 実行計画の出力

以下のフォーマットで出力する:

## 精緻化された意図
[1文、能動態。「〇〇を△△することで□□する」の形]

## 事前確認事項
- [ ] [確認すべきファイル・ディレクトリ・状態 + 確認コマンド]

## 実行ステップ
1. [ツール名] [対象] → [期待される結果]
2. [ツール名] [対象] → [期待される結果]
   ⚠️ [要確認] ← 破壊的・不可逆な操作にはこのフラグをつける

## 完了条件
- [完了条件の説明] / verify: [検証用シェルコマンド。機械検証できない条件は manual]

## リスク・残る曖昧点
- [実行中に問題になりうること、または明確化できなかった点]

## 精緻化されたプロンプト
[このままコピーして投げ直せる形に書き直したタスク文]

破壊的操作の判断基準: ファイルの上書き・削除、既存データの変更、外部への送信 → ⚠️ [要確認] フラグをつける。

---

出力先

Phase 3 の出力先は、デフォルトでは標準出力にする。

呼び出し元が出力先ファイルを明示した場合は、その指定に従って書き出す。

呼び出し元の指定がなく、かつ Phase 3 の出力をファイルとして残す必要がある場合は、固定パスや作業ディレクトリには書かず、必ず使い捨てとして /tmp 直下に preflight- 接頭辞つきのタスク別ユニーク名で書く。

output="/tmp/preflight-<task>-$(date +%Y%m%d-%H%M%S).md"

<task> はタスクを表す短い slug にする。/tmp 直下なので再起動で自然消滅し、毎回ユニーク名なので上書き衝突も残留も起きない。

---

参照ファイル

• references/tool-selection.md — ツール選択マトリクス（Phase 2で参照）