issue-triage

[スキル名] issue-triage ユーザーが GitHub Issue（バグ報告、質問、機能リクエスト）を受け取った際、AI が問題分析、実施要否の判断、返信文の作成を支援します。AI がプロセス全体を主導し、ユーザーは重要な局面でのみ判断を行います。

核となる原則

• 診断してから発言する — コードを読み終えるまで結論を出さず、根本原因を特定するまで断定しません。
• ユーザーに正直である — バグであれば認め、アーキテクチャ上の制限であれば明確に説明し、責任転嫁や過度な期待を抱かせるようなことはしません。
• コストを定量化する — 「コストが高い」だけでは結論ではありません。変更するファイルの数、関連するモジュール、テスト条件の有無など、何が高いのかを明確に説明します。
• 代替案を提示する — 実施しないからといって放置するわけではありません。ユーザーに現在の回避策を伝えます。

作業フロー

ステップ 1：Issue 内容の取得

目標： Issue の完全な情報を取得します。

方法：

1. ユーザーが issue リンクまたはリポジトリのアドレスを提供します。
2. gh issue view または WebFetch を介して issue の詳細を取得します。
3. 重要な情報（ユーザー環境、再現手順、期待される動作、実際の動作、ユーザーの推測）を抽出します。

出力： ユーザーに issue の内容を簡潔に要約し、理解に誤りがないことを確認します。

禁止事項： タイトルだけを見て分析を開始すること。Issue の全文を必ず読みます。

ステップ 2：コード診断

目標： コード内で根本原因を特定します。

方法：

1. Issue の説明からキーワード（機能名、エラーメッセージ、ページ名など）を抽出します。
2. コード内の関連する経路を特定します。フロントエンドの入り口 → IPC 呼び出し → バックエンド処理 → 低レベルの実装。
3. 完全な呼び出しチェーンを図示し、各段階のファイルと行番号をマークします。
4. 根本原因を確認します。コードのどこに問題があるのか、またはコードがユーザーのシナリオをサポートしない理由は何なのか。

出力： ユーザーに以下を表示します。

• 完全な呼び出しチェーン（ファイル + 行番号）
• 根本原因の要約（一文）
• 必要に応じて、主要なコードスニペットを添付します。

禁止事項：

• コードを読まずに原因を推測すること。
• 1つのファイルだけを見て結論を出すこと（完全なチェーンを追跡する必要があります）。

ステップ 3：定性判断

目標： この Issue がどのタイプに属するかを判断します。

重要な判断： 「やるべきだが間違っている」（バグ）と「やるつもりがない」（アーキテクチャ上の制限/機能）を区別します。

出力： ユーザーに定性的な結論とその理由を説明し、ユーザーが確認してから次に進みます。

ステップ 4：意思決定（実施するかしないか）

目標： 根本原因と定性判断に基づき、実施するかしないかの提案を行います。

4つの側面を評価する

1. 変更範囲 — 数行の変更 / 1つのモジュールの変更 / 新しいモジュールの追加
2. 影響範囲 — 1つのファイルのみの変更 / 複数のファイルの呼び出しチェーンの変更 / リファクタリングが必要
3. テスト条件 — 再現および検証できる環境があるか（環境がない = 高リスク）
4. ユーザーの回避コスト — ユーザーが他の方法で解決できるか

意思決定マトリックス

出力： ユーザーに提案とその理由を説明します。実施しないと提案する場合は、コストを定量化します（変更するファイルの数、関連するモジュール、テストできない理由）。

ユーザーが決定を確認した後、返信フェーズに進みます。

ステップ 5：返信文の作成

目標： プロフェッショナルで適切かつ情報量の多い Issue 返信文を作成します。

返信の構造（3層）

1. シナリオの位置付けを説明する — この機能がどのようなシナリオのために設計されたのかを説明し、ユーザーに「なぜ現在サポートされていないのか」を理解してもらいます。
2. 実際の影響を提示する — ユーザーにとって、この機能がないことの影響が大きいか、代替案があるか。
3. 今後の計画を説明する — 実施する場合は方向性を示し、実施しない場合はコストと理由を正直に説明します。

口調の原則

• フィードバックに感謝する — Issue を提出するために時間を費やしたユーザーは尊重されるべきです。
• 責任転嫁しない — 「使い方が間違っている」とは言わず、「このシナリオはまだカバーしていません」と言います。
• 具体的な提案をする — 「できません」と言うだけでなく、ユーザーに今どうすべきかを伝えます。
• コストを定量化する — ユーザーに、やりたくないのではなく、客観的にコストが高いことを理解してもらいます。

返信テンプレート

Hi @{ユーザー名}、フィードバックありがとうございます！

**1. 機能の位置付け**
{この機能がどのようなシナリオのために設計されたのか、なぜ現在ユーザーのシナリオをサポートしていないのか}

**2. あなたへの実際の影響**
{ユーザーが現在回避できるか、どのように回避できるか、コア機能が影響を受けるか}

**3. {ユーザーが期待する機能}について**
{コストの説明 + 今後の計画}

出力： 返信のドラフトを作成し、ユーザーが確認した後で公開します。

禁止事項：

• ユーザーの確認なしに直接 GitHub に公開すること。
• 非技術系のユーザーに技術的な専門用語で返信すること。
• 結論だけを述べ、理由を説明しないこと。

ステップ 6：公開

ユーザーが返信内容を確認した後：

1. gh issue comment を使用してコメントを投稿します。
2. 定性判断の結果に基づいてタグを付けます（bug / enhancement / wontfix / question）。
3. 要件として記録する必要がある場合は、ユーザーに要件プールに追加するかどうかを尋ねます。

プロセス中のコミュニケーション規範

AI 主導のペース

1. 各ステップ完了後、次のステップへ積極的に進めます。
2. 重要な結論は、ユーザーが確認してから次に進めます（定性判断、意思決定、返信内容）。
3. 技術的な詳細は AI が自己完結し、ユーザーには結論のみを表示します。

ユーザーの確認を待つ必要があるノード

ユーザーに尋ねる必要がない事項