samber/golang-gopls

Persona: Du bist ein Go-Entwickler, der semantische Code-Intelligenz anstelle von grep verwendet, wenn es um den aufgelösten Build geht – grep findet Text, gopls findet Bedeutung (Typen, Aufrufgraphen, Shadowing, Implementierungsbeziehungen).

Abhängigkeiten: gopls – go install golang.org/x/tools/gopls@latest (v0.20+). Das native LSP-Tool benötigt zusätzlich ENABLE_LSP_TOOL=1 und das Marketplace-Plugin gopls-lsp@claude-plugins-official (siehe references/mcp.md).

gopls ist der offizielle Go-Sprachserver. Er beantwortet nur Fragen zu deinem spezifischen, lokal aufgelösten Build – deinem Workspace plus allen Abhängigkeiten exakt wie in go.sum festgelegt, einschließlich replace-Direktiven. Für ein Paket, das nicht Teil dieses Builds ist (Versionen, Dokumentation, Lizenzen, CVEs von etwas, das du noch nicht hinzugefügt hast), → Siehe Skill samber/cc-skills-golang@golang-pkg-go-dev (godig) stattdessen.

Drei Wege, gopls zu erreichen

Nicht austauschbar – wähle basierend auf dem, was du bereits weißt und was du zurückbekommst:

• gopls' eigener MCP-Server (bevorzugt für die meisten Aufgaben) – maßgeschneidert für Agenten: Tools akzeptieren Namen, Dateipfade und unscharfe Abfragen anstelle von rohen Cursorpositionen. Einmal pro Maschine registrieren: claude mcp add gopls -- gopls mcp. Läuft headless über stdio, kein Editor angeschlossen, sieht nur auf der Festplatte gespeicherte Dateien – der richtige Standard für einen agentenorientierten Workflow. Siehe references/mcp.md für jedes Tool.
• Das native LSP-Tool – Claude Codes integrierte Editor-artige Integration. Standardmäßig deaktiviert: Setze ENABLE_LSP_TOOL=1, installiere gopls, und installiere das offizielle Marketplace-Plugin gopls-lsp@claude-plugins-official, um es als Go-Sprachserver zu verdrahten. Operationen (goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, Aufrufhierarchie) sind nach line/character indiziert, daher sind sie am nützlichsten, sobald du bereits eine Position hast – typischerweise direkt nach einem grep oder einem Lesevorgang. Einzigartiger Wert: Compilerdiagnosen werden automatisch nach jeder Bearbeitung in den Kontext eingefügt, kein expliziter Aufruf erforderlich.
• Das gopls-CLI – dieselbe Engine, aufgerufen als gopls <command> <file:line:col>. Das Go-Team dokumentiert es als experimentell und nur zum Debuggen – "nicht effizient, vollständig, flexibel oder offiziell unterstützt." Verwende es, wenn weder MCP noch das native Tool eingerichtet sind, oder für einen einmaligen skriptgesteuerten Check. Positionen sind file:line:col (1-basiert, UTF-8-Bytes) oder file:#offset (0-basiert). Siehe references/cli.md.

Bevorzugungsreihenfolge: MCP → natives LSP → CLI. MCP-Tools passen zu der Denkweise eines Agenten (nach Name/Pfad, nicht Cursorposition); das native Tool fügt kostenlose automatische Diagnose hinzu; das CLI ist der dokumentierte letzte Ausweg. Verbinde so viele wie verfügbar und lass die Aufgabe das Tool auswählen – eine Abfrage, für die du bereits eine line:col hast, ist über LSP günstig, eine "wo ist X"-Abfrage ist über go_search günstig, ein schneller unbeaufsichtigter Check ist über das CLI günstig.

Fähigkeit → CLI → MCP → natives LSP

Vollständige Zuordnung jeder Fähigkeit zu ihrem CLI-Befehl, MCP-Tool und nativen LSP-Op: references/matrix.md.

Anwendungsfälle

• Navigation – springe zu einer Definition, einer Implementierung oder verfolge einen Aufrufgraphen, bevor du Code anfasst, den du nicht geschrieben hast. Details: references/features.md.
• Code-Erkundung – lerne die Form eines Workspaces (go_workspace), suche unscharf nach einem Symbol, das du nicht genau platzieren kannst (go_search), oder lies die öffentliche Oberfläche einer Abhängigkeit (go_package_api), bevor du sie verwendest.
• Dokumentation – fahre mit der Maus für Typ-/Dok-/Größeninfo, Signaturhilfe beim Aufruf einer Funktion oder durchsuche gerenderte Paketdokumentation (source.doc, einschließlich interner Pakete, die pkg.go.dev nie sieht).
• Diagnose & Sicherheit – Compiler- und Analyzerfehler nach jeder Bearbeitung (go_diagnostics / automatisch mit LSP), plus eine einfache go_vulncheck-Erreichbarkeitsprüfung: einmal als Basislinie direkt nach der Erkennung des Workspaces und erneut nach jeder go.mod-Änderung.
• Formatierung – kanonische gofmt-äquivalente Formatierung und Importorganisation, sowohl skriptgesteuert als auch code-aktionsgetrieben.
• Refactoring – sicheres Umbenennen (blockiert eine Änderung, die die Interface-Erfüllung brechen würde), Extrahieren/Einfügen und die gesamte refactor.rewrite.*-Familie (Struct/Switch ausfüllen, If umkehren, Zeilen teilen/verbinden, unbenutzten Parameter entfernen, Struct-Tags hinzufügen, Interface implementieren). Vollständiger Katalog mit Fallstricken: references/features.md.

Effiziente Workflows

Diese Lese-/Bearbeitungs-Workflows kodieren die Reihenfolge, die redundante Abfragen und halb angewandte Bearbeitungen vermeidet – behandle jeden Schritt als erforderlich, nicht optional, selbst um eine Runde zu sparen.

• Sitzungsstart – rufe go_workspace einmal auf, um zu erkennen, ob dies überhaupt ein Go-Workspace ist; wenn ja, folge sofort mit einer Basislinien-go_vulncheck, um Schwachstellen aufzudecken, die der Workspace bereits trägt. Dies ist bedingungslos, getrennt von der späteren Prüfung des Bearbeitungs-Workflows nach einer Abhängigkeitsänderung.

Lese-Workflow (verstehen, bevor du etwas anfasst):

1. go_workspace – Layout (Module/Workspace/GOPATH); derselbe Aufruf wie die Sitzungsstart-Prüfung oben, falls noch nicht ausgeführt.
2. go_search – suche unscharf nach einem Typ/einer Funktion/Variable anhand des Namens.
3. go_file_context – direkt nach dem ersten Lesen einer Go-Datei sehen, was sie aus dem Rest ihres Pakets einzieht; erneut ausführen, wenn sich die Abhängigkeiten dieser Datei ändern.
4. go_package_api – öffentliche Oberfläche einer Drittanbieter-Abhängigkeit oder eines Geschwisterpakets, ohne jede Datei zu lesen.

Bearbeitungs-Workflow (iterieren, bis die Diagnose sauber ist):

1. Zuerst lesen (Workflow oben).
2. go_symbol_references vor dem Ändern einer Definition – beurteile die Auswirkungsbreite, lies dann jede referenzierende Datei, die eine passende Bearbeitung benötigt.
3. Führe alle geplanten Bearbeitungen durch, einschließlich der Änderungen an den Referenzstellen, bevor du fortfährst.
4. go_diagnostics für jede geänderte Datei – obligatorisch nach jeder Änderung, kein optionaler Bereinigungsschritt.
5. Behebe gemeldete Fehler: Überprüfe jede vorgeschlagene Quick-Fix-Diff, bevor du sie anwendest, führe dann die Diagnose erneut aus, um zu bestätigen, dass der Fix angekommen ist. Ignoriere Hint/Info-Diagnosen, die nichts mit der Aufgabe zu tun haben. Eine Diagnosemeldung kann den umgebenden Quellcode paraphrasieren, anstatt ihn wörtlich zu zitieren.
6. Nur wenn sich die go.mod-Abhängigkeiten geändert haben, führe go_vulncheck für den gesamten Workspace aus – nachdem die Diagnose sauber ist, nicht davor.
7. Führe go test <changed-package-paths> aus – nicht ./..., sofern nicht ausdrücklich danach gefragt.