# Issue Triage

Triage a GitHub issue into something actionable, reproduce the claim, find duplicates...

- Repository: https://github.com/ParadevAI/Paradev (15823 stars)
- Category: Git and review
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ParadevAI/Paradev --skill issue-triage -g -a claude-code -y`
Codex: `npx skills add ParadevAI/Paradev --skill issue-triage -g -a codex -y`
Cursor: `npx skills add ParadevAI/Paradev --skill issue-triage -g -a cursor -y`
Gemini CLI: `npx skills add ParadevAI/Paradev --skill issue-triage -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ParadevAI/Paradev`

## Description

Triage a GitHub issue into something actionable, reproduce the claim, find duplicates, judge severity, and apply labels, milestone, and assignee. Use when the user asks to triage an issue, sort the backlog, deal with new issues, check whether a bug is already reported, or says "what should we do with this issue".

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Triage a GitHub issue

Triage answers three questions in order: **is it real, is it new, and how urgent is it.**
Labels and assignees come last. Applying labels without answering the first three is
filing, not triage.

## 1. Read it as written

Fetch the issue and its comments. Separate what the reporter **observed** from what they
**concluded**. "The API returns 500 when I pass an empty array" is an observation.
"The validation layer is broken" is a conclusion, and it is frequently wrong even when the
observation is right. Triage the observation.

Note what is missing: version, environment, reproduction steps, actual vs expected. You
need these to judge severity, but ask for them only after step 2, most issues that look
under-specified turn out to be duplicates of a well-specified one.

## 2. Search for duplicates before anything else

This is the step that gets skipped and the one that saves the most work.

Search the issue's distinctive terms, an error string, a function name, a status code, rather than its title. Titles describe symptoms in the reporter's words; error text is
stable across reporters. Search **closed** issues too: a bug closed as fixed and reported
again means a regression, which is a different and more urgent finding than a new bug.

When you find a duplicate, comment linking both directions and close the newer one, unless
the newer report contains a better reproduction, in which case close the older and carry
the good repro forward.

## 3. Reproduce, or say plainly that you did not

If the repo is checked out and the issue has steps, run them. Record the result in a
comment: what you ran, what happened, on what version.

If you cannot reproduce, say which specific step failed and what you saw instead. Never
label something `cannot-reproduce` on the strength of not having tried, an unreproduced
bug that gets closed and refiled three times costs more than the ten minutes of trying.

## 4. Judge severity on impact, not volume

The rest: https://github.com/ParadevAI/Paradev/blob/HEAD/plugins/github/skills/issue-triage/SKILL.md