issue-triage

Issue Triage Skill

分類と優先順位付けにより、Java プロジェクトの GitHub issue を効率的にトリアージします。

使用するタイミング

• ユーザーが「issue をトリアージして」／「最近の issue を確認して」と言ったとき
• 定期的なメンテナンスのワークフロー
• 休暇や休憩の後（バックログ処理）
• 毎週／毎月の issue レビュー

前提条件

推奨：最適なトークン使用量のため、GitHub MCP サーバーを設定します

claude mcp add github --transport http \
  https://api.githubcopilot.com/mcp/

代替：gh CLI を使用します（トークン効率は低くなります）

ワークフロー

1. Issue の取得

GitHub MCP を使用する場合（推奨）：

Tool: list_issues
Parameters: {
  "state": "open",
  "sort": "updated", 
  "per_page": 10
}

gh CLI を使用する場合：

gh issue list --state open --limit 10 --json number,title,labels,body,url

2. 各 Issue を分類する

issue の内容を分析し、カテゴリを割り当てます。

バグ報告 ✅

判断材料：

• スタックトレースやエラーメッセージがある
• 再現手順が記載されている
• 期待される動作と実際の動作が説明されている
• 特定のバージョン番号に言及している

対応：

• ラベル：bug
• 説明から再現可能かを確認する
• 重複するバグがないか確認する
• 重大な場合はマイルストーンに追加する

例：

Issue #234: "NPE when loading plugin from directory"
- Stack trace: ✅
- Reproduction steps: ✅
- Version info: ✅
→ Label: bug, high-priority

機能リクエスト 💡

判断材料：

• 新しい機能を求めている
• ユースケースが説明されている
• 「こうなったら便利です」／「追加してもらえますか」
• 理由が示されている

対応：

• ラベル：enhancement
• プロジェクトの目標との整合性を評価する
• 簡単に判断できない場合は、議論が必要なものとしてマークする
• コミュニティから意見を募る

質問／サポート ❓

判断材料：

• 「どうすれば……」／「誰か助けてもらえますか」
• 設定や使い方に関する質問
• バグ報告でも機能リクエストでもない

対応：

• ラベル：question
• 回答するか、ドキュメントへのリンクを案内する
• 複雑なサポートが必要な場合は、StackOverflow を案内する
• 解決した場合は、回答後にクローズする

重複 🔄

類似する issue を検索します：

• GitHub 検索を使用する：is:issue <keywords>
• 最近クローズされた issue を確認する
• 同じエラーメッセージがないか探す

対応：

• 元の issue へのリンクを記載する：「#123 の重複です」
• 丁寧なコメントを添えてクローズする
• 追加情報がある場合は、元の issue にコメントするよう報告者に依頼する

無効／不明確 ⚠️

判断材料：

• 重要な情報が不足している
• 話題から外れている、またはスパムである
• 対応に必要なコンテキストが足りない

対応：

• テンプレートを使って詳細を尋ねる
• 「needs-more-info」ラベルを設定する
• 14 日間返信がなければ自動クローズする

3. 優先度の評価

重大（P0）🔴

基準：

• セキュリティの脆弱性
• データの損失／破損のリスク
• 機能が完全に停止する
• 本番システムに影響する

対応：

• ラベル：critical
• メンテナーに直ちに通知する
• 現在のマイルストーンに追加する
• ホットフィックスのリリースを検討する

例：

- "SQL injection vulnerability in plugin loader"
- "All plugins fail to load after upgrade"
- "ClassLoader leak causes OutOfMemoryError"

高（P1）🟠

基準：

• 中核機能が動作しない
• 多くのユーザーに影響する
• 回避策はあるものの、利用しづらい
• 以前のバージョンからのリグレッション

対応：

• ラベル：high-priority
• 次のマイルストーンに追加する
• リリースノートに含める

例：

- "Plugin dependencies not resolved correctly"
- "Hot reload crashes application"

中（P2）🟡

基準：

• エッジケースのバグ
• 明確な価値のある機能強化
• ドキュメントの不足
• 一部のユーザーに、ときどき影響する

対応：

• ラベル：medium-priority
• 今後のマイルストーンへの追加を検討する
• コントリビューター向けのタスクとして適している

例：

- "Improve error message for invalid plugin"
- "Add plugin lifecycle listener"

低（P3）🟢

基準：

• あれば便利な機能
• 見た目上の問題
• 非常にまれなエッジケース
• ドキュメントの改善

対応：

• ラベル：low-priority
• 「コントリビューション歓迎」タグを付ける
• 今後対応するため、バックログに追加する

例：

- "Add more examples to README"
- "Typo in JavaDoc"

4. 返信テンプレート

追加情報が必要

Thanks for reporting this issue! 

To investigate further, could you provide:
- Java version (java -version)
- Library version
- Minimal reproducible example
- Full stack trace (if applicable)
- Configuration files (if relevant)

This will help us diagnose and fix the issue faster.

重複

Thanks for reporting! This is being tracked in #123.

Closing as duplicate. Feel free to add any additional context 
or information to the original issue.

対応しない（理由を添える）

Thank you for the suggestion. After consideration, this doesn't 
align with the project's current direction because [reason].

Consider [alternative approach] instead, which might better 
serve your use case.

If you feel strongly about this, please open a discussion in 
our [forum/discussions] to gather community feedback.

バグを確認

Confirmed! This is a valid bug. 

I've added it to milestone X.Y and labeled it as [priority].
Contributions welcome if anyone wants to tackle it!

Reproduction verified with:
- Java 17
- Version 3.10.0
- Ubuntu 22.04

機能リクエスト — 検討中

Interesting idea! This aligns with our goal of [project goal].

I've labeled this as 'enhancement' for further discussion.
Community feedback welcome - upvote with 👍 if you'd find 
this useful.

Some questions to consider:
- [question 1]
- [question 2]

質問への回答

To achieve this, you can [solution].

Example:
\`\`\`java
[code example]
\`\`\`

Also check our documentation: [link]

Let me know if this solves your issue!

トークン最適化の方法

バッチ処理

# Process multiple issues in one prompt
"Triage issues #234-243, categorize and prioritize"

削減量：1 件ずつ処理する場合と比べて、トークンを約 60% 削減

構造化された GitHub MCP 呼び出しを使用する

• issue の一覧取得を 1 回呼び出し、結果をキャッシュする
• 詳細が必要な場合に限り、対象を絞って呼び出す
• ラベルの更新をまとめて行う

削減量：bash を繰り返し呼び出す場合と比べて、トークンを約 40% 削減

Issue の一覧をキャッシュする

# First prompt
"Fetch the last 20 issues, save list in memory"

# Subsequent prompts
"Analyze issue #5 from cached list"
"Mark #7-#9 as duplicate"

最初の投稿と最近のコメントに注目する

• 50 件のコメントがあるスレッドをすべて読まない
• 最初の投稿に目を通して、コンテキストを把握する
• 更新内容を確認するため、直近 2～3 件のコメントを確認する

避けるべきパターン

❌ 避ける：

# One-by-one processing
"Check issue #234"
"Now check issue #235"
"Now check issue #236"
→ Wastes tokens on repeated context loading

# Over-analyzing
Reading entire 100-comment thread
Checking all related PRs
Deep diving into code for each issue
→ Diminishing returns after certain point

# Premature closing
Closing issues without proper investigation
Missing duplicates due to poor search
→ Frustrates users, creates duplicate work

✅ 推奨：

# Batch operations
"Triage issues #234-250, categorize, prioritize"

# Quick triage decisions
Fast categorization → Can revisit if needed
Surface-level analysis for most issues
Deep dive only for critical/complex ones

# Thorough duplicate search
Quick keyword search before marking duplicate
Link to specific comment if clarification exists

自動化の機会

古くなった Issue を自動でクローズする

# Issues with no activity for 90 days and "needs-more-info" label
"Find stale issues (>90 days, needs-more-info label), 
suggest closing with polite message"

キーワードでラベルを付ける

# Auto-label based on content
"java.lang.NullPointerException" → bug
"add support for" → enhancement
"how do I" → question

週次サマリー

# Generate triage summary
"Summarize issues from last week:
- New bugs: X
- Feature requests: Y
- Questions: Z
- Closed: W"

GitHub との統合

GitHub MCP を使用する

// Structured workflow
1. list_issues → get open issues
2. get_issue → details for each
3. add_labels → categorize
4. create_comment → respond
5. close_issue → if needed

gh CLI を使用する

# List issues
gh issue list --json number,title,labels,body

# View specific issue
gh issue view 234

# Add labels
gh issue edit 234 --add-label "bug,high-priority"

# Comment
gh issue comment 234 --body "Thanks for reporting..."

# Close
gh issue close 234 --comment "Fixed in v2.1"

追跡する指標

各トリアージセッションの後に、次の内容を報告します。

📊 Triage Summary
─────────────────
Issues processed: 15
├─ Bugs: 5 (2 critical, 3 high)
├─ Enhancements: 4
├─ Questions: 3
├─ Duplicates: 2
└─ Invalid: 1

Actions taken:
├─ Labeled: 15
├─ Responded: 12
├─ Closed: 3
└─ Milestoned: 5

Time saved: ~45 minutes (vs manual)
Token usage: 3,200 tokens

ベストプラクティス

1. 定期的に実施する - 週次でトリアージを行うと、バックログを防げます
2. 敬意を持って対応する - ユーザーは時間をかけて報告してくれています
3. リソースへのリンクを追加する - ドキュメント、関連する Issue、例などを案内します
4. 質問する - 推測するより、確認するほうが適切です
5. コントリビューションを歓迎する - コミュニティの参加を促します
6. 傾向を追跡する - よくある問題は、ドキュメントに不足があることを示しています
7. 報告者に感謝する - 適切なバグ報告をしてくれたユーザーに感謝します
8. 明確にクローズする - Issue をいつまでも放置しないようにします

ワークフローの例

# Monday morning triage
claude code ~/projects/pf4j

> view .claude/skills/issue-triage/SKILL.md
> "Triage the last 15 issues from pf4j/pf4j,
   categorize, prioritize and suggest responses"

[Claude analyzes and presents summary]

> "Apply labels and post the suggested responses"

[Claude executes actions]

> "Generate summary for release notes"

結果：手動で約 45 分かかる作業を、約 10 分で 15 件の Issue のトリアージが完了