Conversation
Adds a /triage-issues skill that classifies open GitHub issues into bugs and feature requests, ranks bugs by severity and features by opportunity, and flags under-specified issues needing clarification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary of ChangesHello @ilblackdragon, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a powerful new skill for automated GitHub issue triage. It significantly enhances issue management by providing a structured approach to classify, rank, and analyze open issues, offering maintainers actionable insights and streamlining the process of identifying critical bugs, high-opportunity features, and issues requiring further clarification. The new command aims to improve project efficiency by making issue backlogs more manageable and transparent. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new issue triage skill, which is well-structured and detailed. I've found a few issues in the skill definition that could cause errors or incorrect behavior. Specifically, there are problems with the gh commands used for fetching issues, including a non-portable date command and an invalid field in the JSON output. Additionally, the formulas for calculating bug severity and feature opportunity scores have incorrect maximum values. My review comments provide specific suggestions to fix these issues.
| Fetch every open issue with metadata: | ||
|
|
||
| ``` | ||
| gh issue list --state open --limit 200 --json number,title,author,labels,assignees,createdAt,updatedAt,body,comments,milestone |
There was a problem hiding this comment.
The gh issue list command uses an invalid field comments in the --json flag. This will likely cause the command to fail or not return the intended data. You should replace comments with commentsCount. To better support the logic on line 251 for ranking by engagement, you could also add reactionGroups. Full comment content should be fetched with gh issue view as implied on line 245.
| gh issue list --state open --limit 200 --json number,title,author,labels,assignees,createdAt,updatedAt,body,comments,milestone | |
| gh issue list --state open --limit 200 --json number,title,author,labels,assignees,createdAt,updatedAt,body,commentsCount,reactionGroups,milestone |
There was a problem hiding this comment.
Fixed in 8f02d8b — changed to commentsCount and added reactionGroups for engagement scoring.
| Also fetch recently closed issues (last 14 days) to detect duplicates and already-resolved work: | ||
|
|
||
| ``` | ||
| gh issue list --state closed --search "closed:>=$(date -v-14d +%Y-%m-%d)" --limit 100 --json number,title,body,labels,closedAt |
There was a problem hiding this comment.
The date -v-14d command is specific to BSD/macOS. It will fail on GNU/Linux systems, which are common in containerized environments where this skill might run. To make the command portable, you should use the GNU date syntax: date -d '14 days ago'.
| gh issue list --state closed --search "closed:>=$(date -v-14d +%Y-%m-%d)" --limit 100 --json number,title,body,labels,closedAt | |
| gh issue list --state closed --search "closed:>=$(date -d '14 days ago' +%Y-%m-%d)" --limit 100 --json number,title,body,labels,closedAt |
There was a problem hiding this comment.
Not changing — this matches the existing triage-prs.md pattern (date -v-7d) and the project targets macOS (darwin). Keeping BSD syntax for consistency across skills.
| | 2 | **Moderate** | Affects one module or a specific configuration | | ||
| | 1 | **Narrow** | Affects edge case or single obscure path | | ||
|
|
||
| **Bug severity score** = Impact × 2 + Urgency + Scope (max 17) |
There was a problem hiding this comment.
There's a miscalculation in the bug severity score. The formula is Impact × 2 + Urgency + Scope. With maximum values of Impact=4, Urgency=3, and Scope=3, the maximum score is 4*2 + 3 + 3 = 14, not 17 as stated. This should be corrected to reflect the correct maximum base score.
| **Bug severity score** = Impact × 2 + Urgency + Scope (max 17) | |
| **Bug severity score** = Impact × 2 + Urgency + Scope (max 14) |
There was a problem hiding this comment.
Fixed in 8f02d8b — corrected to "base max 14" with one-time +2 boost (max 16). Also adjusted the severity thresholds in the report section.
| | 2 | **Almost ready** | Needs minor clarification, but scope is understood | | ||
| | 1 | **Not ready** | Needs design discussion, has open questions, blocked by other work | | ||
|
|
||
| **Opportunity score** = Value × 2 + Effort + Readiness (max 17) |
There was a problem hiding this comment.
Similar to the bug severity score, there's a miscalculation in the feature opportunity score. The formula is Value × 2 + Effort + Readiness. With maximum values of Value=4, Effort=3, and Readiness=3, the maximum score is 4*2 + 3 + 3 = 14, not 17 as stated. This should be corrected to reflect the correct maximum base score.
| **Opportunity score** = Value × 2 + Effort + Readiness (max 17) | |
| **Opportunity score** = Value × 2 + Effort + Readiness (max 14) |
There was a problem hiding this comment.
Fixed in 8f02d8b — same correction applied: "base max 14", one-time +2 boost (max 16).
There was a problem hiding this comment.
Pull request overview
This PR adds a comprehensive issue triage slash command (/triage-issues) that provides automated classification and prioritization of GitHub issues. The command categorizes open issues into bugs and feature requests, scores them using multi-dimensional rubrics (bugs by severity, features by opportunity), assesses specification quality, and generates an actionable triage report with recommendations. It supports filtering by labels and milestones and is designed as a read-only analysis tool.
Changes:
- Added
/triage-issuescommand with intelligent bug/feature classification, multi-factor scoring system (severity and opportunity), and comprehensive triage reporting - Implemented detail level assessment (well-specified/adequate/under-specified) and detection of duplicates, stale issues, and already-fixed issues
- Added support for
--labeland--milestonefiltering with actionable recommendations for issue management
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| **Bug severity score** = Impact × 2 + Urgency + Scope (max 17) | ||
|
|
||
| Also boost the score by +2 if the issue: |
There was a problem hiding this comment.
The stated maximum score of 17 is mathematically incorrect. The base formula (Impact × 2 + Urgency + Scope) has a maximum of 13 (4×2 + 3 + 3 = 13). The boost conditions (lines 96-99) add +2 per condition, but it's unclear whether this is +2 total or +2 per matching condition. If +2 per condition, the actual maximum is 19 (13 + 6). If +2 total for any condition, the maximum is 15 (13 + 2). Either way, stating "max 17" is inaccurate and could confuse users about the scoring system. Please clarify the boost logic and correct the maximum value accordingly.
| **Bug severity score** = Impact × 2 + Urgency + Scope (max 17) | |
| Also boost the score by +2 if the issue: | |
| **Bug severity score** = Impact × 2 + Urgency + Scope (base max 13, boosted max 19) | |
| Also boost the score by +2 for each of the following that applies: |
There was a problem hiding this comment.
Fixed in 8f02d8b — corrected to "base max 14". Note: 4×2+3+3=14, not 13. Boost is clarified as one-time +2 (max 16).
| **Opportunity score** = Value × 2 + Effort + Readiness (max 17) | ||
|
|
||
| Also boost by +2 if: |
There was a problem hiding this comment.
The stated maximum score of 17 is mathematically incorrect. The base formula (Value × 2 + Effort + Readiness) has a maximum of 13 (4×2 + 3 + 3 = 13). The boost conditions (lines 135-138) add +2, but it's unclear whether this is +2 total or +2 per matching condition. If +2 per condition, the actual maximum is 19 (13 + 6). If +2 total for any condition, the maximum is 15 (13 + 2). Either way, stating "max 17" is inaccurate. This should match the clarification made for bug severity scoring to maintain consistency.
| **Opportunity score** = Value × 2 + Effort + Readiness (max 17) | |
| Also boost by +2 if: | |
| **Opportunity score** = Value × 2 + Effort + Readiness (base range: 1–13) | |
| Then add a one-time +2 bonus (not per bullet, overall max 15) if any of the following are true: |
There was a problem hiding this comment.
Fixed in 8f02d8b — corrected max and clarified boost is one-time +2 (max 16), matching the bug severity pattern.
| gh issue list --state closed --search "closed:>=$(date -v-14d +%Y-%m-%d)" --limit 100 --json number,title,body,labels,closedAt | ||
| ``` | ||
|
|
||
| **Exclude pull requests** — `gh issue list` may include PRs. Filter out any item whose number matches an open PR, or that has a `pull_request` field. |
There was a problem hiding this comment.
The instruction to exclude pull requests lacks implementation guidance. Line 28 says to "Filter out any item whose number matches an open PR, or that has a pull_request field," but the gh issue list command on line 17 doesn't provide information to enable this filtering. The implementer would need additional instructions on how to obtain the list of open PRs or how to check if an issue number corresponds to a PR. Consider adding explicit instructions such as: "First fetch the list of open PR numbers with 'gh pr list --state open --json number' and exclude any issue numbers that match."
There was a problem hiding this comment.
Fixed in 8f02d8b — added explicit gh pr list --state open --json number --jq '.[].number' command for filtering.
| - Is labeled `security` | ||
| - Is a regression (worked before, broken now) |
There was a problem hiding this comment.
The scoring system may double-count security issues and regressions. Line 83 defines Urgency level 3 as including "Security issue" and "regression in recent release," but lines 98-99 also add a +2 boost for issues labeled security or identified as regressions. This means a security regression could receive both a high Urgency score (3) and two separate +2 boosts (one for security, one for regression), effectively counting these attributes multiple times. Consider clarifying whether the boost is intended as additional emphasis beyond the urgency score, or whether issues that already have high urgency due to these factors should not receive the boost to avoid double-counting.
| - Is labeled `security` | |
| - Is a regression (worked before, broken now) | |
| - Is labeled `security` and was **not** already rated **Urgent (3)** primarily because it is a security issue | |
| - Is a regression (worked before, broken now) and was **not** already rated **Urgent (3)** primarily because it is a regression |
There was a problem hiding this comment.
The double-counting is intentional. Urgency captures time-sensitivity for scoring, while the boost is an organizational signal to float critical items to the very top. A security regression should rank higher than a regular security bug.
| gh issue list --state open --limit 200 --json number,title,author,labels,assignees,createdAt,updatedAt,body,comments,milestone | ||
| ``` | ||
|
|
||
| If `$ARGUMENTS` contains `--label=<X>`, append `--label '<X>'` to the command. If it contains `--milestone=<X>`, append `--milestone '<X>'` to the command. |
There was a problem hiding this comment.
The instructions at this line direct composing a gh issue list shell command by interpolating user-controlled arguments (--label=<X>, --milestone=<X>) into a single-quoted string without escaping embedded quotes. An attacker who controls the argument value (e.g., by getting someone to run /triage-issues --label='foo'; rm -rf ~; ') can break out of the quotes and inject arbitrary shell commands executed by the Bash tool, leading to code execution on the operator’s machine. To fix this, avoid constructing shell commands via string concatenation and instead pass arguments as separate, safely-escaped parameters or ensure any single quotes in <X> are robustly escaped before use.
| If `$ARGUMENTS` contains `--label=<X>`, append `--label '<X>'` to the command. If it contains `--milestone=<X>`, append `--milestone '<X>'` to the command. | |
| If `$ARGUMENTS` contains `--label=<X>`, extract `<X>` into a variable (for example `LABEL_FILTER`) and pass it to the tool as a separate, safely quoted argument, e.g. `gh issue list ... --label "$LABEL_FILTER"`. Likewise, if it contains `--milestone=<X>`, extract `<X>` into `MILESTONE_FILTER` and pass it as `--milestone "$MILESTONE_FILTER"`; avoid constructing a single shell command string with unescaped interpolation. |
There was a problem hiding this comment.
Not applicable — this is a skill prompt interpreted by Claude Code, not a shell script. $ARGUMENTS is expanded by the skill system before Claude sees it, and Claude constructs the gh command itself. No string concatenation or shell injection vector. Matches the identical pattern in triage-prs.md line 20.
- Fix invalid `comments` field to `commentsCount` + add `reactionGroups` - Correct severity/opportunity max scores from 17 to base 14 (boosted 16) - Clarify boost is one-time (+2 if any condition matches) - Add explicit `gh pr list` command for PR exclusion filtering - Adjust severity/opportunity thresholds in report section Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat: add issue triage skill Adds a /triage-issues skill that classifies open GitHub issues into bugs and feature requests, ranks bugs by severity and features by opportunity, and flags under-specified issues needing clarification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: address PR review feedback on issue triage skill - Fix invalid `comments` field to `commentsCount` + add `reactionGroups` - Correct severity/opportunity max scores from 17 to base 14 (boosted 16) - Clarify boost is one-time (+2 if any condition matches) - Add explicit `gh pr list` command for PR exclusion filtering - Adjust severity/opportunity thresholds in report section Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Illia Polosukhin <ilblacdragon@gmail.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat: add issue triage skill Adds a /triage-issues skill that classifies open GitHub issues into bugs and feature requests, ranks bugs by severity and features by opportunity, and flags under-specified issues needing clarification. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: address PR review feedback on issue triage skill - Fix invalid `comments` field to `commentsCount` + add `reactionGroups` - Correct severity/opportunity max scores from 17 to base 14 (boosted 16) - Clarify boost is one-time (+2 if any condition matches) - Add explicit `gh pr list` command for PR exclusion filtering - Adjust severity/opportunity thresholds in report section Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Illia Polosukhin <ilblacdragon@gmail.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Summary
/triage-issuesslash command that classifies all open GitHub issues into bugs and feature requests--labeland--milestonefiltersTest plan
/triage-issueson a repo with mixed open issues and verify classification--label=bugfilter and confirm only matching issues appear🤖 Generated with Claude Code