name: go-code-review description: Go コードレビュー。コード実装後やPR作成前に使用し、並行処理の安全性と一般的なGoのコーディング規約をレビューします。git diffを自動取得して変更されたコードを分析し、race condition、goroutineリーク、エラーハンドリング、命名規則などをチェックして詳細なフィードバックを提供します。

Go Code Review

Overview

このスキルは、Goコードの品質を向上させるためのコードレビューを実施します。以下を重点的にチェックします:

• 並行処理の安全性: goroutine、channel、mutex、race conditionの検出
• 一般的なGoコーディング規約: Effective Go、命名規則、エラーハンドリング

レビューワークフロー

1. レビュー対象の特定

以下のいずれかの方法でレビュー対象を特定します:

方法A: git diffから自動取得(推奨)

# 変更されたファイルを確認
git status

# 変更差分を取得
git diff

変更されたGoファイル(*.go)を特定し、それらをレビュー対象とします。

方法B: ユーザー指定

ユーザーが明示的に指定したファイルやコードスニペットをレビューします。

2. コードの読み込み

レビュー対象のファイルを読み込みます:

# Readツールを使用
Read tool: path/to/file.go

重要: 必ず実際のファイルを読んでからレビューしてください。推測でレビューしないこと。

3. コンテキストの理解

必要に応じて、以下のreferencesファイルを読み込んでレビュー基準を確認します:

• go-coding-standards.md: 一般的なGoのコーディング規約
• concurrency-review.md: 並行処理の安全性レビューガイド
• review-checklist.md: 体系的なレビューチェックリスト

読み込みタイミング:

• コーディング規約の確認: references/go-coding-standards.md
• goroutineやchannel使用時: references/concurrency-review.md
• 体系的にレビューしたい場合: references/review-checklist.md

4. レビューの実施

以下の優先順位でレビューします:

優先度1: 並行処理の安全性

Goroutineリーク:

• 終了条件が明確か
• Contextでキャンセルを制御しているか
• defer wg.Done() を使っているか

Race Condition:

• 共有変数へのアクセスが保護されているか
• Mapへの並行書き込みがないか
• Sliceへの並行appendがないか

Channel使用:

• バッファサイズが適切か
• 全結果を待っているか
• Busy loopになっていないか

詳細は references/concurrency-review.md を参照。

優先度2: エラーハンドリング

• 全てのエラーをチェックしているか
• fmt.Errorf の %w でwrapしているか
• エラーメッセージに具体的なコンテキストがあるか
• panicを通常処理で使っていないか

優先度3: コーディング規約

命名規則:

• パッケージ名が小文字の単一単語か
• 公開関数/型が大文字で始まっているか
• スネークケースを使っていないか

関数設計:

• 1つの関数が1つの責務を持っているか
• 関数が適切な長さか(目安: 50行以内)
• 早期リターンでネストを浅くしているか

リソース管理:

• defer でリソース解放しているか
• Contextが適切に伝播されているか

詳細は references/go-coding-standards.md を参照。

優先度4: テストコード

テーブルドリブンテスト:

• テストケース名が具体的か
• t.Run でサブテストを実行しているか
• エッジケースがカバーされているか

テストの独立性:

• テストが他のテストに依存していないか
• グローバル状態を変更していないか

5. レビューコメントの作成

以下の形式でフィードバックを提供します:

重大な問題(修正必須):

❌ [並行処理] Race conditionの可能性があります
ファイル: xxx.go:70
理由: 共有変数への並行アクセスが保護されていません
提案: mutexまたはchannelで保護してください

参照: references/concurrency-review.md#race-conditionの検出

改善提案(推奨):

⚠️ [コーディング規約] 早期リターンを推奨します
ファイル: xxx.go:45
理由: ネストが深く読みにくいです
提案: if err != nil { return err } パターンを使ってください

参照: references/go-coding-standards.md#if文

良い点(称賛):

✅ [並行処理] goroutineとchannelの使い方が適切です
ファイル: xxx.go:68-86
理由: バッファサイズが適切で、全ての結果を待っています

質問:

❓ [設計] この関数は分割できませんか?
ファイル: xxx.go:95
理由: 100行を超えており、複数の責務を持っているように見えます

使用例

例1: 変更されたコードのレビュー

ユーザー: "現在の変更をレビューしてください"

実行手順:

1. git status で変更ファイルを確認
2. git diff で差分を取得
3. 変更されたGoファイルをReadで読み込み
4. 上記のワークフローに従ってレビュー
5. フィードバックを提供

例2: 特定ファイルのレビュー

ユーザー: "server.goをレビューしてください"

実行手順:

1. 指定されたファイルをReadで読み込み
2. 必要に応じてreferencesを参照
3. 並行処理、エラーハンドリング、コーディング規約をチェック
4. フィードバックを提供

例3: 並行処理に特化したレビュー

ユーザー: "goroutineの使い方をレビューしてください"

実行手順:

1. 対象ファイルをReadで読み込み
2. references/concurrency-review.md を読み込み
3. goroutine、channel、sync関連のコードを重点的にチェック
4. Race conditionやリークの可能性を指摘
5. フィードバックを提供

静的解析ツールの併用

レビュー前に以下のツールを実行することを推奨します(スキル内では実行しません):

# 基本チェック
go vet ./...

# Race detector
go test -race ./...

# 静的解析
staticcheck ./...

# 総合Linter
golangci-lint run

これらのツールで検出されない、コードの設計や可読性の問題を本スキルで検出します。

レビュー時の注意事項

やるべきこと

• ✅ 実際のコードを読んでからレビューする
• ✅ 具体的なファイル名と行番号を指摘する
• ✅ 改善案を提示する
• ✅ 良い点も積極的に評価する
• ✅ 必要に応じてreferencesを参照する

やらないこと

• ❌ コードを読まずに推測でレビューする
• ❌ 抽象的な指摘のみで終わらせる
• ❌ 批判のみでポジティブなフィードバックを忘れる
• ❌ referencesを無視して主観的に評価する

Resources

このスキルには以下のreferencesが含まれています:

references/go-coding-standards.md

一般的なGoのコーディング規約とベストプラクティス。Effective Go、命名規則、エラーハンドリング、関数設計、パッケージ構成などを網羅しています。

使用タイミング: コーディング規約の確認、命名規則、関数設計のレビュー時

references/concurrency-review.md

Go並行処理の安全性レビューガイド。goroutineリーク、race condition、channelの適切な使用方法、mutexの使い方などを網羅しています。

使用タイミング: goroutine、channel、mutex、sync.*を使っているコードのレビュー時

references/review-checklist.md

レビュー時の体系的なチェックリスト。コーディング規約、エラーハンドリング、並行処理、関数設計、テスト、セキュリティ、パフォーマンスの全項目を網羅しています。

使用タイミング: 包括的なレビューを実施したい場合、レビュー漏れを防ぎたい場合

よくある質問

Q: referencesを全て読む必要がありますか? A: いいえ。レビュー対象のコードに応じて、必要なreferencesのみを読んでください。例えば、goroutineを使っていない場合はconcurrency-review.mdを読む必要はありません。

Q: レビューコメントの優先度は? A: ❌(重大な問題) > ⚠️(改善提案) > ❓(質問) > ✅(良い点) の順です。

Q: 全てのチェック項目を確認する必要がありますか? A: 対象コードに応じて、該当する項目のみをチェックしてください。例えば、テストコードでない場合、テストパターンの確認は不要です。