rtk-triage

/rtk-triage

RTK triage orchestrator. Merges issue-triage + pr-triage and produces a cross-analysis.

---

When to use

• Weekly or before each sprint
• When the PR/issue backlog grows quickly
• To identify duplicates before reviewing

---

4-phase workflow

Phase 0 — Preconditions

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

Check that the current date is known (use date +%Y-%m-%d).

---

Phase 1 — Data gathering (parallel)

Launch both collections simultaneously:

Issues :

gh repo view --json nameWithOwner -q .nameWithOwner

gh issue list --state open --limit 150 \
  --json number,title,author,createdAt,updatedAt,labels,assignees,body

gh issue list --state closed --limit 20 \
  --json number,title,labels,closedAt

gh api "repos/{owner}/{repo}/collaborators" --jq '.[].login'

PRs :

# Fetcher toutes les PRs ouvertes — paginer si nécessaire (gh limite à 200 par appel)
gh pr list --state open --limit 200 \
  --json number,title,author,createdAt,updatedAt,additions,deletions,changedFiles,isDraft,mergeable,reviewDecision,statusCheckRollup,body

# Si le repo a >200 PRs ouvertes, relancer avec --search pour paginer :
# gh pr list --state open --limit 200 --search "is:pr is:open sort:updated-desc" ...

# Pour chaque PR, récupérer les fichiers modifiés (nécessaire pour overlap detection)
# Prioriser les PRs candidates (même domaine, même auteur)
gh pr view {num} --json files --jq '[.files[].path] | join(",")'

---

Phase 2 — Individual triage

Run the analyses of /issue-triage and /pr-triage separately (same logic as the individual skills) to produce:

Issues :

• Categorization (Bug/Feature/Enhancement/Question/Duplicate)
• Risk (Red/Yellow/Green)
• Staleness (>30d)
• Map issue_number → [PR numbers] via scan fixes #N, closes #N, resolves #N

PRs :

• Size (XS/S/M/L/XL)
• CI status (clean/dirty)
• Our PRs vs external
• Overlaps (>50% files in common between 2 PRs)
• Clusters (author with 3+ PRs)

Display the standard tables of each skill (see SKILL.md of issue-triage and pr-triage for the exact format).

---

Phase 3 — Cross-analysis (core of this skill)

This is where this skill adds value beyond the two individual skills.

3.1 Double coverage — 2 PRs for 1 issue

For each issue linked to ≥2 PRs (via scanning bodies + file overlap):

Issue	PR1 (info)	PR2 (info)	Recommended verdict
#N (title)	PR#X — author, size, CI	PR#Y — author, size, CI	Keep the most targeted one. Close/coordinate the other

Verdict rule:

• Prefer the smaller one (XS < S < M) if same scope
• Prefer CI clean over CI dirty
• Prefer "our PRs" if one is internal
• If file overlap >80% → near-certain conflict, flag it

3.2 Security coverage gaps

For each red issue (#640-type security review):

• List the sub-findings mentioned in the body
• Cross-reference with existing PRs (keywords in title/body)
• Identify findings without a PR

Format:

## Issue #N — security review (finding par finding)
| Finding | PR associée | Status |
|---------|-------------|--------|
| Description finding 1 | PR#X | En review |
| **Description finding critique** | **AUCUNE** | ⚠️ Trou |

3.3 P0/P1 bugs without PR

Issues labeled P0 or P1 (or keywords: "crash", "truncat", "cap", "hardcoded") without any linked PR.

Format:

## Bugs critiques sans PR
| Issue | Titre | Pattern commun | Effort estimé |
|-------|-------|----------------|---------------|

Look for a common pattern (e.g. "hardcoded cap", "lost exit code") — if 3+ bugs share a pattern, suggest a grouped sprint.

3.4 Our dirty PRs — likely causes

For each internal PR with CI dirty or CONFLICTING:

• Check if another PR touches the same files
• Check if a recent merge to develop could explain the conflict
• Recommend: rebase, close, or wait

Format:

## Nos PRs dirty
| PR | Issue(s) | Cause probable | Action |
|----|----------|----------------|--------|

3.5 PRs without a tracked issue

Internal PRs without fixes #N in the body — flag for traceability.

---

Phase 4 — Final output

Display the complete cross-analysis (sections 3.1 → 3.5)

Then display the numerical summary:

## Résumé chiffré — YYYY-MM-DD

| Catégorie | Count |
|-----------|-------|
| PRs prêtes à merger (nos) | N |
| Quick wins externes | N |
| Double couverture (conflicts) | N paires |
| P0/P1 bugs sans PR | N |
| Security findings sans PR | N |
| Nos PRs dirty à rebaser | N |
| PRs à fermer (recommandé) | N |

Save to claudedocs

date +%Y-%m-%d  # Pour construire le nom de fichier

Save to claudedocs/RTK-YYYY-MM-DD.md with:

• The issues + PRs triage tables (Phase 2)
• The complete cross-analysis (Phase 3)
• The numerical summary

Confirm: Sauvegardé dans claudedocs/RTK-YYYY-MM-DD.md

---

Saved file format

# RTK Triage — YYYY-MM-DD

Croisement issues × PRs. {N} PRs ouvertes, {N} issues ouvertes.

---

## 1. Double couverture
...

## 2. Trous sécurité
...

## 3. P0/P1 sans PR
...

## 4. Nos PRs dirty
...

## 5. Nos PRs prêtes à merger
...

## 6. Quick wins externes
...

## 7. Actions prioritaires
(liste ordonnée par impact/urgence)

---

## Résumé chiffré
...

---

Rules

• Language: argument en/fr. Default: fr. GitHub comments always remain in English.
• Never post GitHub comments without user validation (AskUserQuestion).
• If >200 issues or >200 PRs: warn the user and paginate (rerun with --search or gh api with pagination).
• The cross-analysis (Phase 3) is always executed — that is the added value of this skill.
• The claudedocs file is saved automatically unless the user says "no save".