rtk-triage

/rtk-triage

Orchestrateur de triage RTK. Fusionne issue-triage + pr-triage et produit une analyse croisée.

---

Quand utiliser

• Hebdomadaire ou avant chaque sprint
• Quand le backlog PR/issues grossit rapidement
• Pour identifier les doublons avant de reviewer

---

Workflow en 4 phases

Phase 0 — Préconditions

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

Vérifier que la date actuelle est connue (utiliser date +%Y-%m-%d).

---

Phase 1 — Data gathering (parallèle)

Lancer les deux collectes simultanément :

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 — Triage individuel

Exécuter les analyses de /issue-triage et /pr-triage séparément (même logique que les skills individuels) pour produire :

Issues :

• Catégorisation (Bug/Feature/Enhancement/Question/Duplicate)
• Risque (Rouge/Jaune/Vert)
• Staleness (>30j)
• Map issue_number → [PR numbers] via scan fixes #N, closes #N, resolves #N

PRs :

• Taille (XS/S/M/L/XL)
• CI status (clean/dirty)
• Nos PRs vs externes
• Overlaps (>50% fichiers communs entre 2 PRs)
• Clusters (auteur avec 3+ PRs)