角色設定： 你是一位 Go 工程師，當面對已解析建構的問題時，會優先使用語意級程式碼智能而非 grep——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 指令）。對於不在此建構中的套件（版本、文件、授權、尚未加入的 CVEs），請改用 samber/cc-skills-golang@golang-pkg-go-dev 技能 (godig)。
三種使用 gopls 的方式
不可互換——根據你已知的資訊和需要的輸出選擇：
- 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.*系列（填寫結構體/switch、反轉 if、分割/合併行、移除未使用的參數、新增結構體標籤、實現介面）。完整目錄與注意事項：references/features.md。
高效工作流程
以下讀取/編輯工作流程規定了避免冗餘查詢和不完整編輯的順序——請將每個步驟視為必需，而非可選，即使這意味著多花一次往返。
- 工作階段開始——呼叫
go_workspace一次以檢測是否為 Go 工作區；如果是，立即執行一次基準go_vulncheck，以揭露工作區已存在的漏洞。此步驟是無條件的，並且與編輯工作流程後段在依賴變更後進行的檢查分開。
讀取工作流程（在接觸任何東西之前先理解）：
go_workspace——佈局（module/workspace/GOPATH）；如果尚未執行，此步驟與上述工作階段開始檢查相同。go_search——模糊定位型別/函式/變數的名稱。go_file_context——在首次讀取任何 Go 檔案後，立即查看它從其套件中的其他部分引入了什麼；如果該檔案的依賴發生變更，則重新執行。go_package_api——第三方依賴或兄弟套件的公開表面，無需讀取每個檔案。
編輯工作流程（迭代直到診斷乾淨）：
- 先讀取（上述工作流程）。
- 在修改任何定義之前，先執行
go_symbol_references——評估影響範圍，然後讀取每個需要進行相應編輯的引用檔案。 - 完成所有計劃的編輯，包括引用位置的編輯，然後再繼續。
- 對每個變更的檔案執行
go_diagnostics——每次修改後都必須執行，而非可選的清理步驟。 - 修復報告的錯誤：在應用之前，檢查任何建議的快速修復差異，然後重新執行診斷以確認修復生效。忽略與任務無關的 hint/info 診斷。診斷訊息可能以改寫方式呈現周圍的原始碼，而非逐字引用。
- 僅當
go.mod的依賴發生變更時，才對整個工作區執行go_vulncheck——在診斷乾淨之後，而非之前。 - 執行
go test <更改的套件路徑>——除非明確要求，否則不要執行./...。