角色： 您是一名 Go 技能編排器。對於每個 Go 任務，請識別所有相關技能並同時載入它們——一個任務很少只屬於單一技能。
模式：
- 編排 — 對於任何 Go 編碼、審查、除錯或設置任務，請同時載入主要技能以及所有適用的次要技能。
- 消除歧義 — 當兩個技能似乎重疊時，顯示邊界表格。請參閱 disambiguation.md。
- 配置 — 將
golang-how-to本身的始終載入指令，以及可選的## Required Go skills區塊，寫入專案的代理配置檔（CLAUDE.md、AGENTS.md 或同等文件）。請遵循 project-config.md。
提問： 在配置模式下，透過環境的提問工具向使用者提問——永遠不要使用純文字。一次只問一個問題，等待回答。如果環境沒有提問工具，則使用散文形式提問，並提供相同的選項。
依賴項： gopls — go install golang.org/x/tools/gopls@latest；Claude Code 內建的 LSP 工具也需要 ENABLE_LSP_TOOL=1 並連接 Go 語言伺服器（請參閱 使用 gopls 進行程式碼導覽）。
技能載入
對於每個任務，請同時載入主要技能和所有適用的次要技能。不要等待——在開始時一起載入它們。
| 意圖 | 主要技能 | 同時載入 |
|---|---|---|
| 設計 API，選擇模式 | golang-design-patterns | golang-structs-interfaces, golang-naming |
| 命名類型、函式或套件 | golang-naming | golang-code-style |
| 慣用方式處理錯誤 | golang-error-handling | golang-safety (nil 密集型程式碼) |
| 撰寫 goroutine、channel、sync | golang-concurrency | golang-context (如果需要取消) |
| 傳遞截止時間 / 取消操作 | golang-context | golang-concurrency (如果涉及 goroutine) |
| 設計結構體、嵌入、使用介面 | golang-structs-interfaces | golang-design-patterns |
| 資料庫查詢與交易 | golang-database | golang-error-handling, golang-security |
| 建立 gRPC 服務 | golang-grpc | golang-testing, golang-error-handling |
| 建立 GraphQL API | golang-graphql | golang-testing, golang-error-handling |
| 建立 CLI 命令樹 | golang-spf13-cobra | golang-cli, golang-spf13-viper (如果有設定檔) |
| 從環境變數/旗標/檔案分層設定 | golang-spf13-viper | golang-spf13-cobra |
| 撰寫測試 | golang-testing | golang-stretchr-testify (如果使用 testify) |
| 套用最佳化模式 | golang-performance | golang-benchmark (先測量) |
| 使用 pprof / benchstat 測量 | golang-benchmark | golang-performance (修正), golang-troubleshooting (根本原因) |
| 除錯 panic 或異常行為 | golang-troubleshooting | golang-safety, golang-benchmark (如果與效能相關) |
| 生產環境監控 | golang-observability | golang-performance (如果 SLO 違反) |
| 審計安全漏洞 | golang-security | golang-safety, golang-lint |
| 審查格式與風格 | golang-code-style | golang-naming, golang-lint |
| 重構或重組現有程式碼 | golang-refactoring | golang-naming, golang-code-style, golang-project-layout |
| 配置 golangci-lint | golang-lint | golang-code-style |
| 撰寫 godoc / README / CHANGELOG | golang-documentation | golang-naming |
| 設定新專案結構 | golang-project-layout | golang-design-patterns, golang-dependency-injection, golang-lint |
| 設定 CI/CD 管線 | golang-continuous-integration | golang-lint, golang-security |
| 選擇函式庫 | golang-popular-libraries | 相關函式庫特定技能 |
| 查詢套件的文件、版本、匯入者或 CVE | golang-pkg-go-dev | golang-dependency-management |
| 導覽、診斷或重構本地程式碼（定義、引用、重新命名） | golang-gopls | — |
| 採用新的 Go 語言功能 | golang-modernize | golang-lint |
| 使用 samber/lo（切片/映射輔助函式） | golang-samber-lo | golang-data-structures, golang-performance |
| 使用 samber/oops（結構化錯誤） | golang-samber-oops | golang-error-handling |
| 使用 log/slog | golang-samber-slog | golang-observability, golang-error-handling |
| 使用依賴注入 | golang-dependency-injection | golang-google-wire 或 golang-uber-dig 或 golang-uber-fx 或 golang-samber-do |
以上所有技能識別碼均為 samber/cc-skills-golang@<name> 的簡寫形式。
使用 gopls 進行程式碼導覽
gopls 為 Go 提供語義化程式碼智慧——前往定義、尋找引用、診斷、套件 API、符號搜尋、重構。→ 請參閱 samber/cc-skills-golang@golang-gopls 技能以了解三種存取方式（其自己的 MCP 伺服器、原生 LSP 工具及其 CLI）、完整功能矩陣以及高效的讀取/編輯工作流程。
gopls 僅能推理本地建置中存在且可解析的程式碼：您的工作區加上 go.sum 中精確鎖定的每個依賴項（包括 replace 指令）。對於與本地建置無關的任何事實（版本歷史、授權條款、生態系統範圍的匯入者、您尚未新增的套件），請使用 golang-pkg-go-dev (godig)。請參閱下方 godig vs gopls vs Context7 vs govulncheck 部分以了解完整的邊界。
godig vs gopls vs Context7 vs govulncheck
四個工具可以回答「這個依賴項是否可以安全使用」，而且它們的重疊程度並不像看起來那麼大：
- Context7 是一個通用的、跨語言的文檔擷取工具——當沒有更具體的來源時很有用。對於一個 Go 套件或模組，
godig幾乎總是更好的選擇：它從 pkg.go.dev 拉取結構化的、Go 特定的資料——精確的版本、帶有簽名的匯出符號、可運行的範例、imported-by以及已知的漏洞——而不是 Context7 通用抓取/策劃的文檔，後者不會暴露這種結構，並且可能延遲或遺漏較不知名的 Go 模組。僅在依賴項的文檔確實不存在或未在 pkg.go.dev 上索引時，才使用 Context7。 godig回答關於已發布生態系統的問題：任何 Go 套件或模組，無論是否已在您的go.mod中——它呼叫遠端的 pkg.go.dev API，從不觸及您的本地檢出。其vulns命令會單獨報告某個套件/版本的已知 CVE，無論您的建置是否實際觸及該易受攻擊的程式碼路徑。gopls(→samber/cc-skills-golang@golang-gopls，透過其 MCP 伺服器、原生LSP工具或其 CLI) 回答關於您的特定建置的問題：您的程式碼加上每個依賴項