hypergadam/agent-skills

Revue de code Go

Objectif : le changement doit améliorer la santé de la base de code. Il n'a pas besoin d'être parfait. Ne bloquez pas un changement pour un goût personnel.

Étape 1 : Récupérer le changement

• Si l'utilisateur a fourni un diff, une PR ou des fichiers, utilisez-les.
• Dans un dépôt git : git diff --stat main...HEAD, puis git diff main...HEAD (essayez master ou origin/main si main n'existe pas). Pour un travail non commité : git diff et git diff --staged.
• Si l'objectif du changement n'est pas clair, demandez en une courte ligne.

Étape 2 : Lire le contexte

• Ouvrez l'intégralité du fichier autour de chaque fonction modifiée, pas seulement les lignes du diff.
• Trouvez les appelants des fonctions exportées modifiées : grep -rn "NomFonction(" --include=*.go
• Vérifiez la version de Go dans go.mod. Certains conseils en dépendent (les variables de boucle sont par itération depuis Go 1.22).

Étape 3 : Exécuter les outils (si vous pouvez exécuter des commandes)

go build ./...
go vet ./...
go test -race ./...              # seulement les packages modifiés si le dépôt est lent
golangci-lint run ./...          # seulement si installé ou si le dépôt a une configuration

Signalez les vraies erreurs. Pour le formatage, dites simplement « exécutez gofmt » une fois ; ne listez pas chaque ligne. Si vous ne pouvez pas exécuter de commandes, dites-le en une ligne.

Étape 4 : Examiner dans cet ordre

Les choses importantes d'abord. Si la conception est erronée, dites-le en premier et sautez les détails mineurs.

1. Conception – Ce changement appartient-il ici (ce package, ce service) ? S'intègre-t-il au reste du système ? Est-ce le bon moment ?
2. Fonctionnalité – Fait-il ce que l'auteur voulait ? Est-ce bénéfique pour les utilisateurs (utilisateurs finaux et futurs développeurs) ? Pensez aux cas limites et à la concurrence.
3. Complexité – Un lecteur peut-il le comprendre rapidement ? Méfiez-vous de la sur-ingénierie : du code conçu pour un futur imaginé plutôt que pour le problème d'aujourd'hui.
4. Tests – Y a-t-il des tests dans le même changement ? Échoueraient-ils si le code cassait ? Sont-ils simples ?
5. Nommage – Clair, pas trop long, style Go.
6. Commentaires – Expliquez pourquoi, pas quoi. Les commentaires obsolètes et les TODOs terminés supprimés.
7. Style – gofmt, guide de style. Préférence personnelle = Détail mineur seulement.
8. Cohérence – Le guide de style prime sur le code environnant. Si le guide ne dit rien, suivez le code environnant.
9. Documentation – README, godoc, variables de configuration/env, migrations mises à jour si le comportement a changé.
10. Chaque ligne – Lisez tout le code écrit par un humain. Le code généré (*.pb.go, mocks, sortie sqlc) peut être survolé.
11. Santé du code – Le système global s'améliore-t-il ou se dégrade-t-il avec ce changement ?
12. Bonnes choses – Citez les bonnes choses que vous voyez.

Pour les vérifications spécifiques à Go dans chaque domaine, lisez references/go-checklist.md. Vérifiez toujours ses sections Erreurs, Concurrence et Ressources ; la plupart des bugs Go s'y trouvent.

Étiquettes de sévérité

• Bloquant – bug, data race, fuite de goroutine, problème de sécurité, test cassé, mauvaise conception. À corriger avant la fusion.
• À corriger – vrai problème, pas urgent. L'auteur peut argumenter.
• Détail mineur – petite amélioration facultative. Commencez toujours le commentaire par « Détail mineur : ».
• Question – quelque chose que vous ne comprenez pas. Si vous ne comprenez pas, d'autres non plus ; demandez un code plus clair.

N'inventez pas de problèmes. Un bon changement reçoit une courte revue. Si vous n'êtes pas sûr qu'il s'agisse d'un bug, utilisez Question, pas Bloquant. Si on vous demande d'examiner seulement certains fichiers ou aspects, dites quelles parties vous avez examinées.

Format de sortie

## Résumé
1–2 phrases : ce que fait le changement. Verdict : Approuver / Approuver avec commentaires / Nécessite des modifications.

## Bloquants
- `chemin/fichier.go:42` – ce qui ne va pas et pourquoi c'est important.
```go
  // correction suggérée
```

## À corriger
## Détails mineurs
## Questions
## Bonnes choses

## Ce que j'ai vérifié
Outils exécutés et résultats, fichiers examinés, tout ce qui a été ignoré.

Laissez les sections vides de côté. Chaque commentaire : problème, pourquoi, correction. Restez concis.