gh-issue-organizer

name	gh-issue-organizer
description	GitHub Issue の棚卸し・整理を体系的に実行するスキル。オープンイシューの分類、 グルーピング、クローズ判定、優先度付け、バッチ化を行う。 CodeRabbit 自動生成イシューと手動報告イシューの区別、根本原因別グルーピング、 完了済みイシューの特定とクローズ提案を含む。 トリガー：「イシューを整理して」「issue を棚卸し」「GitHub issue をトリアージ」 「stale issue をクローズ」「issue の優先度付け」 といった GitHub Issue 整理関連リクエストで起動。

GitHub Issue 整理スキル

オープンイシューの棚卸し・分類・整理を体系的に実行する。

ワークフロー

以下の5ステップで順番に実行する。

ステップ 1: 現状把握（取得・集計）

gh CLI でオープンイシューを全件取得し、現状を把握する。

# 全オープンイシューを取得（ラベル・作成者・作成日付き）
gh issue list --state open --limit 500 --json number,title,labels,author,createdAt,updatedAt,body

# ラベル別の件数を確認
gh issue list --state open --limit 500 --json labels --jq '[.[].labels[].name] | group_by(.) | map({label: .[0], count: length}) | sort_by(-.count)'

結果をサマリーテーブルとして整理する:

項目	件数
オープンイシュー合計	N件
CodeRabbit 自動生成	N件
手動報告	N件
Epic / リファクタリング	N件

ステップ 2: 分類

各イシューを以下のカテゴリに分類する。

分類基準

カテゴリ	判定条件
CodeRabbit 自動生成	author が coderabbitai または github-actions[bot]、またはラベルに coderabbit を含む
手動報告（バグ）	ラベルに bug を含む、または人間が作成
手動報告（機能要求）	ラベルに enhancement / feature を含む
Epic / リファクタリング	ラベルに refactoring / epic を含む、またはタイトルに「Phase」「リファクタリング」を含む
その他	上記に該当しないもの

判定用コマンド

# CodeRabbit 生成イシューを抽出
gh issue list --state open --limit 500 --json number,title,author --jq '[.[] | select(.author.login == "coderabbitai" or .author.login == "github-actions[bot]")]'

# 手動報告イシューを抽出
gh issue list --state open --limit 500 --json number,title,author --jq '[.[] | select(.author.login != "coderabbitai" and .author.login != "github-actions[bot]")]'

ステップ 3: グルーピング

分類済みイシューを根本原因・テーマ別にグループ化する。

グルーピングの観点

1. コード領域: 対象モジュール・クレート（actor-core, remote, cluster, streams 等）
2. 根本原因: 共通の設計課題（mutex戦略、型設計、カプセル化、エラー処理 等）
3. 対応の粒度: 単独対応可 vs 一括対応が効率的

出力フォーマット

## グループ: [テーマ名]
- 関連イシュー: #N, #M, #K
- 根本原因: [説明]
- 対応方針: [個別 / バッチ]
- 推定作業量: [小 / 中 / 大]

ステップ 4: クローズ判定（コード検証必須）

各イシューについて、実際にコードを読んで解決済みかどうかを判定する。 PR履歴やコミットログだけで判断してはならない。必ず現在のコードを確認すること。

判定手順

各イシューに対して以下を順番に実行する:

1. イシュー本文の解析: イシュー本文から以下を抽出する

   • 対象ファイルパス
   • 対象シンボル（関数名、構造体名、トレイト名 等）
   • 指摘内容（何が問題とされているか）
   • コードスニペット（引用されているコード）

2. 対象コードの存在確認: ファイル・シンボルが現在のコードベースに存在するか確認する

   # Serena の find_symbol / get_symbols_overview を使う
   # または Glob / Grep で対象ファイルを検索
   

   • ファイルが存在しない → クローズ可能（理由: 対象コード削除済み）
   • シンボルが存在しない → クローズ可能（理由: 対象シンボル削除済み）

3. コードの実読: 対象シンボルが存在する場合、実際にコードを読んで指摘内容が解消されているか判定する

   # Serena の find_symbol with include_body=True でシンボル本体を読む
   # または Read ツールで該当ファイルの該当箇所を読む
   

   確認観点:

   • 指摘されていた問題のコードパターンがまだ残っているか？
   • リファクタリングにより構造が変わって指摘が無効化されているか？
   • 指摘通りの修正が既に適用されているか？

4. 判定結果の記録: 各イシューに以下のいずれかのステータスを付与する

ステータス	基準	根拠の記載方法
クローズ可能	コードを読んだ結果、指摘が解消されている	「<ファイル> の <シンボル> を確認。指摘内容の <問題> は <現在の実装> により解消済み」
対象消失	指摘対象のファイル・シンボルが存在しない	「<ファイル> は削除済み」または「<シンボル> は存在しない」
未解決	コードを読んだ結果、指摘内容がまだ該当する	「<ファイル> の <シンボル> を確認。指摘の <問題> は依然として存在」
要確認	コードだけでは判断できない（設計意図に依存等）	判断できない理由を明記
重複	別イシューと同一の指摘	重複先の Issue 番号を明記

判定の原則

• コードを読まずにクローズ判定してはならない。PR タイトルやコミットメッセージだけで「修正済み」と判断しない。
• イシュー1件ごとに、対象コードの該当箇所を実際に読んで確認する。
• CodeRabbit イシューは指摘箇所が具体的（ファイルパス・行番号付き）なので、その箇所を直接読む。
• 大量のイシューを処理する場合は Agent ツールで並列に検証してもよい。

クローズ時のコメント

クローズする際は、コード確認の根拠を含めて以下のフォーマットでコメントを付ける:

## 解決確認

- 確認対象: `<ファイルパス>` の `<シンボル名>`
- 確認結果: <指摘内容>は<具体的な現在の実装の説明>により解消済み
- 関連: [PR #N / リファクタリング Phase X]（該当する場合）

クローズします。

重要: 実際のクローズ操作は、判定結果をユーザーに報告し承認を得てから実行する。

ステップ 5: 報告

分析結果を以下のフォーマットで報告する。

サマリー

## Issue 棚卸しサマリー

| カテゴリ | 件数 | クローズ候補 | 残存 |
|----------|------|-------------|------|
| CodeRabbit 自動生成 | N | N | N |
| 手動報告（バグ） | N | N | N |
| 手動報告（機能要求） | N | N | N |
| Epic / リファクタリング | N | N | N |
| 合計 | N | N | N |

クローズ候補一覧

## クローズ候補

| # | タイトル | ステータス | 確認箇所 | 根拠 |
|---|---------|-----------|---------|------|
| #N | ... | クローズ可能 | `src/actor/foo.rs` の `Bar::baz()` | 指摘の mutex 使用は Arc<RwLock> に変更済み |
| #N | ... | 対象消失 | `src/old_module.rs` | ファイル削除済み |
| #N | ... | 重複 | - | #M と同一指摘 |

グループ別詳細

各グループごとに以下を記載:

• 関連イシュー一覧
• 根本原因の説明
• 推奨アクション（クローズ / 対応 / 保留）
• バッチ対応の提案（同時に対処すべきイシュー群）

優先度提案

残存イシューに対する対応順の提案:

1. High: セーフティ・正確性に関わるもの
2. Medium: 設計改善・保守性向上
3. Low: スタイル・軽微な改善

gh CLI コマンドリファレンス

# イシュー一覧（詳細）
gh issue list --state open --limit 500 --json number,title,labels,author,createdAt,updatedAt,body,comments

# 特定ラベルのイシュー
gh issue list --state open --label "bug" --json number,title

# イシュー詳細の確認
gh issue view <number> --json number,title,body,labels,author,comments

# イシューのクローズ（コメント付き）
gh issue close <number> --comment "理由"

# イシューへのラベル追加
gh issue edit <number> --add-label "label-name"

# マージ済みPR一覧
gh pr list --state merged --limit 50 --json number,title,mergedAt

# PR の変更ファイル確認
gh pr view <number> --json files

注意事項

• クローズ判定は必ずコードを読んで行う。PR履歴・コミットメッセージ・タイトルだけで判断しない。指摘箇所の現在のコードを実際に確認する。
• クローズ操作は必ずユーザー承認後に実行する。判定結果の報告まではスキルが自動実行し、実際のクローズはユーザーの確認を経て行う。
• コード確認には Serena のシンボリックツール（find_symbol, get_symbols_overview）や Read/Grep ツールを活用する。
• CodeRabbit イシューは指摘箇所が具体的（ファイルパス・行番号付き）なので、その箇所を直接読んで判定する。
• CodeRabbit イシューは数が多いため、まずグルーピングで全体像を把握してからクローズ判定に進む。
• 大量のイシューを効率的に処理するため、同一ファイルに関するイシューはまとめて確認する。
• イシュー本文が長い場合は --jq で必要なフィールドのみ抽出し、効率的に処理する。
• 判断に迷うイシューは「要確認」として残し、ユーザーに判断を委ねる。