review-go

Go バックエンドのコードレビュー

引数

• --parallel：エージェントが対応している場合、各技術領域を並行してレビューします（ステップ 5 を参照）
• パス：対象ディレクトリ（デフォルト：現在の作業ディレクトリ）

ステップ 1：変更されたファイルを特定する

git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '\.go$'

合格条件： 何も出力されない場合は、概要に No Go files in this diff と記載し、ステップ 2～6 をスキップしてください。対象外のファイルについて、指摘事項をでっち上げてはいけません。

ステップ 2：使用技術を検出する

# Detect BubbleTea TUI
grep -r "charmbracelet/bubbletea\|tea\.Model\|tea\.Cmd" --include="*.go" -l | head -3

# Detect Wish SSH
grep -r "charmbracelet/wish\|ssh\.Session\|wish\.Middleware" --include="*.go" -l | head -3

# Detect Prometheus
grep -r "prometheus/client_golang\|promauto\|prometheus\.Counter" --include="*.go" -l | head -3

# Detect ZeroLog
grep -r "rs/zerolog\|zerolog\.Logger" --include="*.go" -l | head -3

# Check for test files
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '_test\.go$'

ステップ 3：検証プロトコルを読み込む

review-verification-protocol スキルを読み込み、レビュー中はそのチェックリストを常に念頭に置いてください。

ステップ 4：スキルを読み込む

該当する以下のスキルをそれぞれ読み込み（SKILL.md を開き、その指示に従ってください）。

必ず読み込む：

• go-code-review

検出結果に応じて読み込む：

条件	スキル
テストファイルが変更されている	go-testing-code-review
BubbleTea が検出された	bubbletea-code-review
Wish SSH が検出された	wish-ssh-code-review
Prometheus が検出された	prometheus-go-code-review

ステップ 5 の開始条件： go-code-review（およびステップ 3 の検証プロトコル）を読み込んでいること。条件付きスキルは、該当する行の条件を満たす場合に限り読み込んでください。ステップ 1 の差分に _test.go が含まれる場合はテスト用スキルを読み込み、BubbleTea／Wish／Prometheus のスキルは、ステップ 2 の該当する grep でパスが 1 つ以上返された場合に限り読み込んでください（grep が何も返さなかった場合、そのスキルを読み込んではいけません）。

ステップ 5：レビューする

エージェントがサブエージェントに対応している場合は、技術領域ごとに 1 つずつ並行して割り当てます。対応していない場合は、各領域を順番にレビューします。どちらの方法でも、出力は同じになります。

逐次実行（デフォルト。サブエージェントが利用できない場合の代替方法）：

1. 該当するスキルを読み込む
2. まず Go の品質上の問題（エラー処理、並行処理、インターフェース）をレビューする
3. 検出された技術領域をレビューする
4. 指摘事項を統合する

並行実行（--parallel。エージェントがサブエージェントに対応している場合のみ）：

1. すべての技術を事前に検出する
2. 技術領域ごとに 1 つずつサブエージェントを割り当てる
3. 各サブエージェントがスキルを読み込み、担当領域をレビューする
4. すべてのサブエージェントの完了を待つ
5. 指摘事項を統合する

ステップ 6：指摘事項を検証する

問題を報告する前に、以下を行ってください。

1. 実際のコードを再読する（差分の文脈だけではなく）
2. 「未使用」と主張する場合は、すべての参照を検索したか確認する
3. 「不足している」と主張する場合は、フレームワークや親側で処理されていないか確認する
4. 構文上の問題については、現行バージョンのドキュメントで検証する
5. 実際の問題ではなく、スタイル上の好みにすぎない指摘は削除する

重大または主要な問題を列挙する前の必須条件（情報提供のみの指摘には、より軽い基準を適用できます）：

1. 読み込み範囲： ディスク上のファイルを開き、該当する関数またはブロックを少なくとも全体的に読んでいること（差分だけ、または抜粋だけを読むのでは不十分です）。
2. 未使用／デッドコード： 参照検索（rg／IDE）を実行し、その結果を指摘事項に記載していること（例：テスト以外に参照がない）。そうでなければ、シンボルが未使用だと主張しないこと。
3. 「不足している」動作： 主張する不足について、呼び出し元、フレームワークの配線、またはドキュメントを確認していること。確認していない場合は、重要度を下げるか、指摘を削除してください。

ステップ 7：レビューの収束

1 回のレビューでの完全性

すべてのカテゴリ（スタイル、ロジック、型、テスト、セキュリティ、パフォーマンス）にわたるすべての問題を、1 回のレビューですべて報告しなければなりません。後のラウンドに問題を持ち越さないでください。

指摘事項を提出する前に、以下を自問してください。

• 「推奨した修正をすべて適用した場合、修正後のコードで新たな問題を見つけることになるだろうか？」
• 「それ自体がレビューを要する新しいコード（テスト、型、モジュール）を要求していないだろうか？」

どちらかが「はい」であれば、作成者が一度にすべて対応できるよう、予想される後続の問題も今回のレビューに含めてください。

スコープルール

• 差分内のコードと、直接関連する既存のコードのみをレビューしてください
• 差分以前には存在しなかった新機能、テスト基盤、アーキテクチャの変更を要求しないでください
• テストカバレッジが不足している場合は、「X、Y、Z のテストカバレッジが不足しています」という 1 件の軽微な問題として指摘してください。モックライブラリ、動作の切り出し、依存性注入のパターンなど、大幅な新規コードを要する実装の詳細は指定しないでください
• Typespec、ドキュメント、命名に関する問題は、公開 API の契約に影響する場合を除き、軽微な問題です
• 新しい依存関係（Mox、テストライブラリ、リンタープラグインなど）の追加を要求しないでください

修正の複雑さの基準

既存コードの修正は、規模にかかわらず実際の重大度で指摘してください。

ただし、差分以前には存在しなかった新規コードの追加を求める場合は、情報提供として分類する必要があります。

• 新しい依存関係の追加（Mox、リンタープラグインなど）
• 完全に新しいモジュール、ファイル、テストスイートの作成
• 新しい動作、プロトコル、抽象化の切り出し

これらは、レビューを妨げる指摘ではなく、今後の作業で作成者が検討する改善提案です。

イテレーションポリシー

修正適用後の再レビューの場合：

• 以前に指摘した問題が正しく修正されたかどうかのみを確認してください
• 以前の指摘と関係のない新たな問題を追加しないでください
• 修正されていない軽微な問題や「あれば望ましい」問題は受け入れ、再度指摘しないでください
• 再レビューの目的は検証であり、新たな問題の発見ではありません

出力形式

## Review Summary

[1-2 sentence overview of findings]

## Issues

### Critical (Blocking)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: Description of what's wrong
   - Why: Why this matters (bug, race condition, resource leak, security)
   - Fix: Specific recommended fix

### Major (Should Fix)

2. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Minor (Nice to Have)

N. [FILE:LINE] ISSUE_TITLE
   - Issue: ...
   - Why: ...
   - Fix: ...

### Informational (For Awareness)

N. [FILE:LINE] SUGGESTION_TITLE
   - Suggestion: ...
   - Rationale: ...

## Good Patterns

- [FILE:LINE] Pattern description (preserve this)

## Verdict

Ready: Yes | No | With fixes 1-N (Critical/Major only; Minor items are acceptable)
Rationale: [1-2 sentences]

修正後の検証

修正を適用した後、以下を実行してください。

go build ./...
go vet ./...
golangci-lint run
go test -v -race ./...

承認する前に、すべてのチェックに合格する必要があります。

ルール

• レビューの前にスキルを読み込んでください（レビュー後ではありません）
• すべての問題に連番を付けてください（1、2、3……）
• 各問題に FILE:LINE を記載してください
• Issue／Why／Fix を明確に分けてください
• 実際の重大度に基づいて分類してください
• -race フラグを使って競合状態を確認してください
• 修正後に検証を実行してください
• すべての問題を一度のレビューで報告してください。後のイテレーションに指摘を先送りしないでください
• 再レビューでは以前の修正のみを検証してください。新たな問題は発見しないでください
• 新規モジュール、依存関係、テストスイートなど、新規コードの追加要求は、ブロッキングではなく情報提供として扱ってください
• 判定では軽微な問題と情報提供の項目は無視し、重大または大規模な問題のみを承認の妨げとします