kickoff

name	kickoff
description	実装・計画・作業を開始する前に、曖昧な点を残さずユーザーに確認を取るためのキックオフニュアンス。 git管理下であればブランチ戦略、コミット粒度、PR作成の有無・タイミング、スコープを必ず事前確認する。 トリガー: "実装", "実装して", "計画", "計画して", "作業開始", "着手", "やって", "お願い", "キックオフ", "kickoff", "/kickoff" 使用場面: コード変更・新規実装・リファクタ・修正・調査から実装に移る時など、「手を動かし始める前」に毎回使う。

kickoff

実装・計画に着手する前に、ユーザーの意図を正確に把握し、後戻りを防ぐための事前すり合わせスキル。

目的

• 曖昧な仕様・要件を推測で進めず、必ずユーザーに確認する
• git管理されている場合、作業フロー（ブランチ・コミット・PR）を事前に合意する
• スコープを明確にし、過剰実装・実装漏れを防ぐ

実行手順

ステップ 1: 作業内容の理解

ユーザーの依頼を読み、以下を整理する:

• 何を作る／直す／調べるのか
• 既に明示されている制約・前提は何か
• 不明点・曖昧な点はどこか ← ここを絶対に放置しない

ステップ 2: 不明点の洗い出しと質問

曖昧な点が1つでもある場合、推測で進めずに必ず AskUserQuestion で質問する。

「だいたい分かったから進めよう」は禁止。以下のような曖昧さは必ず確認する:

• 要件の解釈に2通り以上ありうる
• 対象範囲（ファイル・機能・画面）が複数考えられる
• UI/挙動の細部が決まっていない
• 既存コードのどのパターンに合わせるか不明
• 使うライブラリ・APIの選択肢が複数ある

1回のAskUserQuestionに複数質問をまとめて効率よく聞く（最大4問）。

ステップ 3: git管理下の場合、作業フローを確認

git rev-parse --is-inside-work-tree などで git管理下だと確認できたら、必ず以下を AskUserQuestion でまとめて聞く:

1. ブランチ戦略

   • 現在のブランチでそのまま作業するか
   • 新しいブランチを切るか（切る場合はブランチ名・派生元）
   • 既存の作業ブランチに乗るか

2. コミット粒度

   • 1コミットにまとめる
   • 機能・論理単位で分割
   • 細かく分割（ファイル単位・ステップ単位）
   • コミットメッセージ規約（Conventional Commits 等）に従うか

3. PR作成の有無・タイミング

   • 作業完了後にPRまで作成するか
   • コミット止まりにするか（ユーザーが手動でPR）
   • ドラフトPRを先に作るか

4. スコープ確認

   • 含める変更の範囲（どのファイル／機能まで）
   • 含めない変更（関連するが今回はやらないこと）
   • 既存コードのリファクタを伴うか

git管理されていない場合は、ブランチ・PRの質問はスキップしてよい。

ステップ 4: 合意内容の要約

質問の回答を受けたら、下記のような短いサマリを返して最終合意を取る:

以下の方針で進めます:
- スコープ: XXX
- ブランチ: YYY（新規/既存）
- コミット粒度: ZZZ
- PR: あり/なし（タイミング: ~~~）
不明点: なし

ステップ 5: 実装／計画の開始

合意が取れたら、planツールまたは実装を開始する。 途中で新たな曖昧さに気づいた場合は、その都度 AskUserQuestion で確認する（推測で進めない）。

ルール

• 曖昧さを見つけたら必ず聞く。推測で進めない。
• git管理下では、ブランチ・コミット粒度・PR・スコープの4点を原則必ず聞く
• 既にユーザーが明示している項目は重複して聞かない（回答済みを尊重）
• 質問は AskUserQuestion ツールを使う（会話文で聞き流さない）
• ユーザーが「全部任せる」「適当でいい」と明言した場合のみ、推奨値で進めてよい