decebals Issue Triage Skill
Efficiently triage GitHub issues for Java projects with categorization and prioritization.
When to Use
- User says "triage issues" / "check recent issues"
- Regular maintenance workflow
- After vacation/break (backlog processing)
- Weekly/monthly issue review
Prerequisites
Recommended: GitHub MCP server configured for optimal token usage
claude mcp add github --transport http \
https://api.githubcopilot.com/mcp/
Alternative: Use gh CLI (less token-efficient)
Workflow
1. Fetch Issues
With GitHub MCP (recommended):
Tool: list_issues
Parameters: {
"state": "open",
"sort": "updated",
"per_page": 10
}
With gh CLI:
gh issue list --state open --limit 10 --json number,title,labels,body,url
2. Categorize Each Issue
Analyze issue content and assign category:
Bug Report ✅
Indicators:
- Has stack trace or error message
- Steps to reproduce provided
- Expected vs actual behavior described
- Mentions specific version numbers
Actions:
- Label:
bug - Verify reproducibility from description
- Check for duplicate bugs
- Add to milestone if critical
Example:
Issue #234: "NPE when loading plugin from directory"
- Stack trace: ✅
- Reproduction steps: ✅
- Version info: ✅
→ Label: bug, high-priority
Feature Request 💡
Indicators:
- Asks for new functionality
- Use case described
- "It would be nice if..." / "Could you add..."
- Rationale provided
Actions:
- Label:
enhancement - Assess alignment with project goals
- Mark for discussion if non-trivial
- Ask for community feedback
Question/Support ❓
Indicators:
- "How do I..." / "Can someone help..."
- Configuration/usage questions
- Not a bug or feature request
Actions:
- Label:
question - Provide answer or link to docs
- Suggest StackOverflow for complex help
- Close after answer if resolved
Duplicate 🔄
Search for similar issues:
- Use GitHub search:
is:issue <keywords> - Check recently closed issues
- Look for same error messages
Actions:
- Link to original: "Duplicate of #123"
- Close with polite comment
- Ask reporter to comment on original if they have additional info
Invalid/Unclear ⚠️
Indicators:
- Missing critical information
- Off-topic or spam
- Not enough context to proceed
Actions:
- Request clarification with template
- Set "needs-more-info" label
- Auto-close if no response after 14 days
3. Priority Assessment
Critical (P0) 🔴
Criteria:
- Security vulnerability
- Data loss/corruption risk
- Complete functionality breakdown
- Affects production systems
Actions:
- Label:
critical - Notify maintainers immediately
- Add to current milestone
- Consider hotfix release
Examples:
- "SQL injection vulnerability in plugin loader"
- "All plugins fail to load after upgrade"
- "ClassLoader leak causes OutOfMemoryError"
High (P1) 🟠
Criteria:
- Core feature broken
- Affects many users
- Workaround exists but painful
- Regression from previous version
Actions:
- Label:
high-priority - Add to next milestone
- Include in release notes
Examples:
- "Plugin dependencies not resolved correctly"
- "Hot reload crashes application"
Medium (P2) 🟡
Criteria:
- Edge case bug
- Enhancement with clear value
- Documentation gap
- Affects some users occasionally
Actions:
- Label:
medium-priority - Consider for future milestone
- Good for contributors
Examples:
- "Improve error message for invalid plugin"
- "Add plugin lifecycle listener"
Low (P3) 🟢
Criteria:
- Nice-to-have feature
- Cosmetic issues
- Very rare edge case
- Documentation improvements
Actions:
- Label:
low-priority - "Contributions welcome" tag
- Backlog for future
Examples:
- "Add more examples to README"
- "Typo in JavaDoc"
4. Response Templates
Need More Information
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.
Duplicate
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.
Won't Fix (with rationale)
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.
Acknowledged 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
Feature Request - Under Consideration
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]
Question Answered
To achieve this, you can [solution].
Example:
\`\`\`java
[code example]
\`\`\`
Also check our documentation: [link]
Let me know if this solves your issue!
Token Optimization Strategies
Batch Processing
# Process multiple issues in one prompt
"Triage issues #234-243, categorize and prioritize"
Savings: ~60% fewer tokens vs one-by-one
Use Structured GitHub MCP Calls
- One call to list issues → cache results
- Targeted calls for details only when needed
- Batch label updates
Savings: ~40% fewer tokens vs repeated bash calls
Cache Issue List
# First prompt
"Fetch the last 20 issues, save list in memory"
# Subsequent prompts
"Analyze issue #5 from cached list"
"Mark #7-#9 as duplicate"
Focus on First Post + Recent Comments
- Don't read entire 50-comment threads
- Skim first post for context
- Check last 2-3 comments for updates
Anti-patterns
❌ Avoid:
# 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
✅ Prefer:
# 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
Automation Opportunities
Auto-close stale issues
# 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"
Label by keywords
# Auto-label based on content
"java.lang.NullPointerException" → bug
"add support for" → enhancement
"how do I" → question
Weekly summary
# Generate triage summary
"Summarize issues from last week:
- New bugs: X
- Feature requests: Y
- Questions: Z
- Closed: W"
Integration with GitHub
With 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
With 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"
Metrics to Track
After each triage session, report:
📊 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
Best Practices
- Regular cadence - Weekly triage prevents backlog
- Be respectful - Users took time to report
- Link resources - Docs, related issues, examples
- Ask questions - Better to clarify than assume
- Welcome contributions - Encourage community involvement
- Track patterns - Common issues suggest documentation gaps
- Celebrate reporters - Thank users for good bug reports
- Close decisively - Don't let issues linger indefinitely
Example Workflow
# 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"
Result: 15 issues triaged in ~10 minutes vs ~45 minutes manual