Que fait promo-scout ?
Intelligence de promotion générique et vérifiée. C'est l'inverse d'un récupérateur de battage médiatique : rien n'atteint le tableau sans que l'état live de GitHub ne le soutienne, et le jugement est rendu par consensus sshx (perspectives isolées + table de vérité), pas par la parole d'un seul modèle.
Nécessite : gh authentifié avec votre auth GitHub existante, soit via gh auth login ou GH_TOKEN, et le skill sshx accessible à l'appelant.
Quand l'utiliser
Un agent ou un opérateur souhaite, pour un dépôt/organisation cible : ce qui est réellement promouvable maintenant, comment les pièces se connectent entre les dépôts, et quelles affirmations tentantes ne sont PAS vérifiables.
Étape 0 — confirmer le périmètre explicite AVEC L'UTILISATEUR
Il n'y a pas de périmètre large par défaut pour tout le compte. Exigez que l'utilisateur nomme :
- une organisation entière (dépôts publics uniquement par défaut),
- un ou plusieurs dépôts spécifiques (
owner/repo), ou - une liste mixte.
Confirmez également
REPO_LIMITpour les cibles d'organisation (par défaut, les 12 dépôts publics les plus récemment actifs). La collecte de dépôts privés nécessite une acceptation explicite avec--include-private; n'utilisez pas ce drapeau à moins que l'utilisateur ne l'ait confirmé.
Étape 1 — récupérer l'état live (déterministe ; s'exécute depuis n'importe où)
Exécutez le récupérateur fourni avec une cible explicite :
python3 scripts/promo_scout_fetch.py <org | owner/repo> [autres...] # périmètre public par défaut
python3 scripts/promo_scout_fetch.py --include-private <org | owner/repo> [autres...] # seulement après confirmation explicite
Il écrit /tmp/promo_scout_bundle.json : par dépôt, le README principal, les commits récents, les releases, les PRs ouvertes, les issues récentes. C'est la SEULE preuve que l'étape de consensus peut utiliser.
Étape 2 — exécuter un consensus sshx réel sur le bundle
Invoquez le skill sshx (délégation de travailleurs, perspectives isolées, codex-cli workers) avec cette décision, en fournissant le bundle comme entrée fixe :
En considérant UNIQUEMENT ce bundle d'état live GitHub, produisez trois listes. (1) Promouvables : éléments qui valent vraiment la peine d'être promus maintenant — chacun DOIT citer une preuve concrète du bundle (un tag de release, un commit daté, une capacité du README). (2) Connexions : liens inter-dépôts où le travail d'un dépôt se compose avec celui d'un autre, chacun soutenu par un signal réel dans le bundle (PRs partagées, mentions de dépendances, capacités complémentaires). (3) Abandonnés : affirmations tentantes que le bundle NE soutient PAS, avec la preuve manquante. Pas de sur-promesse ; si la preuve est absente, elle va dans Abandonnés, pas dans Promouvables.
Utilisez des perspectives de réflexion sshx distinctes, par exemple : une lentille de promouvabilité, une lentille de connexion inter-dépôts, et une lentille de sceptique / chasseur de sur-promesses. Exigez la convergence selon la table de vérité sshx ; respectez abstain lorsque les travailleurs ne peuvent pas établir une affirmation.
Étape 3 — émettre le tableau
Écrivez le résultat convenu sous forme de tableau (markdown + JSON optionnel) : ## Promouvables maintenant, ## Connexions, ## Abandonnés (non vérifiable). Chaque élément promouvable ou de connexion porte sa preuve du bundle en ligne. La liste Abandonnés est obligatoire — c'est elle qui donne sa crédibilité au tableau.
Garde-fous
- Pas de preuve, pas de publication. Le bundle live est la seule source ; pas de mémoire externe, pas de chiffres gonflés.
- Les connexions/synthèse doivent ÉMERGER du consensus sur l'état live — n'injectez pas un récit pré-écrit.
- Honnête par construction : non vérifiable → Abandonné ; lorsque le consensus ne peut être atteint, rapportez
abstain, pas une supposition.