kura-by2 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: [Stop hook が実コマンドとして実行する検証コマンド。失敗すると停止がブロックされるため、絶対パスへ展開済みの実行可能なコマンドだけを書く。`<worktree>` などの未展開プレースホルダや説明的日本語は残さない。機械検証できない条件は注釈なしのリテラル `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で参照）