開発スキル

gitワークフローの実践を構造化します。コード変更を行う際に使用します。コミット、ブランチ作成、コンフリクト解決時、または複数の並行ストリームにわたって作業を整理する必要がある場合に使用します。リリース作成、セマンティックバージョンのバンプ選択、タグ付け、またはチェンジログ作成時に使用します。

ユーザーがGitHub Actionsのワークフローの書き方、説明、カスタマイズ、移行、セキュリティ、トラブルシューティング、ワークフロー構文、トリガー、マトリックス、ランナー、再利用可能なワークフロー、アーティファクト、キャッシュ、シークレット、OIDC、デプロイメント、カスタムアクション、またはActions Runner Controllerについて質問し、特に公式のGitHubドキュメント、正確なリンク、またはドキュメントに基づいたYAMLガイダンスが必要な場合に使用します。

生のメモ、エラーログ、音声入力、スクリーンショットを、簡潔なGitHub Flavored Markdownのissueレポートに変換します。ユーザーがバグ情報、エラーメッセージ、または非公式な説明を貼り付けて、構造化されたGitHub issueを希望する場合に使用します。視覚的な証拠として画像やGIFをサポートします。

Golangのベンチマーク、プロファイリング、パフォーマンス測定。Goのベンチマークを作成、実行、比較する際、pprofを使用したホットパスのプロファイリング、CPU/メモリ/トレースプロファイルの解釈、benchstatによる結果分析、CIベンチマーク回帰検出の設定、またはPrometheusランタイムメトリクスを使用した本番パフォーマンスの調査に使用します。また、開発者が特定のパフォーマンス指標について深い分析を必要とする場合にも使用します。このスキルは測定方法論を提供し、一方で...

We need to translate the given text from English to Japanese, preserving the name "golang-cli" and other technical terms. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "golang-cli" appears in the source text? Actually, the source text does not contain "golang-cli" explicitly; it says "Golang CLI application development." The name to preserve is "golang-cli" but it's not in the text. However, the instruction says "Do not include the name unless it appears in the source text." So we should not add it. Also preserve product names, protocol names, URLs, numbers, technical terms. So "cobra", "viper", "urfave/cli", "samber/cc-skills-golang@golang-spf13-cobra" should be kept as is. Also "CLI", "Go", "I/O", etc. Translate the rest naturally. The text: "Golang CLI application development. Use when

We need to translate the given text from English to Japanese, preserving the name "golang-code-style" and other technical terms. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "golang-code-style" appears in the source text? Actually, the source text does not contain the name "golang-code-style" explicitly. The name is given in the context: "Name to preserve: golang-code-style". But the instruction says "Do not include the name unless it appears in the source text." Since it does not appear in the source text, we should not add it. However, the source text contains references like "samber/cc-skills-golang@golang-naming" etc. Those should be preserved as is. We need to translate the description of the skill. The text describes conventions for Go code style. We'll translate into natural Japanese, keeping technical terms like "Go", "linter", "doc comments" etc. Also preserve the arrows and references. Let's break

Goの並行処理パターン。goroutine、チャネル、select、ロック、同期プリミティブ、errgroup、singleflight、ワーカープール、fan-out/fan-inパイプラインを含む並行Goコードの作成やレビュー時に使用します。また、goroutineリーク、競合状態、チャネルの所有権の問題を検出した場合や、チャネルとミューテックスのどちらを選択すべきかの判断が必要な場合にも発動します。

Go言語における慣用的なcontext.Contextの使い方 — API境界を越えた伝播、キャンセル、タイムアウトとデッドライン、リクエストスコープの値、リクエストを超えて存続するバックグラウンド処理のためのcontext.WithoutCancel。レイヤー間のコンテキスト伝播を設計する際、リークや期限切れしていないコンテキストをデバッグする際、context.Background/TODO/WithoutCancelの使い分け、またはコンテキストに値を格納する際に適用します。単にctxを第一引数として受け取るだけのコードには使用しません。

CI/CDパイプライン構成。GitHub Actionsを使用したGolangプロジェクト向け。テスト、リンティング、SAST、セキュリティスキャン、コードカバレッジ、Dependabot、Renovate、GoReleaser、コードレビュー自動化、リリースパイプラインを含む。GoプロジェクトのCI設定や改善、GitHub Actionsワークフローの構成、リンターやセキュリティスキャナーの追加、依存関係更新の自動化、品質ゲートの追加時に使用。

Golangのデータ構造 — スライス（内部構造、容量の拡大、事前割り当て、slicesパッケージ）、マップ（内部構造、ハッシュバケット、mapsパッケージ）、配列、container/list/heap/ring、strings.Builderとbytes.Bufferの比較、ジェネリックコレクション、ポインタ（unsafe.Pointer、weak.Pointer）、およびコピーセマンティクス。Goのデータ構造の選択や最適化、ジェネリックコンテナの実装、container/パッケージの使用、unsafeまたはweakポインタの利用、スライスやマップの内部構造に関する疑問がある場合に使用します。

Goデータベースアクセスの包括的ガイド — パラメータ化クエリ、構造体スキャン、NULL許容カラム、トランザクション、分離レベル、SELECT FOR UPDATE、コネクションプール、バッチ処理、コンテキスト伝搬、マイグレーションツール。PostgreSQL、MariaDB、MySQL、SQLiteと連携するGolangコードの作成、レビュー、デバッグ時、データベーステスト時、またはdatabase/sql、sqlx、pgxに関する質問時に使用します。データベーススキーマやマイグレーションSQLは生成しません。

Go言語における依存性注入（DI）の包括的ガイド。DIが重要である理由（テスト容易性、疎結合、関心事の分離、ライフサイクル管理）、手動コンストラクタインジェクション、DIライブラリの比較（google/wire、uber-go/dig、uber-go/fx、samber/do）をカバー。このスキルは、サービスアーキテクチャの設計、依存性注入の設定、密結合コードのリファクタリング、シングルトンやサービスファクトリの管理、またはユーザーが制御の反転やサービスについて質問した際に使用します。

Golangプロジェクトの依存関係管理戦略 — go.mod管理、パッケージのインストール/アップグレード、最小バージョン選択、脆弱性スキャン、古い依存関係の追跡、バイナリサイズ分析、Dependabot/Renovateの設定、競合解決、go.workワークスペース。Goの依存関係の追加、削除、アップグレード、脆弱性の監査、バージョン競合の解決、自動依存関係更新の設定時に使用します。

慣用的なGo言語のデザインパターン — 関数型オプション、コンストラクタ、エラーフローとカスケード、リソース管理とライフサイクル、グレースフルシャットダウン、耐障害性、アーキテクチャ、依存性注入、データ処理、ストリーミングなど。アーキテクチャパターンを明示的に選択する際、関数型オプションを実装する際、コンストラクタAPIを設計する際、グレースフルシャットダウンを設定する際、耐障害性パターンを適用する際、または特定の問題に適合する慣用的なGoパターンを尋ねる際に適用します。

Golangプロジェクト向けの包括的なドキュメントガイド。godocコメント、README、CONTRIBUTING、CHANGELOG、Go Playground、Exampleテスト、APIドキュメント、llms.txtをカバー。ドキュメントコメントやドキュメントの作成・レビュー時、コード例の追加時、ドキュメントサイトのセットアップ時、またはドキュメントのベストプラクティスについて議論する際に使用。ライブラリとアプリケーション/CLIの両方に対応。

We need to translate the given English text into Japanese, preserving the name "golang-error-handling" if it appears, but it does not appear in the text. The text is a description of a skill for idiomatic Go error handling. We must not add any extra commentary, labels, or formatting. Just the translation. The text includes technical terms: "Idiomatic Golang error handling", "creation", "wrapping with %w", "errors.Is/As", "errors.Join", "custom error types", "sentinel errors", "panic/recover", "single handling rule", "structured logging with slog", "HTTP request logging middleware", "samber/oops for production errors", "log aggregation 3rd-party tools", "Go code", "samber/cc-skills-golang@golang-samber-oops". These should be preserved as is or translated appropriately. For example, "Idiomatic Golang error handling" can be translated as "慣用的なGoのエラーハンドリング". But we need to keep technical terms like "errors

We need to translate the given English text into Japanese, preserving the specified name "golang-google-wire" (though it's not in the text, so no issue). The text is a description of a directory item type "agent skill". We must not include the name unless it appears in the source text. The source text does not contain "golang-google-wire". So we just translate the text. The text describes compile-time dependency injection in Golang using google/wire, listing various functions and concepts. We need to translate accurately, keeping technical terms like wire.NewSet, wire.Build, etc. as they are (they are code identifiers). Also preserve URLs? There is no URL. Numbers? None. Technical terms: "compile-time dependency injection", "injector files", "wire_gen.go", etc. We'll translate the surrounding Japanese. We must not add any extra commentary, labels, or formatting. Just the translation. Let's break down the text: "Compile-time dependency injection in Golang using google/wire — wire.NewSet, wire

gqlgenまたはgraphql-goを使用してGolangでGraphQL APIを実装します。

Golangマイクロサービス向けのgRPC利用ガイドライン、protobuf構成、および本番対応パターンを提供します。gRPCサーバー/クライアントの実装、レビュー、デバッグ時、protoファイルの作成、インターセプターの設定、ステータスコードを用いたgRPCエラー処理、TLS/mTLSの構成、bufconnを用いたテスト、ストリーミングRPCの操作時に使用します。

Golangスキルオーケストレーター — Golangのコーディング、レビュー、デバッグ、セットアップタスクで常にアクティブ。タスクコンテキストを読み取り、samber/cc-skills-golangから最も関連性の高いスキルをロードします。多くの場合、複数のスキルを同時にロードします：gRPCサービスの作成時にはgolang-grpc + golang-testing + golang-error-handlingをロード；パニックのデバッグ時にはgolang-troubleshooting + golang-safetyをロード；セキュリティ監査時にはgolang-security + golang-lint + golang-safetyをロード。また、2つのスキルが重複しているように見える場合、競合するクラスターを明確に区別します...

GolangプロジェクトにおけるLintのベストプラクティスとgolangci-lintの設定 — リンターの実行、.golangci.ymlの設定、nolintディレクティブによる警告の抑制、Lint出力の解釈、リンターの選択。golangci-lintの設定時、Lint警告やnolint抑制について質問がある時、コード品質ツールのセットアップ時、またはリンターを選択する時に使用します。また、ユーザーがgolangci-lint、go vet、staticcheck、reviveに言及した場合にも使用します。

golang-linter — AIエージェント用のインストール可能なスキルです。

Goコードを最新の言語機能、標準ライブラリの改善、慣用的なパターンを使用するようにモダナイズします。Goコードの作成やレビュー中に旧来のパターンが検出された場合、または非推奨警告に遭遇した場合にプロアクティブにトリガーします。また、ユーザーが明示的にモダナイゼーション、Goバージョンアップグレード、CI/ツールのリフレッシュを依頼した場合にも使用します。

Go（Golang）の命名規則 — パッケージ、コンストラクタ、構造体、インターフェース、定数、列挙型、エラー、ブーリアン、レシーバ、ゲッター/セッター、関数型オプション、頭字語、テスト関数、サブテスト名をカバーします。新しいGoコードを書くとき、レビューやリファクタリングを行うとき、命名の選択肢（New vs NewTypeName、isConnected vs connected、ErrNotFound vs NotFoundError、StatusReady vs StatusUnknown at iota 0）を検討するとき、Goパッケージ名（utils/helpersアンチパターン）について議論するとき、または...にこのスキルを使用してください。

Go言語の日常的な可観測性 — 本番環境で常時オンとなるシグナル。slogによる構造化ログ、Prometheusメトリクス、OpenTelemetry分散トレーシング、pprof/Pyroscopeによる継続的プロファイリング、サーバーサイドRUMイベント追跡、アラート、Grafanaダッシュボードをカバー。Goサービスを本番監視用に計装する際、メトリクスやアラートを設定する際、OpenTelemetryトレーシングを追加する際、ログとトレースを関連付ける際、レガシーロガー（zap/logrus/zerolog）をslogに移行する際、追加する際に適用。

Golangのパフォーマンス最適化パターンと方法論 - XのボトルネックがあればYを適用。アロケーション削減、CPU効率、メモリレイアウト、GCチューニング、プーリング、キャッシング、ホットパス最適化をカバー。プロファイリングやベンチマークでボトルネックが特定され、それを修正するための適切な最適化パターンが必要な場合に使用。また、パフォーマンスコードレビューを行い、改善点や迅速なパフォーマンス向上を特定するのに役立つベンチマークを提案する場合にも使用。測定方法論には使用しない（→...）

本番環境で使用可能なGolangライブラリとフレームワークを推奨します。ユーザーが明示的にライブラリの提案を求めた場合、代替案の比較を希望する場合、特定のタスクに適したライブラリを選択する必要がある場合、またはプロジェクトに新しい依存関係を追加する際に適用します。

Golangプロジェクトのレイアウトとワークスペースの設定ガイドを提供します。新しいGoプロジェクトを開始するとき、既存のコードベースを整理するとき、複数のパッケージを持つモノレポを設定するとき、複数のメインパッケージを持つCLIツールを作成するとき、cmd/internal/pkgディレクトリの規約を決定するとき、またはパッケージの再構築、パッケージ分割、モジュール分割について議論するときに使用します。

防御的なGolangコーディングにより、パニック、データの静かな破損、および微妙なランタイムバグを防止します。nilパニック、appendエイリアシング、マップの同時アクセス、浮動小数点比較の落とし穴、またはゼロ値設計に関する問題に遭遇した場合に使用します。また、nil安全性、数値変換のオーバーフロー、リソースライフサイクルの問題（ループ内のdefer）、またはスライスやマップの防御的コピーについてコードをレビューする際にも使用します。

Golangでsamber/doを使用した依存性注入 — サービスコンテナ、ライフサイクル管理、スコープ、ヘルスチェック、グレースフルシャットダウン、モジュール構成。samber/doを使用または採用する場合、コードベースがgithub.com/samber/doまたはgithub.com/samber/do/v2をインポートしている場合、または手動のコンストラクタインジェクションをDIコンテナにリファクタリングする場合に適用します。