action-audit

Règles

• Cette skill est strictement en lecture seule. Ne modifiez, ne créez, ne supprimez aucun fichier.
• Pas d'appels API mutants. Les requêtes gh api GET sont autorisées librement. N'utilisez pas -X POST, -X PUT, -X PATCH, ou -X DELETE.
• Signalez l'incertitude. Si un résultat est ambigu, notez-le dans le rapport plutôt que de deviner.

Modes

• incident (par défaut) : Recherche ciblée d'une action spécifique — utilisée quand une action est compromise ou dépréciée.
• audit : Balayage de tous les fichiers de workflow à l'échelle de l'organisation pour détecter tout référence d'action non épinglée.

Étape 1 : Analyser le contexte

Déterminez le mode à partir de la demande de l'utilisateur :

• Si l'utilisateur nomme une action spécifique (p. ex., tj-actions/changed-files), utilisez le mode incident.
• Si l'utilisateur demande un balayage général des actions non épinglées, utilisez le mode audit.
• Si une action de remplacement est mentionnée, notez-la pour l'étape de remédiation (gérée séparément par la skill action-remediate).

Étape 2 : Rechercher à l'échelle de l'organisation

Mode incident — recherchez l'action spécifique :

gh search code "uses: <action-name>" --owner <org> --path .github/workflows/ --limit 100

Recherchez également sans le préfixe uses: pour capturer les références indirectes :

gh search code "<action-name>" --owner <org> --path .github/workflows/ --limit 100

Mode audit — trouvez tous les fichiers de workflow avec des références d'action non épinglées (non épinglées sur un SHA complet) :

gh search code "uses:" --owner <org> --path .github/workflows/ --limit 100

Filtrez ensuite les résultats pour trouver les lignes uses: qui NE correspondent PAS au motif @[a-f0-9]{40} (c'est-à-dire non épinglées sur un hash).

Remarque : Les index de recherche de code GitHub peuvent accuser un décalage de quelques minutes à quelques heures après un push récent. Les résultats peuvent ne pas refléter les commits les plus récents. Signalez cette mise en garde dans la sortie.

Étape 3 : Analyser et afficher les résultats

Pour chaque résultat, déterminez :

1. Repo et chemin du fichier
2. Valeur uses: actuelle (ligne complète)
3. Statut d'épinglage :
   • hash — épinglé sur un SHA complet de 40 caractères (conforme)
   • tag — épinglé sur une balise de version (p. ex., @v3, @v1.2.3)
   • branch — pointant vers une branche (p. ex., @main)
   • none — pas d'épinglage du tout

Affichez un tableau :

En mode incident, incluez tous les statuts. En mode audit, omettez les lignes hash (déjà conformes).

S'il n'y a aucun résultat, informez l'utilisateur et arrêtez.

Étape 4 : Résoudre les SHAs

Mode incident :

Déterminez l'approche de remédiation :

• Si l'utilisateur a mentionné une action de remplacement : notez-la dans le rapport.
• Sinon : résolvez le hash sûr pour l'épinglage.

Résolvez le SHA :

gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha'

Où <owner>/<repo> est le repo de l'action et <ref> est la balise cible ou main.

Présentez à l'utilisateur :

• SHA résolu
• Lien de vérification : https://github.com/<owner>/<repo>/commit/<sha>

Demandez : « Ce SHA vous semble-t-il correct ? Tapez yes pour confirmer, ou fournissez un SHA différent. »

Attendez la confirmation avant de finaliser le rapport.

Mode audit :

Pour chaque action unique trouvée non épinglée, résolvez son SHA le plus récent actuel de la même manière et présentez une liste groupée pour que l'utilisateur l'examine.

Étape 5 : Rapport de synthèse

Affichez un rapport de synthèse final :

Informez l'utilisateur qu'il peut utiliser la skill action-remediate pour appliquer les corrections basées sur ces résultats.