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

引数

• --parallel: テクノロジー領域ごとに特化したサブエージェントを起動
• Path: 対象ディレクトリ(デフォルト: 現在の作業ディレクトリ)

ステップ 1: 変更されたファイルを識別

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

パス条件: 何も出力されない場合は、サマリーに このdiffにGo ファイルがありません と記載し、ステップ 2～6 をスキップ してください。スコープ外のファイルに対して発見内容を作成しないでください。

ステップ 2: テクノロジーを検出

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

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

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

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

# テストファイルを確認
git diff --name-only $(git merge-base HEAD main)..HEAD | grep -E '_test\.go$'

ステップ 3: 検証プロトコルをロード

beagle-go:review-verification-protocol スキルをロードし、レビュー全体を通じてそのチェックリストを念頭に置いてください。

ステップ 4: スキルをロード

Skill ツールを使用して適用可能な各スキルをロードしてください(例: Skill(skill: "beagle-go:go-code-review"))。

常にロード:

• beagle-go:go-code-review

検出に基づいて条件付きでロード:

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

ステップ 5 の前にパス: beagle-go:go-code-review をロードしました(およびステップ 3 の検証プロトコル)。条件付き スキルはその行が該当する場合のみロードしてください: ステップ 1 の diff に _test.go がある → テストスキル; BubbleTea/Wish/Prometheus スキルはステップ 2 の grep が少なくとも 1 つのパスを返した場合のみ(grep が何も返さない場合はそのスキルをロード しない)。

ステップ 5: レビュー

順序実行(デフォルト):

1. 適用可能なスキルをロード
2. Go の品質問題(エラーハンドリング、並行処理、インターフェース)を最初にレビュー
3. 検出されたテクノロジー領域をレビュー
4. 発見内容を統合

並列実行(--parallel フラグ):

1. すべてのテクノロジーを事前に検出
2. Task ツールでテクノロジー領域ごとに 1 つのサブエージェントを起動
3. 各エージェントがそのスキルをロードしてそのドメインをレビュー
4. すべてのエージェントを待機
5. 発見内容を統合

ステップ 6: 発見内容を検証

問題を報告する前に:

1. 実際のコードを再度読む(diff コンテキストまたは抜粋のみではなく)
2. 「未使用」の主張については - すべての参照を検索しましたか?
3. 「不足」の主張については - フレームワーク/親の処理を確認しましたか?
4. 構文の問題については - 最新バージョンのドキュメントに対して検証しましたか?
5. スタイル設定の好みであり、実際の問題ではない発見内容を削除

Critical または Major 問題を記載する前の厳密なゲート (Informational はより軽い基準):

1. 読み込み深度: ファイルをディスク上で開き、少なくとも囲まれた関数またはブロックを読みました(diff のみまたは抜粋のみの読み込みでは不十分)。
2. 未使用/デッドコード: 参照検索(rg/IDE)を実行し、結果を発見内容に記載しました(例: テスト以外の参照がない)、または未使用シンボルの主張をしていません。
3. 「不足」の動作: 呼び出し元、フレームワークの配線、またはドキュメントで主張されたギャップを確認しました、またはアイテムを格下げ/削除しました。

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

単一パスの完全性

すべてのカテゴリ(スタイル、ロジック、型、テスト、セキュリティ、パフォーマンス)にわたるすべての問題を単一のレビューパスで報告する 必要があります。後のラウンド用に問題を保留しないでください。

発見内容を送信する前に、自問してください:

• 「推奨されるすべての修正が適用された場合、修正されたコード内で新しい問題を見つけるでしょうか?」
• 「新しいコード(テスト、型、モジュール)をリクエストしており、それ自体がレビューが必要になるでしょうか?」

どちらかが「はい」の場合: これらの予想される下流の問題を 今すぐ このレビューに含めるので、著者がすべてを一度に対処できます。

スコープルール

• diff 内のコードと直接関連する既存のコードのみをレビュー
• diff の前に存在しなかった新機能、テストインフラストラクチャ、またはアーキテクチャ変更をリクエストしない
• テストカバレッジが不足している場合は、1 つの Minor 問題として記載してください(「X、Y、Z のテストカバレッジがありません」) — モックライブラリ、動作抽出、依存性注入パターンなど、大量の新しいコードを導入する実装詳細を指定しない
• 仕様、ドキュメント、命名の問題は、公開 API コントラクトに影響しない限り Minor
• 新しい依存関係(Mox、テストライブラリ、リンタープラグインなど)の追加をリクエストしない

修正の複雑さ予算

既存のコードへの修正は、サイズに関係なく実際の重大度でフラグを立てる必要があります。

ただし、diff の前に存在しなかった純粋な新しいコードのリクエスト は Informational に分類する必要があります:

• 新しい依存関係の追加(Mox、リンタープラグイン)
• 完全に新しいモジュール、ファイル、またはテストスイートの作成
• 新しい動作、プロトコル、または抽象化の抽出

これらは著者が将来の作業で検討する改善提案であり、レビューの制約ではありません。

反復ポリシー

これが修正が適用された後の再レビューの場合:

• 以前にフラグが立てられた問題が正しく対処されたかのみを検証
• 前回のレビューの問題に関連しない新しい発見内容を導入しない
• 修正されなかった Minor/Nice-to-Have 問題を受け入れる — 再度フラグを立てない
• 再レビューの目標は 検証 であり、発見ではありません

出力形式

## レビューサマリー

[発見内容の 1～2 文の概要]

## 問題

### Critical(ブロッキング)

1. [FILE:LINE] ISSUE_TITLE
   - Issue: 何が問題かの説明
   - Why: これが重要な理由(バグ、競合状態、リソースリーク、セキュリティ)
   - Fix: 推奨される具体的な修正

### Major(修正すべき)

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

### Minor(あると良い)

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

### Informational(参考)

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

## 良いパターン

- [FILE:LINE] パターン説明(保持)

## 判定

Ready: Yes | No | With fixes 1-N (Critical/Major のみ; Minor アイテムは許可される)
Rationale: [1～2 文]

修正後の検証

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

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

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

ルール

• レビュー前にスキルをロード(後ではなく)
• すべての問題に連続番号を付ける(1、2、3...)
• 各問題に FILE:LINE を含める
• Issue/Why/Fix を明確に分離
• 実際の重大度で分類
• -race フラグで競合状態をチェック
• 修正後に検証を実行
• 単一パスですべての問題を報告 — 後のイテレーション用に問題を保留しない
• 再レビューは前回の修正の検証 のみ — 新しい発見ではない
• 純粋な新しいコード(新しいモジュール、依存関係、テストスイート)のリクエストは Informational であり、ブロッキング ではない
• Verdict は Minor および Informational アイテムを無視 — Critical および Major のみが承認をブロック