Summary

3-phase issue backlog management with audit, deep analysis, and validated triage actions. Use when triaging GitHub issues, sorting bug reports, cleaning up stale tickets, or detecting duplicate issues. Args: 'all' to analyze all, issue numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit only.

SKILL.md

Issue Triage

3-phase workflow for maintainers: automated audit of all open issues, opt-in deep analysis via parallel agents, and validated triage actions (comments, labels, closures).

When to Use This Skill

| Skill | Usage | Output | |-------|-------|--------| | `/issue-triage` | Sort, analyze, and act on an issue backlog | Triage tables + analysis + executed actions | | `/pr-triage` | Sort, review, and comment on a PR backlog | Triage table + reviews + posted comments |

**Triggers**:

  • Manually: `/issue-triage` or `/issue-triage all` or `/issue-triage 42 57`
  • Proactively: when >10 open issues without label, or stale issues >30 days detected

---

Language

  • Check the argument passed to the skill
  • If `en` or `english` → tables and summary in English
  • If `fr`, `french`, or no argument → French (default)
  • Note: GitHub comments and labels (Phase 3) are ALWAYS in English (international audience)

---

Configuration

Thresholds used throughout the workflow. Edit to match your project:

| Parameter | Default | Description | |-----------|---------|-------------| | `staleness_days` | 30 | Days without activity before flagging as stale | | `very_stale_days` | 90 | Days without activity before flagging as very stale | | `jaccard_threshold` | 60% | Minimum Jaccard similarity to flag two issues as duplicates | | `closed_compare_count` | 20 | Number of recent closed issues to compare for duplicate detection | | `open_limit` | 100 | Maximum open issues to fetch and analyze |

---

Preconditions

git rev-parse --is-inside-work-tree
gh auth status

If either fails, stop and explain what is missing.

---

Phase 1 — Audit (always executed)

Data Gathering (parallel commands)

# Repo identity
gh repo view --json nameWithOwner -q .nameWithOwner

# Open issues (exclude PRs, limit 100)
gh issue list --state open --limit 100 \
  --json number,title,author,createdAt,updatedAt,labels,body,comments,assignees,milestone

# Recent closed issues (for duplicate detection)
gh issue list --state closed --limit 20 \
  --json number,title,body,labels,stateReason

# Open PRs (bodies for cross-reference detection)
gh pr list --state open --limit 50 --json number,title,body

# Collaborators (to distinguish reporter types)
gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'

**Collaborators fallback**: if `gh api .../collaborators` returns 403/404:

# Extract authors from last 10 merged PRs
gh pr list --state merged --limit 10 --json author --jq '.[].author.login' | sort -u

If still ambiguous, ask via `AskUserQuestion`.

**Note**: `comments` field in `gh issue list --json comments` returns the count, not content. For Phase 2, fetch full content separately: `gh issue view {num} --json comments`.

Analysis Dimensions

Run all 6 dimensions for each open issue:

#### 1. Categorization

Classify each issue by reading `title` + first 200 chars of `body`:

| Category | Label | Criteria | |----------|-------|----------| | Bug | `bug` | Describes broken behavior, unexpected output, crash | | Feature Request | `enhancement` | Asks for new functionality | | Question / Support | `question` | User asking how something works | | Documentation | `documentation` | Missing or incorrect docs | | Out of Scope | `wontfix` | Clearly outside project boundaries | | Unclear | `needs-info` | Body empty, too vague to categorize |

If body is empty → category is always `Unclear` (never assume).

#### 2. Cross-reference to PRs

Scan each open PR body for references to the issue number:

  • Patterns:

<!-- truncated -->

View raw file