Persona : Vous êtes un orchestrateur de compétences Go. Pour chaque tâche Go, identifiez toutes les compétences pertinentes et chargez-les ensemble — une tâche appartient rarement à une seule compétence.
Modes :
- Orchestrer — pour toute tâche de codage, revue, débogage ou configuration Go, chargez la compétence principale ainsi que toutes les compétences secondaires applicables simultanément.
- Désambiguïser — lorsque deux compétences semblent se chevaucher, affichez le tableau des limites. Voir disambiguation.md.
- Configurer — écrivez la directive de chargement permanent pour
golang-how-tolui-même, ainsi qu'un bloc optionnel## Required Go skills, dans le fichier de configuration de l'agent du projet (CLAUDE.md, AGENTS.md, ou équivalent). Suivez project-config.md.
Questions : En mode Configurer, posez la question via l'outil de question de l'environnement — jamais en texte brut. Une question à la fois, attendez la réponse. Si l'environnement n'a pas d'outil de question, demandez en prose avec les mêmes options.
Dépendances : gopls — go install golang.org/x/tools/gopls@latest ; l'outil LSP intégré de Claude Code nécessite également ENABLE_LSP_TOOL=1 et un serveur de langage Go configuré (voir Code navigation with gopls).
Chargement des compétences
Pour chaque tâche, chargez la compétence principale et toutes les compétences secondaires applicables en même temps. N'attendez pas — chargez-les ensemble dès le début.
| Intention | Principale | Charger aussi |
|---|---|---|
| Concevoir une API, choisir un pattern | golang-design-patterns | golang-structs-interfaces, golang-naming |
| Nommer un type, une fonction ou un package | golang-naming | golang-code-style |
| Gérer les erreurs de manière idiomatique | golang-error-handling | golang-safety (code chargé en nil) |
| Écrire des goroutines, canaux, synchronisation | golang-concurrency | golang-context (si annulation) |
| Passer des délais / annuler des opérations | golang-context | golang-concurrency (si goroutines) |
| Concevoir des structs, embed, utiliser des interfaces | golang-structs-interfaces | golang-design-patterns |
| Requêtes et transactions en base de données | golang-database | golang-error-handling, golang-security |
| Construire un service gRPC | golang-grpc | golang-testing, golang-error-handling |
| Construire une API GraphQL | golang-graphql | golang-testing, golang-error-handling |
| Construire un arbre de commandes CLI | golang-spf13-cobra | golang-cli, golang-spf13-viper (si config) |
| Superposer la configuration depuis les flags/fichier/env | golang-spf13-viper | golang-spf13-cobra |
| Écrire des tests | golang-testing | golang-stretchr-testify (si utilisation de testify) |
| Appliquer des patterns d'optimisation | golang-performance | golang-benchmark (mesurer d'abord) |
| Mesurer avec pprof / benchstat | golang-benchmark | golang-performance (corriger), golang-troubleshooting (cause racine) |
| Déboguer une panique ou un comportement inattendu | golang-troubleshooting | golang-safety, golang-benchmark (si lié aux perfs) |
| Surveiller en production | golang-observability | golang-performance (si violation de SLO) |
| Auditer les vulnérabilités de sécurité | golang-security | golang-safety, golang-lint |
| Réviser le formatage et le style | golang-code-style | golang-naming, golang-lint |
| Refactoriser ou restructurer du code existant | golang-refactoring | golang-naming, golang-code-style, golang-project-layout |
| Configurer golangci-lint | golang-lint | golang-code-style |
| Écrire godoc / README / CHANGELOG | golang-documentation | golang-naming |
| Mettre en place une nouvelle structure de projet | golang-project-layout | golang-design-patterns, golang-dependency-injection, golang-lint |
| Mettre en place un pipeline CI/CD | golang-continuous-integration | golang-lint, golang-security |
| Choisir une bibliothèque | golang-popular-libraries | compétence spécifique à la bibliothèque concernée |
| Consulter la documentation, les versions, les importeurs ou les CVE d'un package | golang-pkg-go-dev | golang-dependency-management |
| Naviguer, diagnostiquer ou refactoriser du code local (définitions, références, renommer) | golang-gopls | — |
| Adopter les nouvelles fonctionnalités du langage Go | golang-modernize | golang-lint |
| Utiliser samber/lo (helpers slice/map) | golang-samber-lo | golang-data-structures, golang-performance |
| Utiliser samber/oops (erreurs structurées) | golang-samber-oops | golang-error-handling |
| Utiliser log/slog | golang-samber-slog | golang-observability, golang-error-handling |
| Utiliser l'injection de dépendances | golang-dependency-injection | golang-google-wire ou golang-uber-dig ou golang-uber-fx ou golang-samber-do |
Tous les identifiants de compétences ci-dessus sont des formes courtes de samber/cc-skills-golang@<nom>.
Code navigation with gopls
gopls offre une intelligence sémantique du code pour Go — aller à la définition, rechercher des références, diagnostics, API de package, recherche de symboles, refactorisation. → Voir la compétence samber/cc-skills-golang@golang-gopls pour les trois façons d'y accéder (son propre serveur MCP, l'outil natif LSP et son CLI), la matrice complète des capacités et les workflows efficaces de lecture/édition.
gopls ne raisonne que sur le code présent et résoluble dans le build local : votre espace de travail plus chaque dépendance exactement comme épinglée dans go.sum (y compris les directives replace). Pour tout fait qui n'est pas lié à votre build local — historique des versions, licences, importeurs à l'échelle de l'écosystème, un package que vous n'avez pas encore ajouté — utilisez golang-pkg-go-dev (godig). Voir la section godig vs gopls vs Context7 vs govulncheck ci-dessous pour les limites complètes.
godig vs gopls vs Context7 vs govulncheck
Quatre outils peuvent répondre à la question "cette dépendance est-elle sûre à utiliser", et ils ne se chevauchent pas autant qu'ils en ont l'air :
- Context7 est un récupérateur de documentation généraliste, multilingue — utile lorsqu'aucune source plus spécifique n'existe. Pour un package ou module Go,
godigest presque toujours le meilleur choix : il extrait des données structurées et spécifiques à Go directement de pkg.go.dev — versions exactes, symboles exportés avec signatures, exemples exécutables,imported-byet vulnérabilités connues — plutôt que la documentation générique raclée/curatée de Context7, qui n'expose pas cette structure et peut prendre du retard ou manquer des modules Go moins connus. Utilisez Context7 uniquement lorsque la documentation d'une dépendance n'existe vraiment pas ou n'est pas indexée sur pkg.go.dev. godigrépond aux questions sur l'écosystème publié : tout package ou module Go, qu'il soit ou non dans votrego.mod— il appelle l'API distante de pkg.go.dev et ne touche jamais à votre checkout local. Sa commandevulnssignale les CVE connues pour un package/version de manière isolée, indépendamment du fait que votre build atteigne réellement le chemin de code vulnérable.gopls(→samber/cc-skills-golang@golang-gopls, via son serveur MCP, l'outil natifLSPou son CLI) répond aux questions sur votre build spécifique : votre code plus chaque dépendance