inspect-issue
GitHub issue #$ARGUMENTS の詳細分析を行い、実施計画を立てます。
手順
1. Issueの取得
bash
gh issue view $ARGUMENTS
issueの内容（タイトル、説明、ラベル、コメント、関連情報）を確認してください。
2. 関連コードベースの調査
Issueの内容に基づき、関連するコードを調査してください。以下の観点で調査を行います:
- •影響範囲: 変更が必要なファイル・コンポーネントの特定
- •依存関係: 変更対象が依存しているモジュールや外部サービス
- •既存のテスト: 関連する既存テストの有無と範囲
- •類似の実装パターン: プロジェクト内で参考にできる既存実装
調査には Glob、Grep、Read ツールを活用してください。
3. 分析結果の構造化
調査結果を以下の構造で整理してください:
3.1 Issueの要約と分析
- •Issueの目的と背景を簡潔にまとめる
- •受け入れ条件（Acceptance Criteria）を明確化する
- •不明点や追加で確認が必要な事項があれば洗い出す
3.2 タスク分解
作業を具体的なタスクに分解してください。TDDに従い、各タスクにはテストの作成を含めてください。
形式:
code
1. [タスク名] - 概要の説明 - テスト: 作成するテストの内容 - 実装: 実装する内容 - 対象ファイル: 変更が必要なファイル
3.3 推奨される実装順序
依存関係を考慮した実装順序を提案してください。理由も添えてください。
3.4 概算見積（相対サイズ）
以下のTシャツサイズで相対的な規模感を見積もってください:
| サイズ | 目安 | 説明 |
|---|---|---|
| XS | 非常に小規模 | 1-2ファイルの軽微な変更、設定変更のみ |
| S | 小規模 | 数ファイルの変更、明確な実装方針 |
| M | 中規模 | 複数コンポーネントの変更、テスト追加 |
| L | 大規模 | 新機能の追加、複数ファイル・テストの大幅変更 |
| XL | 非常に大規模 | アーキテクチャ変更を伴う |
見積には以下を考慮してください:
- •変更ファイル数
- •テスト作成の工数
- •既存コードへの影響範囲
- •不確実性の度合い
3.5 リスクと考慮事項
以下の観点でリスクを洗い出してください:
- •技術的リスク: 実装上の課題、パフォーマンスへの影響
- •依存関係リスク: 外部サービス、他のIssueとの依存
- •互換性リスク: 既存機能への影響、破壊的変更の有無
- •テストリスク: テストが困難な箇所
4. 分析結果をIssueコメントとして投稿
整理した分析結果を、以下の形式でIssueにコメントとして投稿してください。
bash
gh issue comment $ARGUMENTS --body "$(cat <<'COMMENT_EOF' ## Issue分析レポート ### 要約 （3.1の内容） ### 受け入れ条件 - [ ] 条件1 - [ ] 条件2 ### タスク分解 （3.2の内容） ### 推奨される実装順序 （3.3の内容） ### 概算見積 **サイズ: [XS/S/M/L/XL]** （3.4の見積理由） ### リスクと考慮事項 （3.5の内容） --- Generated with [Claude Code](https://claude.com/claude-code) COMMENT_EOF )"
注意: コメント本文にシングルクォートが含まれる場合は適切にエスケープしてください。HEREDOCのデリミタ 'COMMENT_EOF' はシングルクォートで囲むことで変数展開を防ぎます。
5. 次のアクション
分析が完了したら、以下を提案してください:
- •対応を開始する場合:
/do-issue $ARGUMENTSの実行を提案 - •追加の調査が必要な場合: 具体的な調査ポイントを提示
- •Issueの内容に不明点がある場合: Issue作成者への質問を提案
注意事項
- •このスキルはコードの変更を行いません（読み取り専用の調査・分析のみ）
- •分析結果は対象IssueへのコメントとしてGitHubに投稿されます
- •
/do-issueの前に実行することで、事前に作業の全体像を把握できます - •複雑なIssueほど事前分析の効果が高くなります