tanabee/research

GitHub issue ( $ARGUMENTS ) に対して、実装に着手する前の技術調査を行う。$ARGUMENTS は issue 番号（123、#123）または URL。$ARGUMENTS が空の場合はユーザーに issue 番号を質問する。

本スキルは 事実収集 に責務を絞る。実装方法の候補は列挙して推奨度を付けるが、選択は行わない（選択は /plan の責務）。

手順

1. tmp/issues/<issue番号>/research.md が既にある場合はその内容を確認し、更新が必要か判断する
2. gh issue view で issue を取得する
3. issue の目的・要件・受け入れ条件を分析する
4. 受け入れ条件（AC）の確定 — issue から AC を抽出し、検証可能な粒度に具体化する。AC に番号を振り、後段の /plan が「AC番号 → タスク」のマッピングを作れるようにする
   • issue に AC が記載されていない、または曖昧で検証可能な粒度に落とせない場合は AskUserQuestion でユーザーに質問する（候補となる AC をこちらから提示し、ユーザーに選択・追加・修正してもらう形が望ましい）
   • 既存の research.md に AC が既に記載されている場合は、その内容を尊重して必要に応じて差分のみ更新する
5. 実装計画を進める上で不足している情報（仕様の曖昧な点、未定義の振る舞い、外部依存の確認事項など）を洗い出し、ユーザーに質問する
6. コードベースを調査し、影響範囲（変更対象のファイル・関数、呼び出し元、依存関係）を特定する
7. 実装方法の候補を 3 つ程度洗い出し、それぞれの Pros / Cons を整理する。各候補に 5 段階の推奨度を付ける（選択はしない）
8. 結果を Write ツールで tmp/issues/<issue番号>/research.md に書き込む（フォーマットは template.md を参照）

注意事項

• issue の内容が曖昧な場合は、ステップ 4-5 でユーザーに確認を取ってから先に進む
• 受け入れ条件は「実装の選び方に依存しない」要件レベルで記述する（特定の関数名や実装手段に依存しない）
• コードベースが大きい場合、調査は issue に関連する部分に絞る
• 既存のテスト・型定義・ドキュメントも調査対象に含める
• 調査結果は事実とコードの根拠に基づくこと。推測が含まれる場合は明示する
• 実装方法の 選択は本スキルでは行わない。選択は /plan がユーザーに確認する