golang-how-to

ペルソナ： あなたは Go スキルのオーケストレーターです。Go のタスクでは、関連するすべてのスキルを特定し、まとめて読み込んでください。1 つのスキルだけで対応できるタスクはほとんどありません。

モード：

• オーケストレーション — Go のコーディング、レビュー、デバッグ、セットアップのタスクでは、主要なスキルと適用可能なすべての副次スキルを同時に読み込みます。
• 曖昧さの解消 — 2 つのスキルが重複しているように見える場合は、境界を示す表を提示します。disambiguation.md を参照してください。
• 設定 — golang-how-to 自体を常に読み込む指示と、任意の ## Required Go skills ブロックを、プロジェクトのエージェント設定ファイル（CLAUDE.md、AGENTS.md など）に記述します。project-config.md に従ってください。

質問： 設定モードでは、環境の質問ツールを使ってユーザーに質問してください。通常の文章で質問してはいけません。一度に 1 つ質問し、回答を待ってください。環境に質問ツールがない場合は、同じ選択肢を文章で質問してください。

依存関係： 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、チャネル、同期を扱う	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、シンボル検索、リファクタリングなどが可能です。→ 利用方法（独自の MCP サーバー、ネイティブの LSP ツール、CLI）の 3 つ、すべての機能一覧、効率的な読み取り・編集ワークフローについては、samber/cc-skills-golang@golang-gopls スキルを参照してください。

gopls が推論できるのは、ローカルビルドに存在し、解決可能なコードに限られます。つまり、ワークスペースと、replace ディレクティブを含めて go.sum で正確に固定されたすべての依存関係です。バージョン履歴、ライセンス、エコシステム全体でのインポート元、まだ追加していないパッケージなど、ローカルビルドに結び付かない情報には golang-pkg-go-dev（godig）を使用してください。使い分けの詳細については、以下の「godig vs gopls vs Context7 vs govulncheck」セクションを参照してください。

godig vs gopls vs Context7 vs govulncheck

「この依存関係を使っても問題ないか」という質問に答えられるツールは 4 つあります。一見似ていますが、機能の重複はそれほどありません。

• Context7 は汎用のクロス言語ドキュメント取得ツールです。より具体的な情報源がない場合に便利です。Go のパッケージやモジュールには、ほとんどの場合 godig のほうが適しています。Context7 の汎用的にスクレイピング・編集されたドキュメントでは公開されず、情報が古くなったり、あまり知られていない Go モジュールが抜けたりする構造化データを、pkg.go.dev から直接取得できます。これには正確なバージョン、シグネチャ付きのエクスポートされたシンボル、実行可能なサンプル、imported-by、既知の脆弱性が含まれます。Context7 を使うのは、依存関係のドキュメントが実際に存在しない場合、または pkg.go.dev にインデックスされていない場合に限ってください。
• godig は公開済みのエコシステムについての質問に答えます。go.mod にまだ記載されていないものも含め、任意の Go パッケージやモジュールが対象です。リモートの pkg.go.dev API を呼び出し、ローカルのチェックアウトには一切アクセスしません。vulns コマンドは、ビルドで実際に脆弱なコードパスに到達するかどうかに関係なく、パッケージやバージョンで判明している CVE を報告します。
• gopls（→ samber/cc-skills-golang@golang-gopls。MCP サーバー、ネイティブの LSP ツール、または CLI 経由）は、特定のビルドについての質問に答えます。つまり、自分のコードと、フォークやローカルパスを指す replace ディレクティブを含めて go.sum で正確に固定されたすべての依存関係が対象です。godig も Context7 も、これらを確認できません。go_vulncheck オペレーションは、現在のワークスペースに対して、その時点での到達可能性チェックを 1 回実行します。
• govulncheck（単独の CLI。samber/cc-skills-golang@golang-security スキルでラップされています）は、ツリー全体の監査ツールです。モジュール全体の呼び出しグラフをたどり、既知の脆弱性に実際に到達できるかを確認します。CI のゲートや定期的なセキュリティチェックで標準的に使用するツールです。gopls の go_vulncheck は、編集作業中に使うための、同じ分析を軽量に 1 回だけ実行するバージョンです。

タスクに応じて選択してください。

タスク	ツール	方法
自分のリポジトリ内でシンボルが定義されている場所を探す	gopls	samber/cc-skills-golang@golang-gopls — go_search、次に go_file_context
ファイルのパッケージ内依存関係を理解する	gopls	samber/cc-skills-golang@golang-gopls — go_file_context
依存関係の正確に解決されたソース（フォークや replace されたバージョンを含む）へ直接ジャンプする	gopls	samber/cc-skills-golang@golang-gopls — go_package_api、またはネイティブの LSP ツールの goToDefinition
自分のコード内で依存関係のシンボルを参照しているすべての呼び出し箇所を見つける	gopls	samber/cc-skills-golang@golang-gopls — go_symbol_references — godig の imported-by は公開された パッケージ のみを列挙し、あなたのリポジトリ内の呼び出し箇所は列挙しません
編集直後にコンパイラの診断を取得する	gopls	samber/cc-skills-golang@golang-gopls — go_diagnostics（MCP）、またはネイティブの LSP ツールで自動的に実行
編集中に、現在のビルドが既知の脆弱性に到達するかどうかを確認する	gopls	samber/cc-skills-golang@golang-gopls — go_vulncheck
ローカルコードの名前変更、抽出、インライン化、その他のリファクタリングを行う	gopls	samber/cc-skills-golang@golang-gopls — 安全な名前変更、refactor.* コードアクション
モジュール全体にわたるツリー全体の脆弱性監査（CI、定期的なスイープ）	govulncheck	samber/cc-skills-golang@golang-security スキル — govulncheck ./...
公開されているパッケージの利用可能なバージョンを一覧表示する	godig	godig versions <path>
まだ追加していないパッケージ/バージョンの既知の CVE を確認する	godig	godig vulns <path>
公開されているパッケージのエクスポートされたシンボル/シグネチャを確認する	godig	godig symbols / symbol doc
シンボルの実行可能なコード例を取得する	godig	godig symbol examples
パッケージのレンダリングされた README/ドキュメントを読む	godig	godig module readme / package doc
公開エコシステム全体で誰がパッケージをインポートしているかを確認する	godig	godig imported-by
パッケージまたはライブラリの候補を検索する	godig	godig search
パッケージまたはモジュールのライセンスを確認する	godig	godig package licenses / module licenses
Go 以外のライブラリ、または pkg.go.dev にインデックスされていない Go モジュールのドキュメントを取得する	Context7	resolve-library-id / query-docs

godig コマンドの完全なリファレンスについては samber/cc-skills-golang@golang-pkg-go-dev スキルを、ツリー全体の govulncheck 修復ワークフローについては samber/cc-skills-golang@golang-security スキルを参照してください。

カテゴリの概要

「use when」フック付きの完全なカタログ: by-category.md

カテゴリ	スキル
コード品質	golang-code-style golang-documentation golang-error-handling golang-lint golang-naming golang-safety golang-security golang-structs-interfaces
アーキテクチャと設計	golang-concurrency golang-context golang-data-structures golang-database golang-dependency-injection golang-design-patterns golang-modernize golang-refactoring
QA とパフォーマンス	golang-benchmark golang-observability golang-performance golang-testing golang-troubleshooting
プロジェクトセットアップ	golang-cli golang-continuous-integration golang-dependency-management golang-gopls golang-pkg-go-dev golang-popular-libraries golang-project-layout golang-stay-updated
API	golang-graphql golang-grpc golang-swagger
依存性注入	golang-dependency-injection golang-google-wire golang-uber-dig golang-uber-fx golang-samber-do
フレームワーク	golang-spf13-cobra golang-spf13-viper
samber/*	golang-samber-do golang-samber-hot golang-samber-lo golang-samber-mo golang-samber-oops golang-samber-ro golang-samber-slog
テスト	golang-stretchr-testify golang-testing

競合するクラスター — 境界線

ルーティング例を含む境界の完全な表については、disambiguation.md を参照してください。

主なクラスターとその担当：

• パフォーマンス：golang-performance（最適化パターン） · golang-benchmark（測定） · golang-troubleshooting（根本原因） · golang-observability（常時稼働の本番環境）
• DI：golang-dependency-injection（概念／判断） · golang-google-wire（コンパイル時） · golang-uber-dig（実行時リフレクション） · golang-uber-fx（ライフサイクルフレームワーク） · golang-samber-do（型安全なコンテナー）
• samber/*：golang-samber-lo（有限変換） · golang-samber-ro（リアクティブストリーム） · golang-samber-mo（モナド型）
• エラー：golang-error-handling（慣用的な方法） · golang-samber-oops（構造化エラー） · golang-safety（パニックの防止）
• スタイル：golang-code-style · golang-naming · golang-lint · golang-documentation
• CLI：golang-cli（アーキテクチャ） · golang-spf13-cobra（コマンドツリー） · golang-spf13-viper（設定の階層化）
• パッケージ検索：golang-pkg-go-dev（既存のパスについて pkg.go.dev を照会：バージョン／ドキュメント／シンボル／インポーター／CVE） · golang-gopls（ローカルで解決されたビルドの移動／リファクタリング） · golang-popular-libraries（採用するライブラリの選定） · golang-dependency-management（go.mod の管理） · golang-security（ツリー全体の CVE スキャン）
• ギャップ — 型とアーキテクチャ：golang-structs-interfaces（型設計）と golang-design-patterns（アーキテクチャパターン）
• ギャップ — ゴルーチンとキャンセル：golang-concurrency + golang-context — コンテキストを使ってゴルーチンをキャンセルする場合は、両方を読み込みます
• ギャップ — 正確性と脅威：golang-safety（内部バグ）と golang-security（外部の脅威）
• ギャップ — 機能とルール：golang-modernize（言語機能の採用）と golang-lint（静的解析の設定）
• ギャップ — プロセスと目標のルール：golang-refactoring（既存コードを安全に、段階的に、大規模に変更する プロセス — 計画、順序付け、gopls を活用した作業、段階的な PR）と golang-naming／golang-code-style／golang-project-layout／golang-design-patterns／golang-modernize（変更後のコードがどのような形であるべきかを定めるもの） — 目標の形を担うスキルと合わせて golang-refactoring を読み込みます

設定モード

golang-how-to 自体を常時読み込むよう、プロジェクトのエージェント設定ファイル（CLAUDE.md、AGENTS.md、GEMINI.md、Cursor ルール、または Copilot の指示 — プロジェクトのハーネスが読み込むもの）に指示を記述します。必要に応じて、特定のセカンダリスキルも強制的に起動できます。

samber/cc-skills-golang@golang-project-layout は、プロジェクト作成時に常時読み込みの指示を自動的に記述します。ユーザーの確認は不要で、スキルの説明を 1 つ分消費するだけで、プロジェクト固有の選択を強制することはありません。/golang-how-to configure を実行すると、指示がない場合はそれも記述され、さらに、ルーティング以外にも常に適用する必要があるスキルについて、## Required Go skills ブロックを確認できます。project-config.md に従ってください。

---

このスキルは網羅的なものではありません。詳しいガイダンスについては、個別のスキルファイルと Go の公式ドキュメントを参照してください。

このスキルプラグインにバグや予期しない動作が見つかった場合は、https://github.com/samber/cc-skills-golang/issues で issue を作成してください。