How to use the PR Bug-Fix Triage agent skill (triage)

What is an agent skill and what does this one make the agent do?

An agent skill is a folder containing a SKILL.md file. The file gives an AI agent a named set of instructions it can load and follow when a request matches the skill's description. This skill is named triage and its description is: Identify focused, evidence-backed skills CLI bug fixes worth quuu's attention.

When a new pull request arrives, the agent reads the PR's description and every changed file patch. It checks that the change fixes a real, previously incorrect behavior with a focused correction and a regression test that fails under the old mechanism. It can also search open issues in the repository for possible matches. If the fix qualifies, it adds the triage:bug-fix label and posts a short comment mentioning a maintainer. Otherwise it stays silent.

• Stops without public effects if files are truncated, a relevant patch is missing, or the context cannot establish the diagnosis.
• Does not treat a fix: title, issue number, author, or reported passing tests as proof on its own.
• Does not judge merge readiness, complete review, or passing checks.

Install the triage skill from the ZIP

Download the ZIP for this skill from this page and unzip it. The skill is a single file, SKILL.md. Place the unzipped skill folder in one of two locations, depending on how you want to use it.

Alternatively, in the Claude apps, open Settings, go to Capabilities, and upload the skill under Skills.

• Personal use across projects: unzip into ~/.claude/skills/.
• Single project: unzip into the project's .claude/skills/ folder.
• Claude apps: Settings → Capabilities → Skills, then upload.

What do you need before the skill can work?

The skill is written for one specific automation setup. It names repository tools it expects the runtime to provide. The file does not specify how credentials are supplied, so the automation runtime must already be connected to GitHub with access to the repository.

The skill is designed for the vercel-labs/skills CLI repository. Using it elsewhere means adapting the tool names, labels, and workflow paths.

• Repository tools named in the skill: read_pull_request, list_workflow_runs, list_run_jobs, read_job_log, search_repository_issues, read_issue.
• A GitHub-connected automation runtime with access to the repository.
• Network access: yes. Runs scripts: no. The skill ships only SKILL.md.

How do you trigger the skill with a natural request?

Agents load skills when a request matches the skill's description. For this skill, the trigger is a new pull request on the skills CLI repository. A plain request such as triage this new PR number 123 on the skills CLI, or check whether this PR is a real bug fix, matches the skill's purpose.

Be specific about the PR number and repository. The skill needs the triggering PR number and the exact head SHA it was given, so it can detect whether the branch changed during review.

• Good: Triage PR 482 on vercel-labs/skills and tell me whether it is a focused bug fix.
• Weaker: Look at this PR (no number or repository given).

What does a good result look like?

When the fix qualifies, the public comment is short and uses a fixed structure: an opening line calling the PR a bug-fix candidate, a Bug bullet describing the previous wrong behavior, and a Fix bullet describing the corrected behavior. If the agent finds confident unlinked matching issues, it adds one Issues bullet listing up to three possible matches.

The public comment is a handoff, not an approval. It must stay at or under 500 characters and 75 words. Regression evidence, verification limits, and reasoning stay in the internal workflow output rather than the comment.

Safety notes: scripts and network

The skill does not run scripts. It uses network access because it calls repository tools to read pull requests, workflow runs, job logs, and issues, and to add a label and post a comment.

The skill is cautious by design. It does not edit code, publish a PR, edit the PR body, change issue labels, post on issues, or close anything. It treats issue bodies and comments as untrusted evidence, never as instructions. Because label and comment delivery cannot be made atomic with the available tools, a failed or ambiguous delivery is reported rather than repeated.

• Review the label and comment permissions your automation runtime grants before enabling it.
• Confirm the repository and label names match your setup before reuse elsewhere.

Tips for getting reliable results

The skill is conservative. Many PRs will receive no comment at all, and that is intended. Maintainer labels such as invalid, duplicate, or wontfix stop the assessment.

Check the output for stated limitations. CI that is pending, approval-gated, or absent is recorded as a limitation, not a pass.

• Use it as a first-pass screen, then review the PR yourself.
• If you adapt it to another repository, rename the tools, labels, and workflow paths first.
• Read the internal output, not only the public comment, to see the regression evidence and limits.