Skip to content
Back to skills

Triage Pr

ASecurity

Triage a pull request — fetch metadata, check status, summarize failing CI logs, ingest reviewer comments, and propose next steps.

  • 56 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 20, 2026
code-qualitygoshellgitapi

Works with

  • api

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add block/proto-fleet --skill triage-pr --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Triage Pr?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Triage Pr
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/block-triage-pr/badge)](https://www.skillsdirectory.com/skills/block-triage-pr)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: triage-pr
description: Triage a pull request — fetch metadata, check status, summarize failing CI logs, ingest reviewer comments, and propose next steps.
argument-hint: <pr-number-or-url>
---

Triage the PR number or URL supplied with the skill invocation. Save it as
`pr_ref`. Goal: give the user a one-screen status read so
they can decide what to do next without reading the GitHub UI.

## Steps

1. **Validate `pr_ref` before any shell call.** The argument must
   match exactly one of:
   - Bare PR number: `^[0-9]+$`
   - Canonical GitHub PR URL:
     `^https://github\.com/[A-Za-z0-9](?:[A-Za-z0-9-]{0,38})/[A-Za-z0-9._-]+/pull/[0-9]+$`

   The URL pattern matches GitHub's actual username/repo charset (owners
   are 1–39 chars from `[A-Za-z0-9-]` with no leading hyphen; repos are
   `[A-Za-z0-9._-]`). If neither matches, stop and ask the user for a
   clean identifier.

   When passing `pr_ref` to a shell command, ALWAYS double-quote it
   (`gh pr view "$pr_ref"`, not `gh pr view $pr_ref`). The regex
   is the first defense; the quote is the second. **After step 2, prefer
   JSON-derived values** (`number`, parsed `owner`/`repo` from the `url`
   field) over re-using `pr_ref` for any further API call.
2. Fetch PR metadata:
   `gh pr view "$pr_ref" --json number,title,state,isDraft,mergeable,mergeStateStatus,headRefName,baseRefName,author,reviewDecision,statusCheckRollup,url`

   Capture from the response:
   - `number` — the canonical PR number (use this, not `pr_ref`, in
     URL paths going forward)
   - `owner` and `repo` — parsed from the `url` field (which is
     `https://github.com/<owner>/<repo>/pull/<n>`). The URL is gh's
     output, not user input, so it's safe to parse via shell parameter
     expansion or `sed`.
3. Fetch check status:
   `gh pr checks "$pr_ref"`
4. Summarize in this shape:
   - **PR**: number, title, author, branch
   - **State**: open/closed/merged, draft, mergeable status
   - **Reviews**: approval state
   - **CI**: count of pending / failing / passing checks. Name the failing
     ones explicitly.
5. For each failing check, fetch logs:
   - Get the run URL via `gh pr checks "$pr_ref" --json name,state,link`
     and filter where `state == "FAILURE"`. The integer after `/runs/` in
     the `link` URL is the run ID.
   - Fetch failing logs: `gh run view <run-id> --log-failed`. Identify
     the root-cause line — test name, lint rule, or compile error.
     Surface that, not the full log.
6. Map failing checks to likely culprit areas using the PR diff:
   `gh pr diff "$pr_ref" --name-only` — match against the workflow
   that failed (e.g. `protofleet-server-checks.yml` failing with `server/`
   diffs is straightforward; failing without `server/` diffs is suspicious).
7. **Pull and triage reviewer feedback.** Use the JSON-derived `owner`,
   `repo`, and `number` from step 2:
   - Line comments: `gh api "repos/$owner/$repo/pulls/$number/comments"`
   - Issue comments: `gh api "repos/$owner/$repo/issues/$number/comments"`
   - Reviews: `gh pr view "$pr_ref" --json reviews`

   Dedupe findings that appear from multiple sources (the same path:line
   flagged by both Copilot and Codex is one finding, not two). For each
   unique finding, classify:
   - **Priority** — use the comment's own badge (`P0`/`P1`/`P2`,
     low/medium/high) if present; otherwise infer from severity language.
   - **Status** — `valid` (real, needs fix), `already-addressed` (fixed
     in a later commit on the branch — re-check the current code on disk),
     `invalid` (false positive, with a brief reason), or
     `needs-discussion`.

   Output a punch-list table: file:line | source | priority | finding |
   status. Skip purely informational bot output (e.g. "auto-formatted N
   files"). Group the table after the CI section in the final summary.
8. Propose the next concrete action based on the CI summary AND the
   comment triage. Examples: "Fix the failing test in X", "Address the
   P1 from Codex re: <thing>", "Rerun CI (probably flaky)", "This needs
   a rebase against main", "Approval is the only blocker".

## Notes

- Do NOT push a fix, post a reply, or rerun checks. Triage is read-only.
- If the PR is in another repo, pass the URL form to `gh pr view`.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…