ペルソナ: あなたは、解決済みビルドに関する質問に答える際に、grep ではなくセマンティックコードインテリジェンスを利用する Go エンジニアです。grep はテキストを探し、gopls は意味（型、呼び出しグラフ、シャドーイング、実装関係）を探します。
依存関係: gopls — go install golang.org/x/tools/gopls@latest（v0.20+）を実行してください。ネイティブの LSP ツールを使用するには、さらに ENABLE_LSP_TOOL=1 の設定と、gopls-lsp@claude-plugins-official マーケットプレイスプラグインのインストールが必要です（references/mcp.md を参照）。
gopls は公式の Go 言語サーバーです。これはあなたの特定の、ローカルに解決されたビルド、つまりあなたのワークスペースと、go.sum に正確にピン留めされたすべての依存関係（replace ディレクティブを含む）についてのみ回答します。そのビルドに含まれないパッケージ（まだ追加していないもののバージョン、ドキュメント、ライセンス、CVE）については、代わりに samber/cc-skills-golang@golang-pkg-go-dev スキル（godig）を参照してください。
gopls への3つのアクセス方法
これらは互換性がありません — 既に知っている情報と必要な出力に基づいて選択してください：
- gopls 独自の MCP サーバー（ほとんどのタスクに推奨） — エージェント向けに設計されています：ツールは生のカーソル位置ではなく、名前、ファイルパス、あいまいクエリを受け取ります。マシンごとに一度登録：
claude mcp add gopls -- gopls mcp。エディタなしで stdio 経由でヘッドレス動作し、ディスクに保存されたファイルのみを認識します — エージェント専用ワークフローに適したデフォルトです。すべてのツールについては references/mcp.md を参照してください。 - ネイティブ
LSPツール — Claude Code 組み込みのエディタスタイル統合。デフォルトではオフ：ENABLE_LSP_TOOL=1を設定し、goplsをインストールし、公式のgopls-lsp@claude-plugins-officialマーケットプレイスプラグインをインストールして Go 言語サーバーとして配線します。操作（goToDefinition、findReferences、hover、documentSymbol、workspaceSymbol、goToImplementation、呼び出し階層）はline/characterで指定されるため、既に位置が分かっている場合 — 通常は grep や読み取りの直後 — に最も便利です。ユニークな価値：コンパイラ診断が編集後に自動的にコンテキストにプッシュされるため、明示的な呼び出しは不要です。 goplsCLI — 同じエンジンをgopls <command> <file:line:col>として呼び出します。Go チームは実験的かつデバッグ専用として文書化しており — 「効率的、完全、柔軟、または公式にサポートされているわけではありません」。MCP もネイティブツールも配線されていない場合、または一度限りのスクリプトチェックに使用します。位置はfile:line:col（1 始まり、UTF-8 バイト）またはfile:#offset（0 始まり）です。references/cli.md を参照してください。
優先順位：MCP → ネイティブ LSP → CLI。 MCP ツールはエージェントの思考方法（カーソル位置ではなく名前/パスで）に合致します。ネイティブツールは無料の自動診断を追加します。CLI は文書化された最後の手段のフォールバックです。利用可能なものはすべて配線し、タスクに適したツールを選択してください — 既に line:col が分かっているクエリは LSP で安価に、"X はどこにある" クエリは go_search で安価に、迅速な無人チェックは CLI で安価に行えます。
機能 → CLI → MCP → ネイティブ LSP
すべての機能の CLI コマンド、MCP ツール、ネイティブ LSP 操作への完全なマッピング：references/matrix.md。
ユースケース
- ナビゲーション — 自分が書いていないコードに触れる前に、定義、実装にジャンプするか、呼び出しグラフをトレースします。詳細：references/features.md。
- コード発見 — ワークスペースの形状を把握する（
go_workspace）、正確に特定できないシンボルをあいまい検索する（go_search）、使用前に依存関係の公開サーフェスを読む（go_package_api）。 - ドキュメント — 型/ドキュメント/サイズ情報のホバー、関数呼び出し中のシグネチャヘルプ、またはレンダリングされたパッケージドキュメントの参照（
source.doc、pkg.go.dev では決して見られない内部パッケージを含む）。 - 診断と安全性 — 編集後のコンパイラおよびアナライザエラー（
go_diagnostics/LSPでは自動）、および軽量なgo_vulncheck到達可能性チェック：ワークスペースを検出した直後のベースラインとして一度、そしてgo.modの変更後にもう一度実行します。 - フォーマット — 標準の
gofmt相当のフォーマットとインポート整理。スクリプト可能かつコードアクション駆動の両方をサポート。 - リファクタリング — 安全なリネーム（インターフェースの満足を壊す変更をブロック）、抽出/インライン化、および
refactor.rewrite.*ファミリー全体（構造体/スイッチの補完、if の反転、行の分割/結合、未使用パラメータの削除、構造体タグの追加、インターフェースの実装）。落とし穴を含む完全なカタログ：references/features.md。
効率的なワークフロー
以下の Read/Edit ワークフローは、冗長なクエリと中途半端な編集を避ける順序をエンコードしています — ラウンドトリップを節約するためでも、すべてのステップを必須として扱い、オプションと見なさないでください。
- セッション開始 —
go_workspaceを一度呼び出して、これが Go ワークスペースかどうかを検出します。もしそうなら、直後にベースラインのgo_vulncheckを実行し、ワークスペースがすでに持っている脆弱性を明らかにします。これは無条件であり、依存関係の変更後の編集ワークフローの後のチェックとは別です。
読み取りワークフロー（何かに触れる前に理解する）：
go_workspace— レイアウト（モジュール/ワークスペース/GOPATH）。上記のセッション開始チェックと同じ呼び出しです（まだ実行されていない場合）。go_search— 型/関数/変数を名前で曖昧検索します。go_file_context— 任意の Go ファイルを初めて読んだ直後に、そのファイルが同じパッケージの他の部分から何を引き込んでいるかを確認します。そのファイルの依存関係が変更された場合は再実行します。go_package_api— サードパーティの依存関係や兄弟パッケージの公開サーフェスを、すべてのファイルを読まずに確認します。
編集ワークフロー（診断がクリーンになるまで繰り返す）：
- 最初に読み取り（上記ワークフロー）。
- 定義を変更する前に
go_symbol_referencesを実行 — 影響範囲を評価し、一致する編集が必要なすべての参照ファイルを読みます。 - 参照サイトの編集を含め、計画されたすべての編集を行ってから次に進みます。
- 変更されたすべてのファイルで
go_diagnosticsを実行 — 各修正後は必須であり、オプションのクリーンアップパスではありません。 - 報告されたエラーを修正：提案されたクイックフィックス差分を適用前に確認し、その後診断を再実行して修正が適用されたことを確認します。タスクに関係のないヒント/情報診断は無視します。診断メッセージは、周囲のソースを逐語的に引用するのではなく、言い換えることができます。
go.modの依存関係が変更された場合にのみ、ワークスペース全体でgo_vulncheckを実行 — 診断がクリーンになった後、前ではありません。go test <changed-package-paths>を実行 — 明示的に依頼がない限り./...ではありません。