feat: add PR triage dashboard skill - #196
Conversation
Adds /triage-prs slash command that classifies all open PRs by module, review state, scope, and architectural impact to produce a prioritized triage dashboard for maintainers. 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 significant enhancement to the PR management workflow by adding a new Claude Code command. This command automates the process of generating a comprehensive and prioritized dashboard for open pull requests, helping maintainers efficiently identify and address PRs that require immediate attention. The new tool aims to streamline review processes and improve overall repository health by providing clear insights into PR status, scope, and potential conflicts. 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 /triage-prs skill, which is a great addition for managing pull requests. The implementation is well-structured as a detailed prompt for the AI. I've provided a couple of suggestions to make the GitHub API calls more robust and efficient by using specific flags for filtering, which should improve the reliability and performance of the skill.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR adds a new /triage-prs Claude command that creates a comprehensive dashboard for triaging open pull requests in the repository. The command fetches PR metadata, classifies PRs by module/scope/nature, assesses review state and CI status, and produces a prioritized dashboard showing which PRs need attention.
Changes:
- Adds
.claude/commands/triage-prs.mdwith a 7-step workflow for PR analysis and dashboard generation - Implements module-based classification covering LLM, Agent Core, Tools, Channels, Storage, Security, Sandbox, and other areas
- Includes filtering by label and author, staleness detection, and conflict identification
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| gh pr list --state open --limit 100 --json number,title,author,labels,additions,deletions,headRefName,createdAt,isDraft,reviewRequests,reviews,files | ||
| ``` | ||
|
|
||
| If `$ARGUMENTS` contains `--label=<X>` or `--author=<X>`, add the corresponding flags to the `gh pr list` command. |
There was a problem hiding this comment.
The instruction says "filter the results accordingly" but doesn't specify how to implement the filtering for --label and --author arguments. The gh pr list command supports native --label and --author flags that should be used. Consider adding explicit instructions like:
"If $ARGUMENTS contains --label=, add --label '' to the gh pr list command. If it contains --author=, add --author '' to the gh pr list command."
This ensures consistent implementation and leverages GitHub CLI's built-in filtering.
| If `$ARGUMENTS` contains `--label=<X>` or `--author=<X>`, add the corresponding flags to the `gh pr list` command. | |
| If `$ARGUMENTS` contains `--label=<X>`, append `--label '<X>'` to the `gh pr list` command. If `$ARGUMENTS` contains `--author=<X>`, append `--author '<X>'` to the `gh pr list` command. |
|
|
||
| | Category | Directories | | ||
| |----------|------------| | ||
| | **LLM & Inference** | `src/llm/`, `src/llm/provider.rs`, `src/llm/nearai.rs`, etc. | |
There was a problem hiding this comment.
The module classification table lists "src/llm/provider.rs, src/llm/nearai.rs, etc." as examples under LLM & Inference. However, this creates ambiguity since it mixes directory paths (src/llm/) with specific file paths. Since these are files within src/llm/, they're already covered by the directory pattern "src/llm/".
Consider simplifying to just "src/llm/" to avoid confusion, or clarify that the specific file mentions are just illustrative examples of what's in that directory.
| | **LLM & Inference** | `src/llm/`, `src/llm/provider.rs`, `src/llm/nearai.rs`, etc. | | |
| | **LLM & Inference** | `src/llm/` | |
| - Key risk areas to focus review on | ||
|
|
||
| ### Changes Requested (Waiting on Author) | ||
| PRs where a reviewer asked for changes. Include who requested and a 1-line summary of what's needed. |
There was a problem hiding this comment.
The dashboard section "Changes Requested (Waiting on Author)" says to "Include who requested" the changes, but the data fetched in Step 1 only includes the reviews array. To identify WHO requested changes, you'd need to parse the reviews data to find review authors where state == "CHANGES_REQUESTED".
Consider adding explicit instructions in Step 3 to extract reviewer information from the reviews data, or clarify in Step 7 that "who requested" refers to data available in the reviews array from Step 1.
| PRs where a reviewer asked for changes. Include who requested and a 1-line summary of what's needed. | |
| PRs where a reviewer asked for changes (based on reviews where `state == "CHANGES_REQUESTED"`). For each PR, use the `reviews` array from Step 1 to extract the reviewer(s) who requested changes, and include their names plus a 1-line summary of what's needed. |
| - Staleness: how many days since last push/comment? | ||
|
|
||
| ## Step 4: Determine scope and risk | ||
|
|
There was a problem hiding this comment.
Step 3 mentions checking "how many days since last push/comment" for staleness, but Step 1 only fetches createdAt. To properly calculate staleness based on last activity:
- The gh pr list command should include "updatedAt" in the --json fields, or
- Additional API calls are needed to determine last push/comment time
Without this data, staleness can only be calculated from creation date, which won't identify PRs that were active initially but have since gone stale. Consider adding "updatedAt" to the Step 1 query.
| - New provider abstractions | ||
| - Changes touching 5+ modules | ||
| - Anything modifying the agent loop, session model, or security layer | ||
| - New dependencies (check Cargo.toml changes) |
There was a problem hiding this comment.
Line 99 says to check "New dependencies (check Cargo.toml changes)" as part of architectural classification. However, the files field from Step 1 only lists filenames, not the actual diff content. To detect new dependencies:
- Check if "Cargo.toml" appears in the files list (indicates potential dependency changes), or
- Use gh pr diff to examine the actual changes (which would require fetching diffs for each PR)
Consider clarifying that this check should look for Cargo.toml in the changed files list, or note that the Task tool should be used to fetch diffs when needed for detailed classification.
| - New dependencies (check Cargo.toml changes) | |
| - New dependencies (if `Cargo.toml` appears in the changed files list, or identified via `gh pr diff` when you fetch diffs with the Task tool) |
| - **Reviewed (comments only)** — Human comments but no formal approve/reject | ||
| - **Automated only** — Only bot reviews (gemini-code-assist, copilot, etc.) | ||
| - **No review** — No reviews at all | ||
|
|
There was a problem hiding this comment.
The review state assessment mentions distinguishing between "human" and "bot" reviews (line 55: "gemini-code-assist, copilot, etc."), but doesn't provide guidance on how to identify bot reviewers.
The command should clarify how to detect bot reviews. Common approaches include:
- Checking if the reviewer's login contains "bot" or ends with "[bot]"
- Checking the reviewer's type field in the GitHub API response
- Maintaining a known list of bot reviewer names
Without clear criteria, different executions might classify the same reviews inconsistently.
| When classifying reviews as human vs bot: | |
| - Treat a review as a **bot** review if the reviewer’s `type` field in the GitHub API/`gh` JSON is `Bot` (or equivalent). | |
| - Also treat a review as a **bot** review if the reviewer login: | |
| - ends with `[bot]`, or | |
| - clearly indicates a bot account (e.g., contains `-bot` or is in a maintained allowlist of known bot reviewers such as `gemini-code-assist`, `github-actions[bot]`, `copilot`, etc.). | |
| - All other reviewers should be treated as **human** for the purposes of the review state categories above. |
| | **Small** | 50-200 lines, 1-5 files | | ||
| | **Medium** | 200-500 lines, 3-10 files | | ||
| | **Large** | 500-2000 lines, 5-20 files | | ||
| | **XL** | 2000+ lines or 20+ files | | ||
|
|
||
| ## Step 5: Classify as fix vs. architectural | ||
|
|
There was a problem hiding this comment.
The scope classification uses "lines changed" as a criterion, but doesn't specify whether this means total lines (additions + deletions), net lines (additions - deletions), or just additions.
Since Step 1 fetches both "additions" and "deletions" fields separately, the command should clarify which metric to use. Most PR size classifications use total changes (additions + deletions) to reflect the review burden. Consider adding: "lines changed = additions + deletions".
| Fetch every open PR with metadata: | ||
|
|
||
| ``` | ||
| gh pr list --state open --limit 100 --json number,title,author,labels,additions,deletions,headRefName,createdAt,isDraft,reviewRequests,reviews,files |
There was a problem hiding this comment.
Step 6 instructs to "look at 'Closes #N' / 'Fixes #N' in PR bodies" but Step 1 doesn't fetch the PR body field. The gh pr list command in Step 1 only fetches: number, title, author, labels, additions, deletions, headRefName, createdAt, isDraft, reviewRequests, reviews, files.
To detect superseded PRs and dependency chains as described, either:
- Add "body" to the --json fields in Step 1, or
- Use gh pr view for each PR to fetch bodies (which would be expensive for many PRs)
Without the body field, this analysis cannot be completed as specified.
| gh pr list --state open --limit 100 --json number,title,author,labels,additions,deletions,headRefName,createdAt,isDraft,reviewRequests,reviews,files | |
| gh pr list --state open --limit 100 --json number,title,author,labels,additions,deletions,headRefName,createdAt,isDraft,reviewRequests,reviews,files,body |
|
|
||
| ### Fixes (merge fast) | ||
| - Bug fixes with clear root cause | ||
| - Security patches | ||
| - Crash/panic prevention | ||
| - Typo/doc corrections | ||
| - Code quality (removing .unwrap(), etc.) | ||
|
|
||
| ### Features (standard review) | ||
| - New functionality within existing patterns | ||
| - New tool implementations | ||
| - Configuration additions | ||
| - Test additions | ||
|
|
||
| ### Architectural (deep review needed) | ||
| - New modules or subsystems | ||
| - Changes to core traits or interfaces | ||
| - New database backends or storage engines | ||
| - New provider abstractions | ||
| - Changes touching 5+ modules | ||
| - Anything modifying the agent loop, session model, or security layer | ||
| - New dependencies (check Cargo.toml changes) | ||
|
|
||
| ## Step 6: Detect conflicts and superseded PRs | ||
|
|
There was a problem hiding this comment.
Step 5 requires classifying PRs by their nature (fixes, features, architectural) based on criteria like "Bug fixes with clear root cause", "Security patches", "New modules or subsystems", etc. However, this classification requires understanding the PR's semantic content and intent, which cannot be reliably determined from just the metadata fetched in Step 1 (title, labels, files, etc.).
To make this classification feasible, consider:
- Relying primarily on PR labels (bug, enhancement, breaking-change, etc.) if the repository uses them
- Using title patterns (e.g., "fix:", "feat:", "refactor:" conventional commit prefixes)
- Adding instructions to fetch PR bodies (as noted in comment Codex/feature parity pr hook #6) for more context
- Making it clear this is a best-effort heuristic classification that may need human judgment
Without additional guidance, this step may be too subjective and inconsistent across executions.
| ``` | ||
|
|
||
| ### Ready to Merge |
There was a problem hiding this comment.
The "Quick Stats" section shows counts for various states: "Open: N | Draft: N | Needs review: N | Changes requested: N | Ready to merge: N". However, these categories have overlaps:
- "Draft" PRs are also "Open"
- "Changes requested" PRs might also "Need review" after changes are made
- "Ready to merge" PRs are also "Open"
Consider clarifying the counting logic, such as:
- Open (total) | Draft | Ready to merge | Needs review | Changes requested | Stale
Or use mutually exclusive categories that sum to the total Open count.
- Add body and updatedAt to PR query fields for superseded detection - Use --label/--author flags directly instead of post-filtering - Use date-based --search for merged PRs instead of --limit 20 - Simplify LLM module listing, add missing module categories - Use updatedAt for staleness, clarify lines changed metric Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Addressed review feedback in 4e3c4b2: Fixed (7 items):
Not changed (5 items — false positives for an LLM prompt):
|
* feat: add PR triage dashboard skill Adds /triage-prs slash command that classifies all open PRs by module, review state, scope, and architectural impact to produce a prioritized triage dashboard for maintainers. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * fix: address review feedback on triage-prs skill - Add body and updatedAt to PR query fields for superseded detection - Use --label/--author flags directly instead of post-filtering - Use date-based --search for merged PRs instead of --limit 20 - Simplify LLM module listing, add missing module categories - Use updatedAt for staleness, clarify lines changed metric 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> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
* feat: add PR triage dashboard skill Adds /triage-prs slash command that classifies all open PRs by module, review state, scope, and architectural impact to produce a prioritized triage dashboard for maintainers. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * fix: address review feedback on triage-prs skill - Add body and updatedAt to PR query fields for superseded detection - Use --label/--author flags directly instead of post-filtering - Use date-based --search for merged PRs instead of --limit 20 - Simplify LLM module listing, add missing module categories - Use updatedAt for staleness, clarify lines changed metric 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> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Summary
/triage-prsslash command for Claude Code that produces a prioritized, module-grouped PR triage dashboardTest plan
/triage-prsin Claude Code and verify dashboard output--labeland--authorargument filtering works🤖 Generated with Claude Code