| name | radar |
| description | Scanne issues, PRs, branches, milestones, CI et roadmap.md de Redface 2 et produit un rapport en 4 buckets (urgent / court terme / roadmap proche / gros chantiers). Spécialisé Redface 2 (lit la phase courante depuis methodology.md, les milestones, les dépendances externes déclarées dans roadmap.md). Mode `collecte` par défaut (signaux objectifs), mode `score` en argument pour avis subjectif. |
| argument-hint | [score] — sans argument: collecte brute. Avec 'score' ou 'triage': ajoute une couche de scoring subjective. |
| disable-model-invocation | true |
/radar — radar repo Redface 2
Objectif
Faire le tour rapide de l'état du repo et produire une liste actionnable de quoi faire ensuite. Pas un audit, pas une review : un radar court qui catégorise issues / PRs / branches / CI / roadmap pour que le contributeur (humain ou agent) attaque le bon truc.
Spécialisé Redface 2 :
- connaît les phases (
docs/specs/roadmap.md, milestones GitHub Phase N — *)
- détecte les blocages structurels en lisant
docs/specs/roadmap.md (sections "prérequis externes", graphe mermaid de dépendances) et les corps d'issues du milestone courant (cherche bloque #N, dépend de #N, prérequis #N dans la description, ou les références d'autres issues via gh issue view <n> --json body). Ne pas hardcoder les numéros d'issues dans ce skill : ils dérivent dès qu'une issue est scindée ou fermée. Utiliser uniquement la roadmap canonique et les liens entre issues.
- connaît la méthodologie triple-hybride et le fait que le projet n'a pas de dates fermes — les phases sont ordonnées par dépendances, pas datées (cf.
docs/specs/methodology.md)
Quand l'invoquer
- Début de session quand on hésite sur la prochaine action.
- Avant d'ouvrir une nouvelle PR pour vérifier qu'on ne marche pas sur une PR existante.
- Avant un sync (humain ↔ agent, ou cross-agent) pour partager une vue d'ensemble.
- Après une grosse merge pour voir ce que ça débloque.
Modes
| Mode | Argument | Sortie |
|---|
| Collecte (défaut) | aucun | Buckets remplis avec signaux objectifs uniquement (CI rouge, PR >14j, milestone courant, etc.). Aucune opinion, aucun classement à l'intérieur d'un bucket. |
| Score | score ou triage | Même collecte + couche subjective : score 1-5 par item (impact × effort × débloque-quoi) et top-3 recommandé pour la prochaine session. |
Le mode collecte est sûr (on ne se trompe pas en restituant des faits). Le mode score est une opinion d'agent : utile en lecture rapide, mais à recouper avec le jugement humain. Toujours afficher mode: collecte ou mode: score en tête du rapport.
Étapes
1. Source of truth — phase courante
Lire :
docs/specs/roadmap.md → lister les phases et leur statut (À faire, En cours, Fait).docs/specs/methodology.md → noter le mode opérationnel courant (spec / prototype / TDD).- Milestones GitHub :
gh api repos/ForumHFR/redface2/milestones --jq '.[] | {title, due_on, open_issues, closed_issues}'.
La phase active = première phase avec open_issues > 0 ET dont les phases précédentes sont closes ou marquées « non bloquantes ». Ne pas inférer un statut depuis les dates des milestones — due_on est indicatif, pas contractuel.
2. Collecte des signaux
Tous les signaux ci-dessous sont objectifs (vrai/faux, pas d'opinion). Lancer en parallèle quand possible.
| Signal | Commande | Bucket par défaut |
|---|
CI rouge sur main | gh run list -R ForumHFR/redface2 --workflow=ci.yml --branch=main --limit 5 --json conclusion,createdAt | Urgent |
| CI rouge sur PR ouverte | gh pr list -R ForumHFR/redface2 --json number,statusCheckRollup --jq '.[] | select(.statusCheckRollup[]?.conclusion=="FAILURE")' | Urgent |
| Security alerts (Dependabot) | gh api repos/ForumHFR/redface2/dependabot/alerts --jq '.[] | select(.state=="open") | {severity:.security_advisory.severity, package:.dependency.package.name, summary:.security_advisory.summary}' | Urgent (severity ≥ moderate) |
| PR ouverte >14j sans review | gh pr list -R ForumHFR/redface2 --state open --json number,title,createdAt,reviewDecision | jq '[.[] | select((now - (.createdAt | fromdateiso8601)) > 1209600 and .reviewDecision != "APPROVED")]' | Urgent |
| PR ouverte récente (< 14j) | gh pr list -R ForumHFR/redface2 --state open | Court terme |
Issues priority:high ou bug ouvertes | gh issue list -R ForumHFR/redface2 --state open --label "bug" (le projet n'a pas encore de label priority:* ; ajouter ici les labels qui apparaissent plus tard) | Urgent si bug, sinon bucket de la phase concernée |
| Issues du milestone courant | gh issue list -R ForumHFR/redface2 --state open --milestone "<phase courante>" | Roadmap proche |
| Issues phase suivante | même commande, milestone N+1 | Gros chantiers |
| Issues phases ultérieures (N+1, N+2, …) | une commande par phase, ex. for p in phase-2 phase-3 phase-4 phase-5; do gh issue list -R ForumHFR/redface2 --state open --label "$p" --json number,title,labels; done. ⚠️ gh issue list --label "a,b,c" filtre en AND (intersection), pas en OR — ne pas utiliser en CSV pour une union de phases. | Gros chantiers |
| Branches feature actives | git branch -r --list 'origin/feature/*' --sort=-committerdate | head -10 | annoter chaque PR avec sa branche pour repérer les branches sans PR |
| Branches sans PR | comparer git branch -r --list 'origin/feature/*' avec gh pr list --json headRefName --jq '.[].headRefName' | Court terme (à transformer en PR ou nettoyer) |
| TODO/FIXME récents (commits derniers 30j) | voir bloc bash ci-dessous (commande sortie de la table car contient | qui casse l'échappement Markdown) | Court terme |
| Drafts ADR | for f in docs/adr/0*.md; do status=$(awk '/^## Statut/{getline; getline; print; exit}' "$f"); echo "$f → $status"; done puis filtrer ceux dont le statut commence par Proposé. ⚠️ Le statut est à 2 lignes après l'en-tête ## Statut (ligne vide intermédiaire) — un grep -A1 '## Statut' ne fonctionne pas. | Gros chantiers (décisions structurelles à acter) |
| Dépendances externes | extraire la liste depuis docs/specs/roadmap.md (graphe mermaid des dépendances + sections « prérequis externes » des phases) — chercher les repos en cylindre ou cités explicitement, puis pour chaque repo gh repo view <owner>/<repo> --json updatedAt. ⚠️ Les noms de repos cités à date dans roadmap.md (ex. XaaT/hfr-redkit pour MPStorage2, XaaT/hfr-redflag pour le Worker) sont plus stables que les numéros d'issues mais peuvent quand même bouger (rename, archive, transfert) — ne pas les hardcoder ici, lire la roadmap. | Gros chantiers + flag « bloquant Phase N » |
Commande TODO/FIXME (sortie de la table car | casserait les colonnes Markdown — pattern shell complet ici, à copier-coller tel quel) :
git log --since="30 days ago" --pickaxe-regex -S 'TODO|FIXME' --oneline -- '*.kt' '*.md' | head -20
git show <sha> -- '*.kt' '*.md' | grep -E '^\+.*\b(TODO|FIXME)\b'
⚠️ Éviter git log -p brut sur 30 jours : génère le diff complet de tous les commits .kt/.md avant de filtrer, lent dès que le repo grossit. --pickaxe-regex -S filtre côté Git et ne diff que les commits qui modifient effectivement une occurrence. Le pattern doit être 'TODO|FIXME' (POSIX ERE — \| est BRE et matche le caractère | littéral, pas une alternance).
Notes :
gh api dependabot/alerts peut retourner 404 si Dependabot n'est pas activé sur le repo — c'est un signal en soi (à activer ?), pas une erreur du skill. Le rapporter en ℹ️.- Toujours filtrer les issues
state:open. Le radar ne re-traite pas le clos.
- Pour les issues, toujours afficher le numéro et le label de phase (ex.
#15 [phase-1] HfrParser …) — le numéro est le levier principal.
3. Buckets
Quatre buckets, dans cet ordre. Toujours rendre les quatre, même vides ((rien) dans ce cas).
3.1 Urgent
Bloquants immédiats. Doit pouvoir être attaqué dans la session courante.
- CI rouge sur
main ou sur une PR ouverte
- Security alerts sévérité ≥ moderate
- PR ouverte >14j sans review et sans activité (signal de stagnation)
- Issues
bug ouvertes (en attendant un label priority:high)
3.2 Court terme (cette semaine)
Éléments qui méritent d'être tranchés rapidement mais pas critiques.
- PR ouvertes <14j (statut review, CI, derniers commentaires)
- Branches feature locales sans PR (à transformer ou supprimer)
- TODO/FIXME ajoutés dans les commits des 30 derniers jours
- Issues
bug non triées dans une phase
3.3 Roadmap proche (phase courante)
Issues attachées au milestone de la phase courante (cf. § 1).
- Trier par : présence d'un blocage déclaré dans la description → bloquantes en premier, puis grosses (label
architecture, storage, navigation), puis le reste.
- Annoter chaque issue avec la liste de ses dépendances connues (ex.
#3 PostRenderer ← bloquée par #15 HfrParser).
- Phase courante par défaut détectée auto en § 1 ; le contributeur peut override en passant un argument (à étendre plus tard).
3.4 Gros chantiers (phases suivantes + structurels)
- Issues des phases N+1 et au-delà.
- ADRs
Proposé non actées.
- Dépendances externes (lire la liste depuis
roadmap.md à chaque run, ne pas hardcoder ici) — flagger comme 🔗 externe.
- Initiatives spec-only (pas encore d'issue) repérées dans
roadmap.md comme « À acter ».
4. Mode score (optionnel)
Si l'argument est score ou triage :
- Pour chaque item, scorer impact (1-5) × effort inverse (1 = gros / 5 = petit) × débloque (nb d'autres items que ça libère, plafonné à 3).
- Trier l'intérieur de chaque bucket par score décroissant.
- Ajouter en tête de rapport un top-3 « si tu n'attaques qu'une chose cette semaine, attaque … » — avec une justification d'une phrase par item.
- Toujours rappeler :
Score subjectif (mode score) — recouper avec le jugement humain.
Ne jamais scorer en mode collecte. Ne jamais ajouter de top-3 en mode collecte. Si le mode est ambigu, défaut = collecte.
Format de sortie
## /radar Redface 2 — <YYYY-MM-DD>
mode: <collecte | score>
phase courante: <Phase N — Nom> (milestone: N open / M closed)
mode opérationnel: <spec | prototype | TDD selon methodology.md>
### 🚨 Urgent
- (rien) ou liste
### ⏱️ Court terme
- ...
### 🗺️ Roadmap proche (phase courante)
- ...
### 🏔️ Gros chantiers
- ...
---
ℹ️ Notes (signaux secondaires, dépendances externes, drafts ADR, etc.)
Variante mode score : ajouter avant les buckets :
### ⭐ Top 3 recommandé (mode score)
1. **#NNN — <titre>** (score X/Y) — <justification 1 phrase>
2. ...
3. ...
Notes
- Le skill ne modifie rien : c'est un radar lecture-seule. Aucun
gh issue create, gh pr comment, push, ni édition de fichiers. Si une action est suggérée, c'est au contributeur (ou à un autre skill) de la déclencher.
- Les commandes réseau (
gh, git fetch) doivent être autorisées par l'agent ou l'humain. Le skill assume que la session a au moins gh auth status OK et un git fetch récent — sinon il le note dans le rapport.
- Si le repo n'a pas encore de tags
phase-N ou de milestones (cas projet jeune), tomber en mode dégradé : afficher la liste brute des issues open sans bucket roadmap. Le rapport reste utile.
- Le mode
score est explicitement marqué « subjectif ». Jamais utilisé pour une décision automatisée — c'est une aide à la lecture, pas une priorité figée.
- Couplage avec d'autres skills :
/preflight avant pour vérifier que gh est OK ; /spec-reality pour le pendant code/spec (le radar ne touche pas à la cohérence interne) ; /spec-audit pour un audit lourd des specs (radar = court, audit = long).
