review-tui

TUI コードレビュー

引数

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

ゲート（順番に実施）

各合格条件を満たした場合にのみ次へ進んでください（スコープの逸脱や、根拠のないブロックの主張を減らすためです）。

ゲート	合格条件
G1 — スコープ	ステップ 1 で、対象となる .go パスの具体的な一覧が作成されている（git コマンドまたはユーザーが明示したパスに基づく）。一覧が空の場合は、スコープを確認するために停止したか、レビューの前に合意済みの非 git スコープ（例：単一のファイル／ディレクトリ）を記録している。
G2 — レビュー前のスキル読み込み	review-verification-protocol、go-code-review、bubbletea-code-review が読み込まれている。ステップ 4 の条件に該当するスキル（テスト → go-testing-code-review、Wish → wish-ssh-code-review）もステップ 5 の前に読み込まれている。
G3 — Critical／Major の根拠	各 Critical／Major の指摘に、開いたソース内のファイルパス＋行番号（または短い引用スニペット）が示されている。差分のハンクだけを根拠にしてはならない。
G4 — 出力前の確認	採用する各指摘について、「Issues」セクションを書く前に、ステップ 7 および読み込んだ検証プロトコルに照らして確認している。

G2 を通過するまでステップ 5 を開始しないでください。G3 と G4 を通過するまで Critical／Major を公開しないでください。

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

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

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

# Detect BubbleTea (required for TUI review)
grep -r "charmbracelet/bubbletea" --include="*.go" -l | head -3

# Detect Lipgloss styling
grep -r "charmbracelet/lipgloss\|lipgloss\.Style" --include="*.go" -l | head -3

# Detect Bubbles components
grep -r "charmbracelet/bubbles\|list\.Model\|textinput\.Model\|viewport\.Model" --include="*.go" -l | head -3

# Detect Wish SSH server
grep -r "charmbracelet/wish\|ssh\.Session" --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
• bubbletea-code-review

検出内容に応じて読み込む：

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

ステップ 5：重点確認項目

Model/Update/View（Elm アーキテクチャ）

• Model が不変である（Update が新しい model を返す）
• Init が適切な初期コマンドを返す
• Update がすべてのメッセージタイプを処理する
• View が純粋関数である（副作用がない）
• 終了時に tea.Quit が正しく使用されている

Lipgloss のスタイリング

• スタイルがパッケージレベルで一度だけ定義されている
• View 関数内でスタイルを作成していない
• 明暗テーマに AdaptiveColor を使用している
• レイアウトが WindowSizeMsg に応じて変化する

コンポーネントの構成

• サブコンポーネントの更新が伝播されている
• サイズ変更可能なコンポーネントに WindowSizeMsg が渡されている
• 複数コンポーネントのフォーカスが管理されている
• ビュー遷移の状態機械が明確である

SSH サーバー（該当する場合）

• ホストキーが永続化されている
• グレースフルシャットダウンが実装されている
• PTY のウィンドウサイズが TUI に渡されている
• セッションごとに Lipgloss レンダラーが用意されている

ステップ 6：レビュー

エージェントがサブエージェントに対応している場合は、技術領域ごとに 1 つずつ割り当てて並行して実施してください。対応していない場合は、領域ごとに順番に実施してください。どちらの場合も出力は同じです。

逐次（デフォルト、およびサブエージェントを利用できない場合の代替手順）：

1. 該当するスキルを読み込む
2. Go コードの品質をレビューする
3. BubbleTea のパターン（Model/Update/View）をレビューする
4. Lipgloss のスタイリングをレビューする
5. コンポーネントの構成をレビューする
6. SSH サーバーをレビューする（該当する場合）
7. 指摘事項をまとめる

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

1. すべての技術を事前に検出する
2. Go の品質、BubbleTea、SSH について、それぞれサブエージェントを 1 つ割り当てる
3. すべてのサブエージェントの完了を待つ
4. 指摘事項をまとめる

ステップ 7：指摘事項の検証

問題を報告する前に：

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

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

1 回のレビューでの網羅性

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

指摘を提出する前に、次の点を自問します：

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

いずれかの答えが「はい」の場合、作者が一度にすべて対応できるよう、予想される後続の問題も今回のレビューに含めます。

スコープのルール

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

修正の複雑さに関する予算

既存コードへの修正は、規模にかかわらず実際の重大度で指摘する必要があります。

ただし、差分以前には存在しなかった新規コードの要求は、Informational に分類する必要があります：

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

これらは今後の作業で作者が検討する改善提案であり、レビューを阻止するものではありません。

イテレーションの方針

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

• 以前に指摘した問題が正しく対処されているかのみを確認します
• 以前の指摘とは関係のない新たな問題を持ち出さないでください
• 修正されていない Minor／Nice-to-Have の問題は許容し、再度指摘しないでください
• 再レビューの目的は問題の発見ではなく、修正の検証です

出力形式

## 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 (UI freeze, crash, resource leak)
   - 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 を明確に分けます
• 実際の重大度に基づいて分類します
• 次の点に特に注意します：
  • Update 内のブロッキング処理（UI がフリーズする）
  • View 内でのスタイル生成（パフォーマンス）
  • WindowSizeMsg の処理不足（リサイズが機能しない）
• 修正後に検証を実行します
• 1 回のレビューですべての問題を報告します。後のイテレーションのために指摘を保留しないでください
• 再レビューでは以前の修正のみを検証し、新たな問題は発見しません
• 新規コード（新しいモジュール、依存関係、テストスイート）の要求は、ブロッキングではなく Informational とします
• Verdict では Minor と Informational を無視し、Critical と Major のみが承認を妨げます