issue-triage

Issue 分类技能

通过分类和优先级排序，高效处理 Java 项目的 GitHub issue。

适用场景

• 用户说“分类 issue”／“查看近期 issue”
• 定期维护工作流
• 假期／休息后（处理积压事项）
• 每周／每月的 issue 审查

前置条件

推荐：配置 GitHub MCP 服务，以优化 token 使用

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

替代方案：使用 gh CLI（token 使用效率较低）

工作流

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 报告 ✅

判断依据：

• 包含堆栈跟踪或错误消息
• 提供了复现步骤
• 描述了预期行为与实际行为的差异
• 提及了具体版本号

操作：

• 添加标签：bug
• 根据描述确认是否可复现
• 检查是否存在重复 Bug
• 如果问题严重，将其加入里程碑

示例：

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

功能请求 💡

判断依据：

• 请求新增功能
• 描述了使用场景
• 出现“如果能……就好了”／“能否添加……”等表述
• 提供了理由

操作：

• 添加标签：enhancement
• 评估其与项目目标的一致性
• 如果并非简单改动，将其标记为待讨论
• 征求社区反馈

问题／支持 ❓

判断依据：

• 出现“如何……”／“有人能帮忙吗……”等表述
• 涉及配置／使用问题
• 既不是 Bug，也不是功能请求

操作：

• 添加标签：question
• 提供答案或文档链接
• 对复杂问题，建议前往 StackOverflow 寻求帮助
• 如果问题已解决，在回答后关闭

重复项 🔄

搜索相似 issue：

• 使用 GitHub 搜索：is:issue <keywords>
• 检查近期已关闭的 issue
• 查找相同的错误消息

操作：

• 链接到原 issue：“Duplicate of #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）🟡

标准：

• 边缘情况 Bug
• 价值明确的功能增强
• 文档缺失
• 偶尔影响部分用户

操作：

• 添加标签：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.

已确认的 Bug

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!

Token 优化策略

批量处理

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

节省：与逐个处理相比，token 用量减少约 60%

使用结构化的 GitHub MCP 调用

• 调用一次以列出 issue → 缓存结果
• 仅在需要时针对性地调用以获取详细信息
• 批量更新标签

节省：与重复调用 bash 相比，token 用量减少约 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

自动化机会

自动关闭过期问题

# 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. 链接相关资源 - 文档、相关问题和示例
4. 提出问题 - 澄清总比妄下假设好
5. 欢迎贡献 - 鼓励社区参与
6. 跟踪问题模式 - 常见问题可能表明文档存在不足
7. 感谢报告者 - 感谢用户提交高质量的错误报告
8. 果断关闭 - 不要让问题无限期搁置

工作流示例

# 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"

结果：约 10 分钟内完成 15 个问题的分类处理，而手动处理约需 45 分钟