Persona: Sie sind ein Go-Skills-Orchestrator. Identifizieren Sie für jede Go-Aufgabe alle relevanten Skills und laden Sie sie gemeinsam – eine Aufgabe gehört selten zu einem einzelnen Skill.
Modi:
- Orchestrieren – für jede Go-Programmier-, Review-, Debug- oder Setup-Aufgabe den primären Skill zusammen mit allen passenden sekundären Skills gleichzeitig laden.
- Disambiguieren – wenn zwei Skills überlappen, die Grenztabelle anzeigen. Siehe disambiguation.md.
- Konfigurieren – die Always-Load-Direktive für
golang-how-toselbst sowie optional einen## Required Go skills-Block in die Agentenkonfigurationsdatei (CLAUDE.md, AGENTS.md oder gleichwertig) schreiben. Befolgen Sie dazu project-config.md.
Fragen: Im Konfigurieren-Modus den Benutzer über das Fragewerkzeug der Umgebung fragen – niemals als Fließtext. Eine Frage nach der anderen, auf die Antwort warten. Wenn die Umgebung kein Fragewerkzeug hat, als Fließtext mit denselben Optionen fragen.
Abhängigkeiten: gopls – go install golang.org/x/tools/gopls@latest; das eingebaute LSP-Werkzeug von Claude Code benötigt außerdem ENABLE_LSP_TOOL=1 und einen verbundenen Go-Sprachserver (siehe Code-Navigation mit gopls).
Skill-Laden
Für jede Aufgabe den primären Skill und alle passenden sekundären Skills gleichzeitig laden. Nicht warten – gleich zu Beginn gemeinsam laden.
| Absicht | Primär | Ebenfalls laden |
|---|---|---|
| Eine API entwerfen, ein Muster wählen | golang-design-patterns | golang-structs-interfaces, golang-naming |
| Einen Typ, eine Funktion oder ein Paket benennen | golang-naming | golang-code-style |
| Fehler idiomatisch behandeln | golang-error-handling | golang-safety (nil-lastiger Code) |
| Goroutinen, Channels, Sync schreiben | golang-concurrency | golang-context (falls Abbruch) |
| Fristen setzen / Operationen abbrechen | golang-context | golang-concurrency (falls Goroutinen) |
| Structs entwerfen, einbetten, Interfaces nutzen | golang-structs-interfaces | golang-design-patterns |
| Datenbankabfragen und Transaktionen | golang-database | golang-error-handling, golang-security |
| Einen gRPC-Dienst bauen | golang-grpc | golang-testing, golang-error-handling |
| Eine GraphQL-API bauen | golang-graphql | golang-testing, golang-error-handling |
| Einen CLI-Befehlsbaum bauen | golang-spf13-cobra | golang-cli, golang-spf13-viper (falls Konfiguration) |
| Konfiguration aus Flags/Datei/Umgebungsvariablen schichten | golang-spf13-viper | golang-spf13-cobra |
| Tests schreiben | golang-testing | golang-stretchr-testify (falls testify verwendet) |
| Optimierungsmuster anwenden | golang-performance | golang-benchmark (zuerst messen) |
| Mit pprof/benchstat messen | golang-benchmark | golang-performance (beheben), golang-troubleshooting (Ursachenforschung) |
| Einen Panic oder unerwartetes Verhalten debuggen | golang-troubleshooting | golang-safety, golang-benchmark (falls leistungsbezogen) |
| In der Produktion überwachen | golang-observability | golang-performance (falls SLO-Verletzung) |
| Sicherheitslücken auditieren | golang-security | golang-safety, golang-lint |
| Formatierung und Stil prüfen | golang-code-style | golang-naming, golang-lint |
| Vorhandenen Code refaktorisieren oder umstrukturieren | golang-refactoring | golang-naming, golang-code-style, golang-project-layout |
| golangci-lint konfigurieren | golang-lint | golang-code-style |
| godoc / README / CHANGELOG schreiben | golang-documentation | golang-naming |
| Eine neue Projektstruktur einrichten | golang-project-layout | golang-design-patterns, golang-dependency-injection, golang-lint |
| CI/CD-Pipeline einrichten | golang-continuous-integration | golang-lint, golang-security |
| Eine Bibliothek auswählen | golang-popular-libraries | relevanter bibliotheksspezifischer Skill |
| Dokumentation, Versionen, Importierer oder CVEs eines Pakets nachschlagen | golang-pkg-go-dev | golang-dependency-management |
| Lokalen Code navigieren, diagnostizieren oder refaktorisieren (Definitionen, Referenzen, Umbenennung) | golang-gopls | — |
| Neue Go-Sprachfunktionen übernehmen | golang-modernize | golang-lint |
| samber/lo verwenden (Slice/Map-Helfer) | golang-samber-lo | golang-data-structures, golang-performance |
| samber/oops verwenden (strukturierte Fehler) | golang-samber-oops | golang-error-handling |
| log/slog verwenden | golang-samber-slog | golang-observability, golang-error-handling |
| Dependency Injection verwenden | golang-dependency-injection | golang-google-wire oder golang-uber-dig oder golang-uber-fx oder golang-samber-do |
Alle obigen Skill-IDs sind Kurzformen von samber/cc-skills-golang@<name>.
Code-Navigation mit gopls
gopls bietet semantische Code-Intelligenz für Go – Gehe-zu-Definition, Referenzen finden, Diagnosen, Paket-API, Symbolsuche, Refactoring. → Siehe samber/cc-skills-golang@golang-gopls-Skill für die drei Zugriffswege (eigener MCP-Server, natives LSP-Werkzeug und dessen CLI), die vollständige Fähigkeitsmatrix und effiziente Lese-/Bearbeitungs-Workflows.
gopls denkt nur über Code nach, der im lokalen Build vorhanden und auflösbar ist: Ihr Arbeitsbereich plus jede Abhängigkeit genau so, wie sie in go.sum festgelegt ist (einschließlich replace-Direktiven). Für Fakten, die nicht an Ihren lokalen Build gebunden sind – Versionshistorie, Lizenzen, Ökosystem-weite Importierer, ein noch nicht hinzugefügtes Paket – verwenden Sie golang-pkg-go-dev (godig). Siehe den Abschnitt godig vs gopls vs Context7 vs govulncheck unten für die vollständige Abgrenzung.
godig vs gopls vs Context7 vs govulncheck
Vier Werkzeuge können die Frage „Ist diese Abhängigkeit sicher zu verwenden?“ beantworten, und sie überschneiden sich weniger, als es scheint:
- Context7 ist ein allgemeiner, sprachübergreifender Dokumentationsabrufer – nützlich, wenn keine spezifischere Quelle existiert. Für ein Go-Paket oder -Modul ist
godigfast immer die bessere Wahl: Es ruft strukturierte, Go-spezifische Daten direkt von pkg.go.dev ab – genaue Versionen, exportierte Symbole mit Signaturen, ausführbare Beispiele,imported-byund bekannte Schwachstellen – und nicht die generischen, gescrapten/kuratieren Dokumente von Context7, die diese Struktur nicht bieten und bei weniger bekannten Go-Modulen veraltet sein oder fehlen können. Greifen Sie nur dann zu Context7, wenn die Dokumentation einer Abhängigkeit wirklich nicht existiert oder nicht auf pkg.go.dev indiziert ist. godigbeantwortet Fragen zum veröffentlichten Ökosystem: jedes Go-Paket oder -Modul, unabhängig davon, ob es bereits in Ihrergo.modsteht – es ruft die entfernte pkg.go.dev-API auf und berührt niemals Ihr lokales Checkout. Der Befehlvulnsmeldet CVEs, die für ein Paket/eine Version isoliert bekannt sind, unabhängig davon, ob Ihr Build tatsächlich den verwundbaren Codepfad erreicht.gopls(→samber/cc-skills-golang@golang-gopls, über seinen MCP-Server, das nativeLSP-Werkzeug oder seine CLI) beantwortet Fragen zu Ihrem spezifischen Build: Ihrem Code plus jeder