Menu
Goコードの読解・修正・実装・レビュー時に使用。並行処理、エラー処理、chi/GORM規約を扱う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
1Password CLI (op) でサインイン・vault 確認・secret 注入を行う時に使う。Claude セッションでは service account token (OP_SERVICE_ACCOUNT_TOKEN) をtoken ファイル (~/.config/op/service-account-token) から直前注入する方式を使い、op read の stdout を Claude context に流さない方針を強制する。「op signin」「op service-account」「op read」「op run」「op inject」「1Password から取って」などで発火。
Browser automation for opening sites, forms, clicks, screenshots, scraping, login, and web app testing.
Run browser automation on AWS Bedrock AgentCore cloud browsers or AWS-hosted sessions.
Capture architecture decisions as ADRs with context, alternatives, and rationale.
不具合修正のワークフロー（調査→再現→修正→検証）を controller がオーケストレーションするための指揮書。バグ・不具合・障害の修正で使う。explorer で原因特定、implementer で再現テスト→修正、verifier で検証。「バグを直して」「不具合修正」「この障害を調査して直す」などで参照。
Create CodeTour `.tour` walkthroughs with file/line anchors.
| name | coding-golang |
| description | Goコードの読解・修正・実装・レビュー時に使用。並行処理、エラー処理、chi/GORM規約を扱う。 |
| invocation | auto |
| ecc-imports | [{"upstream-commit":"4e66b2882da9afb9747468b08a253ca2f09c85f3","upstream-path":"skills/golang-patterns/SKILL.md","sections-merged":[],"conflicts":["When to Activate","Core Principles","Error Handling Patterns","Concurrency Patterns","Interface Design","Package Organization","Struct Design","Memory and Performance","Go Tooling Integration","Quick Reference: Go Idioms","Anti-Patterns to Avoid"],"imported-at":"2026-04-26T15:00:00.000Z"}] |
| 項目 | バージョン |
|---|---|
| Go | 1.21+ |
| chi | v5.x |
| GORM | v1.25+ |
| GORM-Gen | v0.3+ |
汎用的なGo言語のコード作成を支援するスキル。chiルーター、GORM/GORM-Gen、プロジェクト固有のロガーを活用し、Goのベストプラクティスとプロジェクト固有の規約に従った高品質なコードを提供する。
ライブラリの最新ドキュメントが必要な場合は、Context7 MCPツールを使用すること。
# 例: chi の最新ドキュメントを取得
1. resolve-library-id で "go-chi/chi" を検索
2. query-docs でライブラリIDを使って必要な情報を取得
| ライブラリ | 用途 | 参照 |
|---|---|---|
| chi | HTTPルーター | chi-patterns.md |
| GORM / GORM-Gen | ORM（GORM-Gen優先） | gorm-patterns.md |
| プロジェクト固有ロガー | ロギング | プロジェクト内のコードを参照 |
コード作成時は、以下を必ず確認すること：
最新のGoの機能を積極的に活用する（modern-go.md参照）：
// 関数のドキュメントコメント
// CreateUser creates a new user with the given information.
func CreateUser(ctx context.Context, name, email string) (*User, error) {
// 入力バリデーション（早期リターン）
if err := validateUserInput(name, email); err != nil {
return nil, err
}
// ビジネスロジック
user := &User{Name: name, Email: email}
if err := saveUser(ctx, user); err != nil {
return nil, fmt.Errorf("failed to save user: %w", err)
}
return user, nil
}
コード作成時に以下を確認すること：
実装時には該当するパターンを参照すること：
| ファイル | 内容 |
|---|---|
| chi-patterns.md | chiルーターの使用パターン（ルーティング、ミドルウェア、認証） |
| gorm-patterns.md | GORM/GORM-Genの使用パターン（CRUD、リレーション、トランザクション） |
| error-handling.md | エラーハンドリングパターン（カスタムエラー、ラッピング） |
| coding-standards.md | コーディング規約とベストプラクティス |
| modern-go.md | Go 1.21+の新機能（slog、errors.Join等） |
| concurrency-patterns.md | 並行処理の実装パターン（遷移期間、Close()非破壊、抽象化境界） |
必要に応じてリファレンスドキュメントを参照し、プロジェクト固有の規約とGoのベストプラクティスに従ったコードを作成すること。 テスト作成時は testing-golang、レビュー時は reviewing-golang を発動すること。
ECC base commit
4e66b2882da9afb9747468b08a253ca2f09c85f3のskills/golang-patterns/SKILL.mdを検証したが、本 skill の構造（references/に詳細を委譲する索引型 + プロジェクト固有規約優先）と異なるため統合せず、全 H2 を conflicts として記録。ECC
golang-patternsは idiomatic Go の汎用パターン解説（674 行）:
- 重複領域 (既存 references/ と重複、既存優先): Core Principles / Error Handling Patterns / Concurrency Patterns
- 既存:
references/error-handling.md,references/concurrency-patterns.md,references/coding-standards.md- 既存になし (将来取り込み余地あり): Interface Design / Package Organization / Struct Design / Memory and Performance / Go Tooling Integration / Quick Reference: Go Idioms / Anti-Patterns to Avoid
- 必要に応じて ECC 原文を
references/ecc-golang-patterns.mdとして配置するか、特定章を抜粋して既存 reference に追記する形で将来取り込む（本 spec のスコープ外）本 skill は プロジェクト固有規約最優先（chi / GORM / プロジェクト固有ロガー）を SKILL.md 冒頭で明記しており、ECC を一括統合すると索引性が下がるため。
タスクが以下のいずれかに該当する場合、references/concurrency-patterns.md を Read ツールで読み込んでから 設計・実装を行うこと:
リファレンスを読んだ上で、各パターンが該当するか判断し、該当するパターンを修正に適用すること。 新しい状態遷移を追加した場合、その状態を書き込む既存コードパス（Close/Shutdown等）が新しい遷移と安全に共存するか確認すること。
Go リポジトリでコミットする前に以下を検証する。
変更ファイルにビルドタグ (//go:build integration 等) がある場合、タグ付きビルドで検証する:
go build -tags integration ./path/to/package/...
go build ./... はビルドタグ付きファイルをスキップするため、これだけでは不十分。staging 済みファイルのビルドタグを確認し、該当するパッケージをタグ付きでビルドすること。
proto 生成 (buf generate 等)、Wire DI 生成 (wire)、mock 生成 (go generate) の実行後は、git status で未 staging の生成ファイルがないことを確認する。生成ツールは複数ディレクトリに出力することがある (例: gen/ と gengogofast/)。生成コマンド実行後は必ず git status で全出力先を確認すること。
ビルド / テスト / デプロイ / 環境構築の操作で raw shell / ansible / docker / kubectl コマンドを書く前に、対応する Makefile target が存在するか確認する。
cat Makefile / make -n <target> / grep -E '^[a-zA-Z_-]+:' Makefile で既存 target を確認例外: 単発の調査コマンド (docker ps, kubectl get pods 等の read-only)、Makefile が存在しないリポジトリ、ユーザーが明示的に raw コマンドを指示。