analyse-issue

Issue の分析

概要

Issue の詳細を取得し、リポジトリが一致していることを確認してから、ローカルのコードベースを調べ、報告された問題を裏付けるか否定するかを確認します。根拠に基づいた分析と、明確な次のステップを提示します。

ワークフロー

1) Issue の入力を解析する

• 入力が GitHub issue の URL の場合は、オーナー／リポジトリと issue 番号を抽出します。
• 入力が番号のみの場合は、ユーザーが別のリポジトリを指定しない限り、現在のリポジトリを対象とします。
• プロバイダーが GitHub ではない場合、または不明な場合は、処理を進める前に確認します。

2) ローカルのリポジトリが issue と一致することを確認する

• 現在のディレクトリが git リポジトリ内にあることを確認します（git rev-parse --show-toplevel）。
• 対象のリモートを特定します（origin を優先）。SSH／HTTPS の形式を owner/repo に正規化します。
• issue の URL にあるリポジトリがローカルの owner/repo と一致しない場合は、処理を中止し、ディレクトリを切り替えるか、対象リポジトリを確認するようユーザーに求めます。
• リモートがない場合、または候補が複数ある場合は、使用するリポジトリをユーザーに確認します。

3) issue の内容を取得する

利用可能な場合は、gh を優先します。

• gh issue view <num> --json title,body,labels,comments,author,createdAt,updatedAt
• URL が指定されている場合は、そのリポジトリを対象に実行します：gh issue view <num> -R owner/repo --json ...

代替手段：

• 他のフィールドが必要な場合は、gh api repos/{owner}/{repo}/issues/{num} と .../comments を使用します。
• gh を利用できず GITHUB_TOKEN がある場合は、GitHub API に対して curl を使用します。
• どちらも利用できない場合は、issue の内容を貼り付けるようユーザーに求めます。

少なくとも次の内容を記録します：タイトル、本文、ラベル、環境の詳細、再現手順、期待される動作と実際の動作、重要なコメントの要点。

4) コードベースを分析する

• issue の内容を、具体的な手がかり（キーワード、エラーメッセージ、スタックトレース、設定名）に落とし込みます。
• rg を使用して、関連するコード、テスト、設定を検索します。
• 実行経路を追跡します：エントリーポイント -> コアロジック -> 依存関係。
• 問題が発生しそうな箇所を特定します：チェックの欠落、エッジケース、誤った前提、データ形状の不一致、並行処理／タイミングの問題。
• 適切かつ安全な場合は、対象を絞ったテストを実行します。それ以外の場合は、仮説を検証するための対象テストを提案します。

5) issue を確認する、または判断を保留する

• ファイル参照と推論を添えて根拠を示します。
• テストを実行せずに推論のみで判断する場合は、前提と確信度を明記します。
• 根拠が不十分な場合は、必要な情報を具体的に列挙します。

6) 構造化した分析を回答する

次の内容を含めます。

• issue の概要（期待される動作と実際の動作）
• リポジトリの一致確認
• 根拠（ファイル／関数）
• 根本原因の仮説、または確認済みの原因
• 修正方法の提案
• 質問、または不足している情報
• 次のステップ（テスト、ログ、再現）

出力規則

• ユーザーの言語が明確な場合は、その言語で回答します。中国語のプロンプトには中国語を既定とします。
• 分析は簡潔にしつつ、具体的なファイルの参照先と根拠を含めます。
• コードに基づく根拠または再現がない限り、問題を確認済みだと断定しないでください。