| 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コミットにまとめる
- 機能・論理単位で分割
- 細かく分割（ファイル単位・ステップ単位）
- コミットメッセージ規約（Conventional Commits 等）に従うか
-
PR作成の有無・タイミング
- 作業完了後にPRまで作成するか
- コミット止まりにするか（ユーザーが手動でPR）
- ドラフトPRを先に作るか
-
スコープ確認
- 含める変更の範囲（どのファイル／機能まで）
- 含めない変更（関連するが今回はやらないこと）
- 既存コードのリファクタを伴うか
git管理されていない場合は、ブランチ・PRの質問はスキップしてよい。
ステップ 4: 合意内容の要約
質問の回答を受けたら、下記のような短いサマリを返して最終合意を取る:
以下の方針で進めます:
- スコープ: XXX
- ブランチ: YYY（新規/既存）
- コミット粒度: ZZZ
- PR: あり/なし（タイミング: ~~~）
不明点: なし
ステップ 5: 実装／計画の開始
合意が取れたら、planツールまたは実装を開始する。
途中で新たな曖昧さに気づいた場合は、その都度 AskUserQuestion で確認する（推測で進めない）。
ルール
- 曖昧さを見つけたら必ず聞く。推測で進めない。
- git管理下では、ブランチ・コミット粒度・PR・スコープの4点を原則必ず聞く
- 既にユーザーが明示している項目は重複して聞かない（回答済みを尊重）
- 質問は
AskUserQuestion ツールを使う（会話文で聞き流さない）
- ユーザーが「全部任せる」「適当でいい」と明言した場合のみ、推奨値で進めてよい
